JSLint Reports on last 2 Production Versions of jQuery

[lorlarz]

lorlarz wrote: [snip]

This might make a lot of JS people here mad, but I _want_ to use
jQuery.

Why should anyone care if you _want_ to shoot yourself in the foot.  As
noted by several people, cleaning up the syntax won't cure its real ills
(the logic) any more than cleaning up Dojo's syntax cured its problems.
 It's just a first step to clear things up enough so that the real work
can begin (and history has shown that the jQuery developers are not up
to doing any real work).

I just want to have all assurance or reasonable
quality control.

Then for Christ's sake, listen to people who know better and don't use
that piece of junk.  Why do you _want_ to use it?  Because you see lots
of other people using it?  If they all jumped off a bridge, would you
follow suit?

At the very least, jQuery is very close to
OK.

No, it isn't.  You are getting hung up on the JSLint results, which is
odd as they don't indicate that all is well either.

I just really want to know if there are any _real_ errors
that make things work wrong.

[snip]

I am a long time JavaScripter and tend to use jQuery only very
sparingly for select purposes, where it makes things not just
a little easier but a LOT easier. (I have been criticized for
using it too little; and, I do still write most programs without
it.)

If we could just focus on the JSLint results which I have some
appreciation for. Mainly: Why must I comment out the 2 single
lines and the block of 5 lines in order for JSLint to make
it further (and on through to the end of jQuery)? What is wrong
with _those_ 3 areas of code -- _that_ worries me.
That seems most serious. At least
a good bit of anything else serious seems to be being addressed
by Resig.

David, I looked at the couple of web pages you cited and would
thusly not use jQuery for purposes where those sorts of things
come up (though I will admit that I did not look at the web
pages long enough to really much figure out what they were
about, but it seemed limited and specialized).

 

[David Mark]

lorlarz wrote: [snip]

This might make a lot of JS people here mad, but I _want_ to use
jQuery.

Why should anyone care if you _want_ to shoot yourself in the foot. As
noted by several people, cleaning up the syntax won't cure its real ills
(the logic) any more than cleaning up Dojo's syntax cured its problems.
It's just a first step to clear things up enough so that the real work
can begin (and history has shown that the jQuery developers are not up
to doing any real work).

I just want to have all assurance or reasonable
quality control.

Then for Christ's sake, listen to people who know better and don't use
that piece of junk. Why do you _want_ to use it? Because you see lots
of other people using it? If they all jumped off a bridge, would you
follow suit?

At the very least, jQuery is very close to
OK.

No, it isn't. You are getting hung up on the JSLint results, which is
odd as they don't indicate that all is well either.

I just really want to know if there are any _real_ errors
that make things work wrong.

[snip]

I am a long time JavaScripter and tend to use jQuery only very
sparingly for select purposes, where it makes things not just
a little easier but a LOT easier. (I have been criticized for
using it too little; and, I do still write most programs without
it.)

If we could just focus on the JSLint results which I have some
appreciation for. Mainly: Why must I comment out the 2 single
lines and the block of 5 lines in order for JSLint to make
it further (and on through to the end of jQuery)? What is wrong
with _those_ 3 areas of code -- _that_ worries me.
That seems most serious. At least
a good bit of anything else serious seems to be being addressed
by Resig.

David, I looked at the couple of web pages you cited and would
thusly not use jQuery for purposes where those sorts of things
come up (though I will admit that I did not look at the web
pages long enough to really much figure out what they were
about, but it seemed limited and specialized).

1. Those issues are the tip of a huge iceberg.

2. If you didn't know about those handful of problems, then you
certainly didn't know to avoid them, nor can you avoid the problems that
you can't see. Worse still, the problems may not appear in the
browsers that you have time to test, which is necessarily a tiny subset
of those in use today on the Web.

3. There's nothing limited and specialized about querying by attribute
(or reading/writing/removing attributes). That sort of stuff shows up
in virtually every jQuery example. Where's the list of "bad
attributes?" There isn't one as it would require a dissertation-sized
document to explain the particulars.

The one thing they assert to do better than anyone else is queries and
it is quite clear that they don't do those well at all. They dumped QSA
on top of an already inconsistent mess, so now they have two layers of
inconsistency that vary between browsers, browser versions, browser
modes, and (worst of all) jQuery versions. So stop using CSS queries
(anyone's rendition) to find elements. It's programming for failure, no
matter what a million clueless, gushing bloggers and shills assert.

Then there is IE quirks mode, which they professed to "support" for
years, until it was demonstrated that they have never come close. They
quietly "announced" (in their forum) that they were "punting" on such
issues, which seems very odd for a script that purports to "smooth over"
DOM differences. Also, realize that some of the issues related to IE
quirks mode are not specific to IE quirks mode at all (e.g. box model
variations).

They bit off way more than they could ever hope to swallow years ago and
have been chewing up the Web ever since as they try to make their
designs work in a handful of the very latest desktop browsers (and
basically ignoring the rest), which is a constantly moving target.
That's called failing. Point it out to them and you will hear a lot of
whining, but few indications of understanding. Worse still, they keep
piling on more crap (e.g. attr calling other methods for "special"
attributes), which ensures that the failures will continue indefinitely.
Software doesn't work like that (and never will). Seeing as browser
scripting has challenges that aren't found in most programming
disciplines (e.g. wildly varying environments, download size
limitations, etc.) it would seem the worst bet for relying on petulant
and overconfident amateurs.

Even if you could download, re-test and re-deploy on a nightly basis,
you could never hope to test in every browser and configuration, so you
would never know for sure what works where and how well. You are
putting your faith in people who haven't come close to earning it. Just
what is this faith based on? You really need to get off the bandwagon
before the wheels come all the way off.

In all the time you have spent trying to "fix" jQuery, you could have
written and tested your own basic wrappers that do what you need to them
do (and nothing else). Then you could break out of the endless jQuery
loop and stop worrying about _their_ hopeless cause.

 

[David Mark]

lorlarz wrote:
[snip]
This might make a lot of JS people here mad, but I _want_ to use
jQuery.
Why should anyone care if you _want_ to shoot yourself in the foot. As
noted by several people, cleaning up the syntax won't cure its real
ills
(the logic) any more than cleaning up Dojo's syntax cured its problems.
It's just a first step to clear things up enough so that the real
work
can begin (and history has shown that the jQuery developers are not up
to doing any real work).

For me, the argument for jquery sounds a lot like the argument for the
food provided by Mcdonalds, KFC, Hungry Jacks... In that the food is
fast, cheap, and does the job (if the job is to fill your stomach rather
than to provide nutrition).

Yes, it is mostly empty calories and ultimately _very bad_ for you. But
many of the people who use these things just want to force-feed the
clients, fill their wallets and blow town, so they aren't around to see
the stuff come up. The clients feel "full" for a little while anyway
(i.e. their sites look like they work in the latest major browsers and
their "experts" advise them not worry about anything else).

And, of course, if they do happen to find out that their clients are
sick, their "solution" is to prescribe more junk (i.e. try the latest
nightly). I mean, if a doctor says you have dangerously high
cholesterol levels, they are unlikely to instruct you to try the latest
Big Mac (more likely they will tell you to stay off the junk entirely).

 

[lorlarz]

** I re-ran jQuery in JSLint and nothing WHATSOEVER CHANGED IN THE
REPORT ***
(i.e exactly the SAME long list of 'errors' was generated by JSLint.)

I didn't try it myself, but I think that's highly unlikely. I only
clicked on one of the changeset links you posted, and in that set alone,
at least 20-30 JSLint warnings should have been fixed. Did you really
check out the current trunk version of JQuery? HEAD, or whatever it's
called in Git-land (sorry, svn user here).
[snip]

I am referring to using the same version I used yesterday from
http://jquery.com ,
with one change in one 'fix' .
I did not try any updates since Resig made any changes in response to
the JSLint results.
I was talking about a re-run of JSLint after I made a safer fix to
one of the problems in _yesterday's_ code, that is all. The new
fix to the one line cannot harm the jQuery code (while the initial
'fix' I used yesterday for that one line could -- conceivably).

That is what I am talking about. Now, all the fixes I did to get
jQuery through to the end (i.e. to a a full scan from JSLint) can in
no way do any harm to anything in jQuery (with only the 3 commented
bits or regular expression code the only possible exceptions, those
being:

// replace(/=([^="'>\s]+\/)>/g, '="$1">')

// jsre = /=\?(&|$)/,

/* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== null ) {
soFar = m[3];

parts.push( m[1] );

if ( m[2] ) {
extra = m[3];
break;
}
}
*/

AGAIN, I have not re-run the JSLint with any of Resigs changes
(all which occurred since yesterday). That is not what I was
talking about. I was talking about no difference in JSLint
results after I substituted a complete equivalent bit of code
(that is: equivalent to the original) for one last fix, where I had
not
necessarily done that before. The result:

** I re-ran jQuery in JSLint and nothing WHATSOEVER CHANGED IN THE
REPORT ***
(i.e exactly the SAME long list of 'errors' was generated by

JSLint.)

 

[lorlarz]

lorlarz wrote: [snip]
This might make a lot of JS people here mad, but I _want_ to use
jQuery.
Why should anyone care if you _want_ to shoot yourself in the foot.  As
noted by several people, cleaning up the syntax won't cure its real ills
(the logic) any more than cleaning up Dojo's syntax cured its problems..
 It's just a first step to clear things up enough so that the real work
can begin (and history has shown that the jQuery developers are not up
to doing any real work).
I just want to have all assurance or reasonable
quality control.
Then for Christ's sake, listen to people who know better and don't use
that piece of junk.  Why do you _want_ to use it?  Because you seelots
of other people using it?  If they all jumped off a bridge, would you
follow suit?
At the very least, jQuery is very close to
OK.
No, it isn't.  You are getting hung up on the JSLint results, which is
odd as they don't indicate that all is well either.
I just really want to know if there are any _real_ errors
that make things work wrong. [snip]

I am a long time JavaScripter and tend to use jQuery only very
sparingly for select purposes, where it makes things not just
a little easier but a LOT easier.  (I have been criticized for
using it too little; and, I do still write most programs without
it.)

If we could just focus on the JSLint results which I have some
appreciation for.  Mainly: Why must I comment out the 2 single
lines and the block of 5 lines in order for JSLint to make
it further (and on through to the end of jQuery)?  What is wrong
with _those_ 3 areas of code -- _that_ worries me.
  That seems most serious.  At least
a good bit of anything else serious seems to be being addressed
by Resig.

David, I looked at the couple of web pages you cited and would
thusly not use jQuery for purposes where those sorts of things
come up (though I will admit that I did not look at the web
pages long enough to really much figure out what they were
about, but it seemed limited and specialized).

1. Those issues are the tip of a huge iceberg.

2. If you didn't know about those handful of problems, then you
certainly didn't know to avoid them, nor can you avoid the problems that
 you can't see.  Worse still, the problems may not appear in the
browsers that you have time to test, which is necessarily a tiny subset
of those in use today on the Web.

3. There's nothing limited and specialized about querying by attribute
(or reading/writing/removing attributes).  That sort of stuff shows up
in virtually every jQuery example.  Where's the list of "bad
attributes?"  There isn't one as it would require a dissertation-sized
document to explain the particulars.

The one thing they assert to do better than anyone else is queries and
it is quite clear that they don't do those well at all.  They dumped QSA
on top of an already inconsistent mess, so now they have two layers of
inconsistency that vary between browsers, browser versions, browser
modes, and (worst of all) jQuery versions.  So stop using CSS queries
(anyone's rendition) to find elements.  It's programming for failure, no
matter what a million clueless, gushing bloggers and shills assert.

Then there is IE quirks mode, which they professed to "support" for

[snip]

That all sounds really bad. I doubt that studying the 2 web pages
would make this clear to me, but perhaps I should take a closer
look. If the situation is so bad, then perhaps you should
publish a list of specific, obviously important and/or common
specific failures (in the specific browsers). Only such an
expose' would make it clear to me _and_ certainly such an
expose' would be necessary to cause adherents to stop and
take a close look -- and that is what matters.

 

[lorlarz]

** I re-ran jQuery in JSLint and nothing WHATSOEVER CHANGED IN THE
REPORT ***
(i.e exactly the SAME long list of 'errors' was generated by JSLint.)

I didn't try it myself, but I think that's highly unlikely. I only
clicked on one of the changeset links you posted, and in that set alone,
at least 20-30 JSLint warnings should have been fixed. Did you really
check out the current trunk version of JQuery? HEAD, or whatever it's
called in Git-land (sorry, svn user here).
[snip]

** BIG UPDATE **:
jQuery now passes JSLint 100% but with noted exceptions:

Quoting a recent post from John Resig to the
group http://forum.jquery.com/developing-jquery-core

Quoting it in-full:

An update: jQuery is now 100% passing JSLint (with a few exceptions,
noted below) and is integrated into the jQuery build process. I've
been making changes to the codebase all day today and it's at a good
state now.

Here is where I integrated JSLint into the jQuery build process:
http://github.com/jquery/jquery/commit/950b5d64a27994db1697eb4e605f5ea48ad8021b

A list of the exceptions that we ignore in our JSLint run can be found
here, with explanation:
http://docs.jquery.com/JQuery_Core_Style_Guidelines#JSLint

(end quote)

 

[David Mark]

WTF?! It could be a typo or it could just be a very bizarre construct.
You've really got to feel for anyone who has to wade through this stuff
on a regular basis. Perhaps that explains the snail's pace of their
"progress" over the last few years. Who would subject themselves to
fiddling around with such nonsense?

[snip]

David,

I don't think you know how well jQuery is doing.

How well it is doing what? Do you mean that it is popular among Web
developers who don't know the first thing about browser scripting? That
follows as it gives them the illusion that they can create solutions
without learning anything about JS and how it interacts with browsers.
Does that appeal to you? What would your clients think of such a
strategy employed on their nickel?

It is by far the
most used JS library and has had and continues to have the fastest
growth.

Most used? Again, so what? And I think more people are dumping it than
adopting it at this point. It isn't scientific, but seeing their GG
posts (before they nuked the group) drop by half since IE8 came out
seems to indicate that people are getting fed up with all of its
problems (which were predictably exacerbated by IE8).

Moreover, jQuery is now used somewhere in a full 20% of
web sites on the Earth.

Who conducted that survey?

We must stay critical about it. But, while other libraries may be
failing, from any use standpoint, jQuery is not.

Other libraries are certainly (and justifiably) failing. Dojo is a good
example; but according to them, that is strictly because they "botched
their documentation" (which may have played a part, but then they aren't
really in a position to document their code as they clearly don't
understand it). It certainly doesn't help their case that their new
documentation is using jQuery 1.2x. (!)

This was posted to their new (also jQuery-powered) forum as an
"explanation" of Dojo's failings on the Web:-

http://n3.nabble.com/Dojo-marketing-tp417680p417740.html

"There's a lot of reasons. Some are that we dropped the ball on
documentation two years ago and we're still playing catch up."

Are they ever, but without understanding their own code's failings and
limitations, they can't really catch up in any meaningful sense.

"Without docs people didn't get how to use Dojo. Since dojo is so
complex and has so many facets and it is used on so many big projects
the core users weren't the overly ambitious blogger type."

So many big projects? Where? Sounds like marketing hyperbole to me.
And I certainly didn't find it particularly complex when I rewrote most
of it last summer. Quite the contrary, each piece was a
less-than-stellar rendition of the same old crap that you can find
elsewhere. But even with the rewrites staring them in the face, they
couldn't figure out what to do next (e.g. lose all of the miserable UA
sniffing). Last I checked, they were piling on more themes.

"jQuery had an easy to understand message, it did one thing really well
(query) and they built from there."

And that message was and is a lie.

"Dojo did everything for anyone."

No they didn't. They piled a bunch of disjointed, UA sniffing crap
together in a ZIP and tied it together with synchronous (blocking) XHR.
Jack of all trades, master of none.

"Lots of people blogged with tutorials for simple 'wowie' stuff with
jQuery which got more people into it and the ball kept rolling. More
blogs, more exposure and more marketshare. They did their marketing right."

And they did their coding wrong. Is that a good lead to follow?

"So we finally started getting our act together and telling people how
great dojo is."

Which is also a whopper. Great at what exactly? Last I looked, the
queries (for example) were fouled up worse than jQuery's (which is
saying something). And, as I recently pointed out on their mailing
list, their XHR module - for example - _requires_ the botched query
module. In fact, if memory serves me, virtually everything in their
core requires everything else. So much for the much-touted modularity.
It's all of the irritation of dealing with a gazillion pieces without
any of the benefits usually associated with granularity. I got one
response to that (about the third time I pointed it out) and it was
something along the lines of it was the "smart" way to do it (and
"everybody" is doing it that way, not just them).

"We have updated our site for the first time in a few years and we're
still working towards a next release of the site with even more info."

Yes, I've seen the site. It's certainly not helping matters.

"We updated our docs and are continuing to improve it. We still need
people blogging about dojo and giving easy to understand examples that
have that 'wowie' effect as a way to get people into dojo."

Wowie! More disingenuous marketing aimed at the easily deluded. It's
like they are flat-out admitting (in public no less) that they plan to
stress dubious points, which implies that they have no solid points to make.

"Showing off the hardcore stuff that's really cool to us (like data
stores and charting) is fine but we have to understand that the vast
majority of people don't care about that stuff.."

Hardcore? It's built on a foundation of feathers. Doesn't matter how
much complicated crap they pile on top of it. In fact, that's their
biggest problem and it is clearly self-imposed (i.e. they can't/won't
solidify the foundation as they don't see such work as having the
desired "wowie" effect).

"they want to quickly add effects and do dom manipulation and there's
ample blog posts and tutorials out there for almost every use case. So
copy and pasting is really easy."

He means copying and _praying_. Most of what you cobble together today
will fall apart tomorrow. What can you say about such a huge and
complex pile of scripts that must be upgraded every time a new (major)
browser appears. And forget about the browsers they profess to not care
about, like Opera 9 and Safari 3. They came within an inch of adding IE
6/7 to that list as well until I pointed out that IE8 can be made to act
just like IE7 (which is pretty close to IE6) with the touch of a button.
But still they "argued" that IE was "holding them back" and the rest of
the world would one day "catch up" to their "advancements". You better
pray _hard_ if you bet on this bunch.

 

[David Mark]

lorlarz wrote:
[snip]
This might make a lot of JS people here mad, but I _want_ to use
jQuery.
Why should anyone care if you _want_ to shoot yourself in the foot. As
noted by several people, cleaning up the syntax won't cure its real ills
(the logic) any more than cleaning up Dojo's syntax cured its problems.
It's just a first step to clear things up enough so that the real work
can begin (and history has shown that the jQuery developers are not up
to doing any real work).
I just want to have all assurance or reasonable
quality control.
Then for Christ's sake, listen to people who know better and don't use
that piece of junk. Why do you _want_ to use it? Because you see lots
of other people using it? If they all jumped off a bridge, would you
follow suit?
At the very least, jQuery is very close to
OK.
No, it isn't. You are getting hung up on the JSLint results, which is
odd as they don't indicate that all is well either.
I just really want to know if there are any _real_ errors
that make things work wrong.
[snip]
I am a long time JavaScripter and tend to use jQuery only very
sparingly for select purposes, where it makes things not just
a little easier but a LOT easier. (I have been criticized for
using it too little; and, I do still write most programs without
it.)
If we could just focus on the JSLint results which I have some
appreciation for. Mainly: Why must I comment out the 2 single
lines and the block of 5 lines in order for JSLint to make
it further (and on through to the end of jQuery)? What is wrong
with _those_ 3 areas of code -- _that_ worries me.
That seems most serious. At least
a good bit of anything else serious seems to be being addressed
by Resig.
David, I looked at the couple of web pages you cited and would
thusly not use jQuery for purposes where those sorts of things
come up (though I will admit that I did not look at the web
pages long enough to really much figure out what they were
about, but it seemed limited and specialized).

1. Those issues are the tip of a huge iceberg.

2. If you didn't know about those handful of problems, then you
certainly didn't know to avoid them, nor can you avoid the problems that
you can't see. Worse still, the problems may not appear in the
browsers that you have time to test, which is necessarily a tiny subset
of those in use today on the Web.

3. There's nothing limited and specialized about querying by attribute
(or reading/writing/removing attributes). That sort of stuff shows up
in virtually every jQuery example. Where's the list of "bad
attributes?" There isn't one as it would require a dissertation-sized
document to explain the particulars.

The one thing they assert to do better than anyone else is queries and
it is quite clear that they don't do those well at all. They dumped QSA
on top of an already inconsistent mess, so now they have two layers of
inconsistency that vary between browsers, browser versions, browser
modes, and (worst of all) jQuery versions. So stop using CSS queries
(anyone's rendition) to find elements. It's programming for failure, no
matter what a million clueless, gushing bloggers and shills assert.

Then there is IE quirks mode, which they professed to "support" for

[snip]

That all sounds really bad.

It certainly is (as I've been pointing out for years).

I doubt that studying the 2 web pages
would make this clear to me, but perhaps I should take a closer
look.

Yes, and you should search the _archive_ to find tons of additional
information about your favorite script. This will likely save you a lot
of future trouble.

If the situation is so bad, then perhaps you should
publish a list of specific, obviously important and/or common
specific failures (in the specific browsers).

How is it my job to educate the world about jQuery? That being said, I
think I've done more than my part. I hear the same old "argument" over
and over from various camps that if only I would put it all together in
a pretty package, perhaps they would get off their asses and read what I
have to say. My job (meaning that which puts money in my wallet) is to
steer _clients_ clear of train wrecks like jQuery (and, quite frankly,
the rest of the non-paying world can go to hell in a hand-basket). It
doesn't take drawing pretty pictures either (usually just a brief
lecture and they are scared straight). Of course, if you have me, you
don't need any of these things anyway. The one objection I do hear
repeatedly is that they are worried about what happens when I am gone,
but that's what documentation and training are for.

Only such an
expose' would make it clear to me _and_ certainly such an
expose' would be necessary to cause adherents to stop and
take a close look -- and that is what matters.

No, they usually just cluck about how newsgroups are old-fashioned
(often on IRC no less) and best ignored. All of the information you
need is available one way or the other. Some make the effort to get it
for free, others prefer to save time and pay for it. In the middle are
the majority wafflers who alternately complain and plead. I've grown
very weary of that segment over the past few years.

 

[David Mark]

** I re-ran jQuery in JSLint and nothing WHATSOEVER CHANGED IN THE
REPORT ***
(i.e exactly the SAME long list of 'errors' was generated by JSLint.)

I didn't try it myself, but I think that's highly unlikely. I only
clicked on one of the changeset links you posted, and in that set alone,
at least 20-30 JSLint warnings should have been fixed. Did you really
check out the current trunk version of JQuery? HEAD, or whatever it's
called in Git-land (sorry, svn user here).
[snip]

** BIG UPDATE **:
jQuery now passes JSLint 100% but with noted exceptions:

Quoting a recent post from John Resig to the
group http://forum.jquery.com/developing-jquery-core

Quoting it in-full:

An update: jQuery is now 100% passing JSLint (with a few exceptions,
noted below)

He really led off with that?

and is integrated into the jQuery build process. I've
been making changes to the codebase all day today and it's at a good
state now.

Yes, I'm sure he was anxious to prove me wrong about his willingness to
make changes (and these were very easy ones of course). No need to
thank me. But, as pointed out, this changes very little in terms of the
viability of the script. In fact, it literally changes nothing for
sites that are running on pre-epiphany jQuery.

And it took all day?!

Here is where I integrated JSLint into the jQuery build process:
http://github.com/jquery/jquery/commit/950b5d64a27994db1697eb4e605f5ea48ad8021b

A list of the exceptions that we ignore in our JSLint run can be found
here, with explanation:
http://docs.jquery.com/JQuery_Core_Style_Guidelines#JSLint

"We ignore the following warnings from JSLint:

"Expected an identifier and instead saw 'undefined' (a reserved word)."
- In jQuery we re-declare 'undefined' as we use it internally. Doing so
prevents users from accidentally munging the name (assigning to
undefined and messing up our tests) and also makes the undefined checks
slightly faster."

Messing up their tests?! And I fail to see how using a variable makes
checking for an undefined variable any faster.


""Use '===' to compare with 'null'." and "Use '!==' to compare with
'null'." - Almost universally in jQuery core we use === or !== with the
exception of when we're comparing against null. It's actually quite
useful to do == null or != null as it will pass (or fail) if the value
is either null or undefined. If we want to explicitly check for a null
or undefined value we use === null or === undefined (discussed in depth
below)."

Of course, that was a large percentage of the warnings. And how is it
"quite useful" to write hopelessly ambiguous code? They use that in
lots of places where it shouldn't be expected to match more than one of
those values.

""Expected an assignment or function call and instead saw an
expression." - There are two areas in which we access a property with
seemingly no side effect, those are:
parent.selectedIndex; (or similar) this is due to the fact that WebKit
mis-reports the default selected property of an option, accessing the
parent's selectedIndex property fixes it."

We went over (and over) that. It's a ridiculous incantation that is
easily avoided. Just check the selectedIndex property as it has the
information needed! Don't evaluate it, pray that that has the desired
side effect and then check a different property. If there is one (two
as it is duplicated) "area" that demonstrates the failings of John Resig
to understand basic browser scripting, this is it. He bases decisions
on what he can see happening (today) rather than sound logic. This
leads to scripts that "work" today and fail tomorrow. It's hardly
unexpected that he would choose to ignore this (again).

"Array.prototype.slice.call( document.documentElement.childNodes, 0
)[0].node... - This check simply attempts to determine if, after a slice
on a NodeList, the resulting collection still holds DOM nodes. This is a
feature detection and is wrapped in a try/catch (if the property doesn't
exist it'll throw an exception."

And, that can hardly be what JSLint was complaining about as it isn't
concerned with the code's _logic_ (or host objects).

""Expected a 'break' statement before 'case'." - There is only one
legitimate reason to use switch statements over an object of properties
or a series of if/else statements: passthroughs."

That's meaningless gobbledygook. Who decided that switch statements
without "pass-throughs" were illegitimate? On the contrary,
pass-throughs are exactly what JSLint is (legitimately) complaining
about as they require careful examination to determine whether the lack
of a - hreak - was intended or an oversight. And what the hell is an
"object of properties?"

""We use it inside of Sizzle to optimize our nly-child selector
checks, reducing code and improving performance."

Whatever.

"Additionally we enable the following two JSLint options by default:

"evil" - This allows code evaluation. We only use it in one place inside
of jQuery: Backwards compatibility support for JSON parsing (we
preferably use the modern JSON.parse method if it's available)."

Evil is right. IIRC, they never did figure out that the Function
constructor is more appropriate for that task.

""forin" - This removes the requirement of doing a hasOwnProperty check
inside of for/in loops. jQuery doesn't support working in an environment
that has manipulated the Object.prototype as it's considered harmful."

Yes, harmful to incompetently written scripts.

The style guide continues:-

"TYPE CHECKS

String: typeof object === "string"
Number: typeof object === "number"
Boolean: typeof object === "boolean"
Object: typeof object === "object""

Cargo cult. There's no reason to use strict comparisons here.

"Function: jQuery.isFunction(object)"

typeof fn == 'function'; // Don't ever use such tests with host objects

"Array: jQuery.isArray(object)"

I'm sure that's the less-than-solid "Miller Device" (another device that
should be designed out of the system, but can't be at this late date).

"Element: object.nodeType
null: object === null
null or undefined: object == null"

That last one is used to death in jQuery, yet it would seem to be (and
should be) rarely needed.

"undefined:
Global Variables: typeof variable === "undefined"
Local Variables: variable === undefined
Properties: object.prop === undefined"

Ridiculously counter-intuitive (and this is because of their undefined
argument trick).

"REGEXP

All RegExp operations should be done using .test() and .exec().
"string".match() is no longer used."

Why? IIRC, they used to use - match - where - test - would be more
appropriate (as I pointed out in numerous reviews), but that is hardly a
style issue as they do two different things.

"STRINGS

Strings should always use double-quotes instead of single-quotes."

Even if they contain double-quotes?

"NODES

..nodeName should always be used in favor of .tagName."

Those are hardly equivalent. This is the usual over-generalization that
leads to would-be programmers shooting their toes off.

".nodeType should be used to determine the classification of a node (not
..nodeName)."

Apples and oranges (again).

"Don't attach expandos to nodes - only attach data using .data()."

....which adds an expando. When it comes to expandos, it's in for a
penny, in for a pound. They should be avoided at design time, but it's
a bit late for jQuery to change that aspect of their design. And due to
their attr woes, at one point at least, these expandos were being
manifested as custom attributes in IE8. (!)

Admittedly, some modules in My Library (e.g. query) attach an expando to
element nodes, but at least IE is spared (as of late), and IE is the
only major browser known to throw exceptions on such assignments. I
think there is still a check for document.expando === false guarding the
query module, which I can now safely remove. There are also a few other
places where document nodes receive expandos (and are guarded with
similar checks that are no guarantee for non-IE browsers), but those
will be removable once support for frames is relegated to builds that
explicitly request such support (of course, frames-enabled builds will
still require them).

 

[David Mark]

That's good news.


| We ignore the following warnings from JSLint:
|
| * "Expected an identifier and instead saw 'undefined' (a reserved
| word)." In jQuery we re-declare 'undefined' as we use it internally.
| Doing so prevents users from accidentally munging the name (assigning
| to undefined and messing up our tests) and also makes the undefined
| checks slightly faster.

It has been mentioned on the JSLint mailing list that the text of this
warning is confusing, because "undefined" is not, in fact, a reserved
word. They could have used something like "undef" or "_undefined" in
jQuery to avoid the warning.

Yes, that would be one sane approach.

| * "Use '===' to compare with 'null'." and "Use '!==' to compare with
| 'null'." - Almost universally in jQuery core we use === or !== with
| the exception of when we're comparing against null. It's actually
| quite useful to do == null or != null as it will pass (or fail) if the
| value is either null or undefined. If we want to explicitly check for
| a null or undefined value we use === null or === undefined (discussed
| in depth below).

Seems to happen a lot in jQuery.

Indeed. It was the bulk of the warnings IIRC.

Funny, I never had a problem with this
warning; I usually either check for "really not null", or truthy.

Sure, it depends on the context.

Anything more complicated than that tends to end up in a function.

They seem to favor ambiguity over readability.

| * "Expected an assignment or function call and instead saw an
| expression." - There are two areas in which we access a property with
| seemingly no side effect, those are:
|
| o parent.selectedIndex; (or similar) this is due to the fact that
| WebKit mis-reports the default selected property of an option,
| accessing the parent's selectedIndex property fixes it.

David mentioned there was a better way to work around this, but I'm not
sure what he was referring to.

The "issue" is that prior to the DOM being ready (or for SELECT's that
have yet to be appended to the DOM), in some browsers, the - selected -
property of the first contained OPTION element will not be set _unless_
it has a SELECTED attribute (which would only be an issue if _none_ of
the other options is selected, either by attribute or memorized user
intervention). Of course, at least one OPTION should have a SELECTED
attribute. But regardless, the selectedIndex property invariably
reveals which option is selected, so it is trivial to determine if a
random OPTION is selected or not by checking the value of that property.
This was explained to Resig (by proxy of course) and then re-explained
(at least one time). Somehow he decided that his mystical incantation
was more "concise" (meaning less _lines_ of code) and therefore it
remains today (four times over at this point due to duplication and the
possibility of the parentNode being an OPTGROUP). It's funny that even
JSLint recognized it as silly and he deflected its advice as well.
Hopeless.

| o Array.prototype.slice.call( document.documentElement.childNodes,
| 0)[0].node... - This check simply attempts to determine if, after a
| slice on a NodeList, the resulting collection still holds DOM nodes.
| This is a feature detection and is wrapped in a try/catch (if the
| property doesn't exist it'll throw an exception.
|
| * "Expected a 'break' statement before 'case'." - There is only one
| legitimate reason to use switch statements over an object of
| properties or a series of if/else statements: passthroughs. We use it
| inside of Sizzle to optimize our nly-child selector checks, reducing
| code and improving performance.

I suggested that JSLint should accept a /*fallthrough*/ comment here,
but Douglas Crockford didn't agree.

I can see such a comment as a suitable substitute. Still, as I noted in
my review of these notes, Resig's assertions about switch statements are
ludicrous at best (I've read them three times now and still have no idea
what he's even talking about).

| Additionally we enable the following two JSLint options by default:
|
| * "evil" - This allows code evaluation. We only use it in one place
| inside of jQuery: Backwards compatibility support for JSON parsing (we
| preferably use the modern JSON.parse method if it's available).
|
| * "forin" - This removes the requirement of doing a hasOwnProperty
| check inside of for/in loops. jQuery doesn't support working in an
| environment that has manipulated the Object.prototype as it's
| considered harmful.

Both of these sound reasonable. I used to use hasOwnProperty()
religiously, but now I think that users who augment Object.prototype
deserve what they get.

But if your scripts must coexist with others on the Web...

Which means that neither jQuery nor my code will
work alongside Prototype.js; I don't have a problem with that.

Ah, I think they finally fixed those problems (after years of broken
scripts and public ridicule). Of course, the old versions are likely
still floating around out there.

 

[Michael Haufe (\TNO\)]

"Expected an identifier and instead saw 'undefined' (a reserved word)."
- In jQuery we re-declare 'undefined' as we use it internally. Doing so
prevents users from accidentally munging the name (assigning to
undefined and messing up our tests) and also makes the undefined checks
slightly faster."

Messing up their tests?!  And I fail to see how using a variable makes
checking for an undefined variable any faster.

I would expect it to be significantly faster and more correct if they
used "void 0" instead of a name of any sort for this. Of course, no
one there reads this list by their own admission... So I wouldn't be
surprised to see this exact change shows up in their code base soon .

 

[David Mark]

I would expect it to be significantly faster and more correct if they
used "void 0" instead of a name of any sort for this.

Or a typeof test.

Of course, no
one there reads this list by their own admission... So I wouldn't be
surprised to see this exact change shows up in their code base soon .

Yes, it would be another in a long series of "coincidences." Of course,
the changes usually show up (much) later rather than sooner.

But their marketers continue to steer the users clear of this newsgroup
as they want them to think that the jQuery geniuses can get along just
fine on their own. The most inexplicable (on a number of levels)
comment I saw recently was that they should look to the JS "experts"
that frequent sites like StackOverflow and (groan) the Dojo mailing list
(no that's not a misprint).

The most ironic part of that is that the typical jQuery zealot hates me
when they should be thanking me for making their lives (a little)
easier. I guess it doesn't help that my primary proxy reinforces the
perception my "unhelpful" nature at every turn (focusing on the contrast
to his "helpful" parroting of my ideas). Crazy world.

 

[Garrett Smith]

[...]

"We ignore the following warnings from JSLint:

"Expected an identifier and instead saw 'undefined' (a reserved word)."

That JSLint Error is completely wrong. `undefined` is a property of the
global object, not a reserved word. It is not an error and should not be
flagged as an error.

[...]

Messing up their tests?! And I fail to see how using a variable makes
checking for an undefined variable any faster.

We discussed this last year, IIRC.

Think about how scope chain and identifier resolution works. `undefined`
is an identifier, not a reserved word, so it must be resolved up the
scope chain, just like any other identifier.

The short answer to why it should faster is that the identifier
`undefined` is resolved sooner on the scope chain, rather than looking
up to the global scope.

[...]

Evil is right. IIRC, they never did figure out that the Function
constructor is more appropriate for that task.

The function constructor is safer because it does not use global scope.

// Use grouping operator to avoid ASI-related error.
var f = new Function("return("+responseText");");

// later on.
var responseValue = f();

""forin" - This removes the requirement of doing a hasOwnProperty check
inside of for/in loops. jQuery doesn't support working in an environment
that has manipulated the Object.prototype as it's considered harmful."

Yes, harmful to incompetently written scripts.

Exactly, IIRC Prototype JS 1.5 or so was modifying Object.prototype.
They probably got the idea from Crockford, who, actually advocated doing
that and called scripts that didn't handle it "incompetent".

The style guide continues:-

"TYPE CHECKS

String: typeof object === "string"
Number: typeof object === "number"
Boolean: typeof object === "boolean"
Object: typeof object === "object""

Cargo cult. There's no reason to use strict comparisons here.

It doesn't really matter either way. It is marginally faster, but
insignificantly so.

The rule I have tried to be consistent with is to use === unless == is
needed, which is pretty rarely.

I chose this because the person reading the code might wonder there is
== in one string comparison check and === in another. If === is used for
other comparisons of string values, then it can be used consistently
without ambiguity or confusion.

"Function: jQuery.isFunction(object)"

typeof fn == 'function'; // Don't ever use such tests with host objects

"Array: jQuery.isArray(object)"

I'm sure that's the less-than-solid "Miller Device" (another device that
should be designed out of the system, but can't be at this late date).

My favorite one is Dojo `it instanceof Array || typeof it == "array"`.

 

[Garrett Smith]

** BIG UPDATE **:
jQuery now passes JSLint 100% but with noted exceptions:

[...]

| * "Expected an assignment or function call and instead saw an
| expression." - There are two areas in which we access a property with
| seemingly no side effect, those are:
|
| o parent.selectedIndex; (or similar) this is due to the fact that
| WebKit mis-reports the default selected property of an option,
| accessing the parent's selectedIndex property fixes it.

The workaround is an undocumented quirk.

David mentioned there was a better way to work around this, but I'm not
sure what he was referring to.

Probably to give the OPTION the `selected` attribute, as RobG pointed
out last year.

Anyhow, it is resolved by following advice in the HTML specification
from a decade ago:

| "Since user agent behavior differs, authors should ensure that each
| [select] includes a default pre-selected OPTION."
|
| <URL: http://www.w3.org/TR/html4/interact/forms.html#h-17.6.1 >

http://groups.google.com/group/comp.lang.javascript/msg/93c61c9ad6e2210c?dmode=source

[...]

 

[David Mark]

On 02/03/10 01:32, lorlarz wrote:

[...]

"We ignore the following warnings from JSLint:

"Expected an identifier and instead saw 'undefined' (a reserved word)."

That JSLint Error is completely wrong. `undefined` is a property of the
global object, not a reserved word. It is not an error and should not be
flagged as an error.

But using it as an argument name is pretty stupid.

[...]

Messing up their tests?! And I fail to see how using a variable makes
checking for an undefined variable any faster.

We discussed this last year, IIRC.

Think about how scope chain and identifier resolution works. `undefined`
is an identifier, not a reserved word, so it must be resolved up the
scope chain, just like any other identifier.

And therein lies my mistake. I know how identifier resolution works (my
whole library is based on avoiding global resolution), but the previous
warning caused a brain malfunction as to the undefined identifier.
Personally I prefer the typeof test. If space is a concern, set a local
variable to the string "undefined" and compare to that, but then that
will be slower than comparing to a string literal.

The short answer to why it should faster is that the identifier
`undefined` is resolved sooner on the scope chain, rather than looking
up to the global scope.

Assuming implementations don't optimize for the undefined identifier in
some way.

[...]

Evil is right. IIRC, they never did figure out that the Function
constructor is more appropriate for that task.

The function constructor is safer because it does not use global scope.

I assume you meant that it does use the global scope, whereas eval uses
whatever scope the call resides in.

// Use grouping operator to avoid ASI-related error.
Huh?

var f = new Function("return("+responseText");");

// later on.
var responseValue = f();


Exactly, IIRC Prototype JS 1.5 or so was modifying Object.prototype.
They probably got the idea from Crockford, who, actually advocated doing
that and called scripts that didn't handle it "incompetent".

And round and round it goes. Regardless, it doesn't make sense to use
unfiltered for-in loops on the Web.

It doesn't really matter either way. It is marginally faster, but
insignificantly so.

I would think that would depend on the implementation. But it is
interesting that they would take the size hit of an extra character for
no reason (they seem to count characters fanatically).

The rule I have tried to be consistent with is to use === unless == is
needed, which is pretty rarely.

I do the exact opposite. Why use strict if you don't have to?
Regardless of possible minute performance benefits, I think it obscures
the meaning of the code (when I see strict comparisons, I figure there
is a good reason for them).

I chose this because the person reading the code might wonder there is
== in one string comparison check and === in another. If === is used for
other comparisons of string values, then it can be used consistently
without ambiguity or confusion.

I like it better my way.

My favorite one is Dojo `it instanceof Array || typeof it == "array"`.

Buffoons. I tried to tell them that was ridiculous, but they just
carped about providing "proof" (and something about ad hominem attacks).
That was the end of that. Now here they are getting ridiculed (again).
I can't bring myself to feel sorry for them. Maybe they enjoy being
laughingstocks, but they do seem put off by the fact that nobody is
using their "great" library. Nothing about that group adds up.

I kept trying to tell them that if they argue over every miserable
mistake, it was going to take forever to get through all of the code.
Near as I can tell, they are still stuck on the very first major problem
(their "global" eval method). And they can't claim I was unhelpful as I
personally rewrote the bulk of it for them (which they almost
immediately dismissed as not theirs).

 

[David Mark]

** BIG UPDATE **:
jQuery now passes JSLint 100% but with noted exceptions:

[...]

| * "Expected an assignment or function call and instead saw an
| expression." - There are two areas in which we access a property with
| seemingly no side effect, those are:
|
| o parent.selectedIndex; (or similar) this is due to the fact that
| WebKit mis-reports the default selected property of an option,
| accessing the parent's selectedIndex property fixes it.

The workaround is an undocumented quirk.

Yes, they are big on those. Seeing something happen in a browser is all
the "proof" they need to treat it as a viable solution. Dojo does this
constantly too. Wonder why these things have to be constantly rewritten
to keep up with three or four browsers?

Probably to give the OPTION the `selected` attribute, as RobG pointed
out last year.

No probably about it (though it sets the property, not the attribute).
It was discussed to death (here and in jQuery-land). Everyone knows
what it is supposed to do, but nobody (sane) would do it that way.

 

[Gregor Kofler]

lorlarz meinte:

I am a long time JavaScripter

Then it shouldn't be a problem to interpret the JSLint output yourself.
Why did you start this thrad?

Gregor

 

[David Mark]

On 02/03/10 01:32, lorlarz wrote:

[...]

"We ignore the following warnings from JSLint:

"Expected an identifier and instead saw 'undefined' (a reserved word)."

That JSLint Error is completely wrong. `undefined` is a property of the
global object, not a reserved word. It is not an error and should not be
flagged as an error.

Forgot to mention that the other argument passed with it is called
"window" and references the window object (of course). ISTM that I
pointed out years ago that a local reference to this mother of all host
objects is a very bad idea (due to the obvious potential for circular
references and the resulting memory leaks in IE). JSLint can't help
them there, but I tried.

 

[David Mark]

<snip>

Proof of what exactly?

That's what I said, but the "cutting edge JS hackers" couldn't come up
with anything more than griping.

That there are no ECMA 262 conforming language implementations where -
typeof - operation applied to an Array object results in the string
"array"? Which doesn't need proving as that is required by "ECMA 262
conforming language implementation".

Of course. But I don't think they have read the specs. In their minds,
there might be a browser out there that does this because that dubious
comparison must have been included for some reason.

That there have never been any web browser script language
implementations based on JavaScript, JScript or/and ECMAScript where -
typeof - operation applied to an Array object results in the string
"array"? Why would they care, as they are not even attempting to support
all possible browsers, only a known set where the situation can be
objectively verified?

In short, they are nuts. I don't know how else to explain their
behavior in this regard (among many others). Their latest and
"greatest" Website, which will ostensibly spur new interest in their
project uses jQuery (1.2x no less) for God's sake.

Another example is that when somebody posted some random numbers that
seemed (to them) to indicate that undeclared globals were "faster", a
chain reaction started that came within an inch of committing changes
that would un-declare all of their globals. (!) They were all very
hyped up about this "breakthrough", which was seen as a counterpoint to
the various speed improvements I introduced in my branch (which they
sullenly dismissed by posting still more random numbers).

I finally headed that one off at the Trac-level by pointing out that the
aforementioned random numbers didn't indicate that at all (as well as
the fact that using undeclared variables was insane and could easily
lead to major problems in one of the browsers they profess to care about).

What is it about the - typeof x == 'array' - mistake that makes it so
hard to recognise? That if so many have made it there must be something
in it? Unquestioning trust in the people they copied their mistakes from?

Probably. Judging from their rate of adoption of my many suggestions
(they are actually starting to scavenge some of them now, copying and
pasting without any real understanding), they trust unknown incompetents
more than they trust me. Like I said, nuts.

 

[David Mark]

That's what I said, but the "cutting edge JS hackers" couldn't come up
with anything more than griping.


Of course. But I don't think they have read the specs. In their minds,
there might be a browser out there that does this because that dubious
comparison must have been included for some reason.


In short, they are nuts. I don't know how else to explain their
behavior in this regard (among many others). Their latest and
"greatest" Website, which will ostensibly spur new interest in their
project uses jQuery (1.2x no less) for God's sake.

Another example is that when somebody posted some random numbers that
seemed (to them) to indicate that undeclared globals were "faster", a
chain reaction started that came within an inch of committing changes
that would un-declare all of their globals. (!) They were all very
hyped up about this "breakthrough", which was seen as a counterpoint to
the various speed improvements I introduced in my branch (which they
sullenly dismissed by posting still more random numbers).

I finally headed that one off at the Trac-level by pointing out that the
aforementioned random numbers didn't indicate that at all (as well as
the fact that using undeclared variables was insane and could easily
lead to major problems in one of the browsers they profess to care about).

They had actually closed the ticket. I had to re-open and invalidate it
(more than once). Looking back, I should have left them to
self-destruct. They are bitchy about any suggestions from me to this
day. They just don't like to hear from people who expose too many
mistakes. After all, if there are that many mistakes to be found, it
might call into "question" their self-described "expert" status. They
seem to care far more about their public image (and egos) than their users.

http://bugs.dojotoolkit.org/ticket/10174

Don't read it while eating, drinking and/or operating a motor vehicle.