"The Good Enough Revolution" - As it applies to js

[Gregor Kofler]

jeanph01 meinte:

I'm professionnal but what you consider important for your code is
maybe not important for my user.

Professional in a way, that you make money with that.

Please don't quote signatures.

Gregor

 

[Andy Dingley]

But for most people, these purists are missing the point. "Good
Enough" really is Just Fine.

What does "Good Enough" mean? In terms of features, then yes. The
article you cite is about simple cameras with limited capabilities,
not badly made cameras that break. It doesn't many any reduction in
product quality, where quality is measured as "ability to do what it
ought" rather than "how much it claims to do".

"Just Good Enough" is indeed making a (maybe minor) revolution in
software. Agile approaches, Scrum and LEAN in particular, are moving
this way. It's driven by finally making a comparison between the well-
known observations that "engineering for the future" has a benefit,
but also that a great many features implented (at cost) are never used
in practice, the surprising outcome being that the wasted features do
indeed outweigh the cost of re-engineering when it turns out to be
necessary.

What "Just Good Enough" doesn't do is to compromise _quality_. In
Scrum terms, don't cook up a squirrelburger (search for it). Your
"Just Good Enough" library needs to keep itself simple and not attempt
things that aren't needed, but that's no excuse to permit memory leaks
and the like.

 

[jeanph01]

For what I see the argument of Richard is Jquery is using browser
detection instead of feature detection. And that he find that this is
bad because somewhere some people found that feature detection was the
way to go. But JQ use feature detection a lot, so... He says that JQ
1.3.x is not backward compatible with previous version but there is
numerous thread talking about the painless migration to JQ new
version, so... He's talking about his library that had no problem with
ie8... fine... good for him... now lets make it open source and see
how it behave on every client that JQ is supporting. Is he willing to
submit it to the test swarm (testswarm.com)? He's talking about
performance. But JQ has not been created to be faster than core JS. I
think that it's also one of the slowest lib out there. But like I
said, the programmer that is using it can deliver code fast, he can
benefit from the help of the community and not be bashed out for not
being that elitist religious coding guru that knows it all. And like
I said for the iphone or the blackberry, JQ is not your tool, at least
for now, that's it. Take a look at this stat :
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
With 0.58% to the "other" share, there is not that many blackberry out
there. Finally, programming to the browser is a pain in the s, JQ help
alleviate that pain. I can still use document.getElementsByTagName but
I find $('tag') less burdensome .

And for the rest of your really gentle comment, well, have a nice
day !

For me, Jquery is great. Period. There is so much passion and desire
to help in the community that I don't see why I would not use it. [...]

Blind leading the blind, that's why.  You missed or deliberately ignorethe
"25% not answered" part in Richard's posting as well.  And you did not quote
any of which what you are replying to.  You are a loser finding lame excuses
for your incompetence while blinding yourself to the facts at hand, in the
hope nobody will notice.  Like a kid playing "if I can't see them, they
can't see me."  Only this time the repercussions of your decisions, and
ultimately and inescapably, your mistakes, affect the lives of a great many
other people.  But you don't care about them, do you?  Your job is "done"
(it is not) and you have "delivered" (you have not).

<http://jibbering.com/faq/>

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <[email protected]>

 

[David Mark]

You know, I've gotten that attitude from other jQuery developers. I've
been asked: "Which library do you use?" I've also been told "We are
using jQuery." And when I reply: "For what/What are you trying to do?"
This is the type of answer that is the most insulting to the religious
fanatic. IT's like, not only do I not follow their sect, I don't even
believe in the fundamentalist ideas.

JQuery is promoted as "magic". I think it invites cult-like following.

Of course I can see the benefits of


jQuery is an abstract set of ideas, values, or experiences developed as
part of a cultural matrix.

(comes right from Wikipedia's "Religion" page).




Good place for him .

You bet! Imagine you'll be around as soon as you stop aping my last
project.

 

[David Mark]

For me, Jquery is great. Period. There is so much passion and desire
to help in the community that I don't see why I would not use it.

So you are charitable with your development time? They likely want to
help really badly, but...

Ok I
don't program for the IPhone or blackberry or whatever.

You typically don't program for any specific device(s). Of course, if
you use jQuery, you pretty much exclude devices such as these (unless
you want to really irritate your mobile users).

My clients
have powerful workstations with plenty of bandwidth, lots of Ram but
also with IE6 (ouch!).

There's your biggest reason not to use it. That's the worst one for
them (just ask them!)

When I include the library and plugins, I get a
lot of things I will never need or use.

And pass those along to users who don't need or want them, leading to
a bogged down browsing experience.

So what ? My job is done, i
deliver, and I don't care to continue to work or think about my code
when I go to bed.

Nothing further.

[...]

 

[David Mark]

Erik Reppen meinte:


jQuery was first published in February 2006, IE 7 appeared in October
2006. Go figure.

A - if not _the_ - goal of jQuery is and was to even out the various
pecularities of browsers (or rather browser DOMs). Perhaps it would be a
smart thing to think about intelligent "browser detection" then. And
browser sniffing is not an intelligent way to do so. As it was proven in
2003, 3 yrs before jQuery saw the light of day.

And six years before they saw the light.

 

[David Mark]

For what I see the argument of Richard is Jquery is using browser
detection instead of feature detection.

That's part of it.

And that he find that this is
bad because somewhere some people found that feature detection was the
way to go.

Anyone paying attention for the last decade or so.

But JQ use feature detection a lot, so... He says that JQ

No, it really doesn't. It thinks it does, but...

1.3.x is not backward compatible with previous version but there is
numerous thread talking about the painless migration to JQ new
version, so...

People talk about lots of things. Take this thread...

He's talking about his library that had no problem with
ie8... fine... good for him... now lets make it open source and see
how it behave on every client that JQ is supporting.

It's been done (publicly) by others. Do some research...

Is he willing to
submit it to the test swarm (testswarm.com)?

LOL. Search the archive for that.

He's talking about
performance. But JQ has not been created to be faster than core JS.

It's not faster than anything from what I have seen. Certainly it's
much slower than its peers. Google for "TaskSpeed".

I
think that it's also one of the slowest lib out there.

Oh, so you know.

But like I
said, the programmer that is using it can deliver code fast, he can
benefit from the help of the community and not be bashed out for not
being that elitist religious coding guru that knows it all.

He can deliver code that doesn't work fast? And see the previous
comments about the community. Religion doesn't enter into any of
this.

 And like
I said for the iphone or the blackberry, JQ is not your tool, at least
for now, that's it.

Of course, Web pages are browsed with these devices, so...

Take a look at this stat :http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
With 0.58% to the "other" share, there is not that many blackberry out
there.

Statistics like that are virtually worthless. Many agents imitate IE.

Finally, programming to the browser is a pain in the s, JQ help
alleviate that pain.

No, it really doesn't. It provides that illusion for the uninitiated
(typically those who see cross-browser scripting as impossible to
begin with).

I can still use document.getElementsByTagName but
I find $('tag') less burdensome .

That's a terrible strategy. The former is almost bullet-proof (avoid
"*" of course). The latter is a mysterious black box.

And for the rest of your really gentle comment, well, have a nice
day !

And yes, people were getting around quirks mode (and other IE issues)
long before jQuery came out. Same for ActiveX, attributes, opacity,
etc. That project really did botch everything for the first few years
and there is no reasonable explanation given that the script came out
6 years after IE6. That's 6 *years* and then another three to argue
about it and finally, a decade later... very little progress. And IE
is the biggest problem you have, so who do you want to solve it for
you?

[...]

 

[Bruno Desthuilliers]

Stefan Weiss a écrit :

On 30/08/09 00:33, Jorge wrote: (snip)

That's rich. How do you keep your pages (or applications) accessible, if
you require JavaScript? For many web sites, accessibility for
handicapped visitors is not an optional feature. I'm not sure how that's
handled in Spain, but if I remember correctly, there's even an EU
regulation about this for publically funded sites (correct me if I'm
wrong).

Nope, you're right. And FWIW, accessibilty would also be one of my first
concerns for a e-commerce website - people with certain disabilities
tend to do their shopping online whenever possible.

If ignoring people with screen readers is the future, then I'll
keep living in the past, as you say. Maybe I'll even set up a Gopher
server to prove my point

Lol. But yes, it's always good (and not necessarily that hard) to design
your web apps so they first work without javascript. I sometimes have to
work in text-mode only (oops, system update failed, no more
X-server...), and that's when you really start understanding what
accessibility is about.

 

[Gregor Kofler]

jeanph01 meinte:

[snip]

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.

[IE6 25+% & the most popular browser]

Now this one:
http://gs.statcounter.com/

August:
IE6 < 18%; rank 3
but I have customers mainly in Europe, one says...
IE6 approx. 8.5%...

IOW: Forget those statistics. BTW they use browser-sniffing for those
statistics. Shows how reliable that works.

And for the rest of your really gentle comment, well, have a nice
day !

Same to you for such nice top-postings.

Gregor

 

[Thomas 'PointedEars' Lahn]

jeanph01 meinte:

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.

[IE6 25+% & the most popular browser]

Now this one:
http://gs.statcounter.com/

August:
IE6 < 18%; rank 3
but I have customers mainly in Europe, one says...
IE6 approx. 8.5%...

IOW: Forget those statistics. BTW they use browser-sniffing for those
statistics. Shows how reliable that works.

I think Net Application's figures are more realistic than others, though,
based on their statements: <http://marketshare.hitslink.com/>, "About Our
Market Share Statistics"

(And hey, 23% for Gecko-based UAs world-wide is really not bad!)

However, even if they showed IE (which is probably mostly MSHTML-based
browsers) to have 90% or more, that would not mean anything. In commercial
terms, even 10% spending visitors can generate more profit than 90% which
just look around and leave without spending.


PointedEars

 

[Peter Michaux]

I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...

And had a thought about javascript libraries like jQuery, et al.

I believe this is the point that many library-users try to make that
js "experts" seem to miss. jQuery (as the popular example) is "good
enough". It trades power, perhaps some speed, and certainly some
compatibility for flexibility, convenience, and simplicity. This is a
trade that most js developers are willing to make.

Although the js "purists" will always argue that libraries are _not_
"good enough" because they are never perfect, this is the same
argument that camera purists may make about cheap point-and-shoot
cameras that do not have the quality of the more advances models. Or
any purists in any field who argues against the "good enough"
technology.

But for most people, these purists are missing the point. "Good
Enough" really is Just Fine.

Yes. Many people like to get on with things and finish projects so
good enough libraries are fine for them.

I think this post discounts the roles the purists play. Without the
purists who have criticized these "good enough" libraries with
behavior ranging from respectful criticism to hissy fits, these
libraries would still be "barely good enough." (Yes some would argue
they still are barely good enough or not good enough at all.) As much
as I would like to live in a civilized world with rational people, the
hissy fits may have had the most impact. Not long ago (~2 years) John
Resig was giving a Google tech talk where he was saying things like
"trust me, browser sniffing is fine." Had people only said "excuse me
John, there are better ways but what you're doing sort of works," do
you think jQuery would have removed as much sniffing as it apparently
has? He seemed to need a brick to the head on this issue. Why he
didn't see the value in feature testing articles on the web,
particularly by Richard Cornford, boggles my mind. What is sad is that
it is not even a big deal to write a base JavaScript library that does
all the main things people want and avoids worst practices like user-
agent sniffing. It has been understood for a long time. A couple
thousand lines of code is probably all that is required. With basic
browser scripting it is possible to have the functionality of these
good enough libraries *and* have them well written technically.

Peter

 

[Bart Lateur]

That's a terrible strategy. The former is almost bullet-proof (avoid
"*" of course). The latter is a mysterious black box.

Uh, what?? $() is intended as a shortcut for document.getElementById...
IMHO.

WTF. $(tag) works too. *shudder*.

This is terrible design. What if I have an id that is also usable as a
html tag? How will it know which one to return, the element with that
id, or all those tags?

 

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

jeanph01 meinte:

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.

[IE6 25+% & the most popular browser]

Now this one:
http://gs.statcounter.com/

August:
IE6 < 18%; rank 3
but I have customers mainly in Europe, one says...
IE6 approx. 8.5%...

IOW: Forget those statistics. BTW they use browser-sniffing for those
statistics. Shows how reliable that works.

I think Net Application's figures are more realistic than others, though,
based on their statements: <http://marketshare.hitslink.com/>, "About Our
Market Share Statistics"

Yes, that's what they claim, and what is widely believed. (And their
methodology *sounds* pretty "sophisticatd".) However, those statistics
suffer from the same shortcomings as browser-sniffing libraries...

(And hey, 23% for Gecko-based UAs world-wide is really not bad!)

Hey, *this* is web developer's heaven:
http://gs.statcounter.com/#browser-an-monthly-200808-200909

And this one (if it might be somewhat off) comes close:
http://gs.statcounter.com/#browser-DE-monthly-200808-200909

However, even if they showed IE (which is probably mostly MSHTML-based
browsers) to have 90% or more, that would not mean anything. In commercial
terms, even 10% spending visitors can generate more profit than 90% which
just look around and leave without spending.

Could be wealthy Apple users, who might run any browser except IE. ;-)

Gregor

 

[Jonathan]

Uh, what??  $() is intended as a shortcut for document.getElementById....
IMHO.

WTF. $(tag) works too. *shudder*.

This is terrible design. What if I have an id that is also usable as a
html tag? How will it know which one to return, the element with that
id, or all those tags?

$() is only a shortcut for gEBId in prototype.js, in jQuery it's a
shortcut to their CSS selector engine (sizzle i believe)

So an ID would use $('#id') vs $('div') for a tag

 

[Thomas 'PointedEars' Lahn]

What if I have an id that is also usable as a html tag?

Given that an HTML tag has the form `<...>', what you describe is not going
to happen.

<http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2>


PointedEars

 

[Eric Bednarz]

[…] With all due respect,

Like missing attribution for the quotation?

I don't believe
anybody was doing anything advanced enough with the DOM before IE 7
came out for varying layout or positioning discrepancies and other
concerns to ever be a real issue for your code.

http://www.google.nl/search?q="you+must+be+new+here"

(There are public archives, no reason to get pathetic; a lot of stuff
that is supposed to be very > 2007 has been discussed here in the early
2000’s; I wasn’t here either back then, so you are not excused.)

[…] it's Dean Edwards' work that I'm really intrigued by
and I'm not sure I would expect any of you guys to understand why at
this point.

If I were you, I wouldn’t expect anyone here to understand that at any
future point either. You might question whose problem that is, though.

 

[Garrett Smith]

Yes. Many people like to get on with things and finish projects so
good enough libraries are fine for them.

I think this post discounts the roles the purists play. Without the
purists who have criticized these "good enough" libraries with
behavior ranging from respectful criticism to hissy fits, these
libraries would still be "barely good enough." (Yes some would argue
they still are barely good enough or not good enough at all.) As much
as I would like to live in a civilized world with rational people, the
hissy fits may have had the most impact.

Not necessarily positive impact.

Some individuals point out shortcomings in jq. Others parrot those
points, obnoxiously.

jQuery changes.

Crediting an obnoxious parroter for changes in jq could be a post-hoc
fallacy. In fact, some small problems have gone unfixed (change
string.match -> pattern.test, in many places, to improve perf). Who do
you blame for that?

Regardless, the few small changes in jq don't change the inherent design
of it much.

It's still based on an unneeded query selector which seems to be at the
core of the "magic".

The "event registry" (if it can be so called) still uses attachEvent or
addEventListener.

There's the - attr - which still deals with property/attribute
ambiguously, and that can cause more divergence between browsers than it
solves.

It still mostly uses unqualified - document - references, so can't
generally work in frames in a lot of cases.

The animation is baked into the core of the library. Most of the time,
animation is not needed. What good is it then? When trying to debug
something it could be a distraction, being alongside code that may be
the actual source of the problem. It also takes up a small amount of
memory and download time.

When animation is used, the animation should use a single - setInterval
- not several. jQuery animation library uses multiple setInterval, and
is severely limited in its design. FWICT, it does not seem to handle
color animation and opacity is designed as one-off in the "fade" effects
only.

A well designed animation library would be like a well designed
anything: focused on one thing, extensible, and have absolutely nothing
to do with "attachEvent", "form serialization" or the mishmash things in
jquery core, few (if any) of which have anything to do with animation.

Garrett

 

[Matt Kruse]

Possibly too slow, or too lazy, or too influenced by poor advice or poor
information, or just unable to see the information through the noise, or
any of any number of other reasons/excuses. It doesn't really matter why
it takes so long for people to see how very superior feature detection
is to the alternatives, only that given enough experience (and wit) they
do eventually see it. Prototype.js and JQuery haven't been switching
from browser sniffing to feature detection in order to impress me, they
have been doing it because it is the right thing to do in the context
browser scripting. It is just a pity that neither group managed to see
that before they wrote the initial browser sniffing versions of there
libraries (thus avoiding the need for change it later, and the back
compatibility issues that come with that), given that feature detection
was we well understood and out in the public domain well before they
started.

It is also a shame that those on the edge of js development realized
too late the importance of general-purpose scripting libraries.

Someone could argue that the need for a public general-purpose library
existed around the turn of the century or before, but it took quite a
few years before the js "experts" realized this and either constructed
their own libraries or began volunteering their time to help existing
ones.

Of COURSE some of the popular libraries were slow in adopting some
general good practices. Of COURSE they started out with some bad ideas
and questionable practices. Because their focus was on solving the
problem of how to write, distribute, debug, support, and maintain a
general-purpose library for the masses. Only later did they catch up
to the importance of best practices and better coding style.

For those people whose focus all along was best practices and better
coding style, they only later realized the importance of writing,
distributing, debugging, supporting, and maintaining a public general-
purpose library. Are they not just as to blame for missing the boat?

In 2009 we are seeing the real merging of the two views, and I think
everyone is going to benefit from it as it's sorted out in the near
future. Enough of looking back and trying to figure out who is right
or which stupid bugs existed in version X of popular library Y. Look
forward. Good things are happening.

Matt Kruse

 

[Garrett Smith]

It is also a shame that those on the edge of js development realized
too late the importance of general-purpose scripting libraries.

Someone could argue that the need for a public general-purpose library
existed around the turn of the century or before, but it took quite a
few years before the js "experts" realized this and either constructed
their own libraries or began volunteering their time to help existing
ones.

Of COURSE some of the popular libraries were slow in adopting some
general good practices. Of COURSE they started out with some bad ideas
and questionable practices. Because their focus was on solving the
problem of how to write, distribute, debug, support, and maintain a
general-purpose library for the masses. Only later did they catch up
to the importance of best practices and better coding style.

They who? The authors? Their focus was on providing support?

The authors provided themselves with a career by impressing less
knowledgeable badly designed code.

The only reason jQuery can exist today is because browsers are as
compatible as they are. It is not because the "experts" were unable to
realize it was necessary. Not only was jquery never necessary, jQuery,
as designed, would be an impossibility back in those days.

Even if the browser compatibility issues were addressed, the sheer size
of jquery, coupled with the fickle support of gzip, and slower
connection speeds.

Trying to run jQuery on a PII or Mac G3 running Mozilla 097 or IE 5.5
would be a disaster. Even if it were patched to be made somewhat
compatible to those browsers.

Did you not notice where I pointed out that the Github tech support said
Safari 3 was too slow for their site (Github using jQuery). Safari 3.
Now Safari 2 was faster than Safari 1 and Safari 1 was much faster than
Mozilla when it came out.

The libraries that existed back then were Dan Steinman's Dynamic Duo,
Bindows, and soon after Dojo, which is still an awful disaster.

For those people whose focus all along was best practices and better
coding style, they only later realized the importance of writing,
distributing, debugging, supporting, and maintaining a public general-
purpose library.

I don't know what is the perceived benefit of "importance of
supporting". While there are plenty of things that are interesting to
consider in API design, they have not been mentioned in this thread, FWICS.

Regards,

Garrett

 

[Tim Down]

Crediting an obnoxious parroter for changes in jq could be a post-hoc
fallacy. In fact, some small problems have gone unfixed (change
string.match -> pattern.test, in many places, to improve perf). Who do
you blame for that?

Regardless, the few small changes in jq don't change the inherent design
of it much.
[snip]

The "event registry" (if it can be so called) still uses attachEvent or
addEventListener.

Have I missed something? Is there another way to register multiple
event listeners for a single event on a single object?

Tim