JSLint Reports on last 2 Production Versions of jQuery

[David Mark]

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.

OMFG. Just noticed that they did actually follow through with this,
despite the invalidated ticket. Oh well, I'm not re-opening any more
tickets for a bunch of self-destructive malcontents.

Be warned, the lights may appear to be on over there, but nobody is home.

 

[David Mark]

Thanks for the explanation. I agree that it's a bad idea to rely on the
side effects of a property access. Apart from the style and the JSLint
warning, a script engine or a minifier might decide that the line is
just empty ballast, and skip it.

Exactly. I once had to do something similar in a widget to force a
re-calculation of offsetHeight/Width and it turned out that it required
an assignment (or something like that) to take effect in all of the
browsers that displayed the delayed update.

Somehow this never came up on the pages I worked with - probably because
I never tried to read a SELECT before the DOM was ready, and when I've
got a SELECT which isn't part of the document, I usually know in advance
which option will be selected. We also rarely write the <select> ...
</select> HTML by hand; it's almost always generated by some method (or
TagLib) which ensures that one of the options has a 'selected' attribute.

Yes, it's one of those very rare things that is inexplicably taking up
space in a library that can't deal with very common problems. The thing
gets cobbled together one observation (often accompanies by a
misinterpretation) at a time. At that rate, maybe they will fill in the
remaining pieces to the MSHTML "puzzle" by 2020.

 

[lorlarz]

lorlarz meinte:


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

Gregor

--http://www.gregorkofler.com

It is just this stinkin' regular expression stuff I had
to comment out a couple days ago which I would still
like to hear about: (What are the 'big problems' JSLint
sees with these and how do you fix them correctly,
maintaining the full intended meaning??):




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


parts.push( m[1] );


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


and





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


and





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

 

[Antony Scriven]

[...]

It is just this stinkin' regular expression stuff I had
to comment out a couple days ago which I would still
like to hear about: (What are the 'big problems' JSLint
sees with these and how do you fix them correctly,
maintaining the full intended meaning??):

Looks to me like the big problems are just style warnings.
Though in a large project bad style can become a problem
over time.

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

parts.push( m[1] );

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

Probably complaining about the comma used as an operator.
Good advice, I'd say.

and

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

and

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

JSLint is, IMHO, too zealous with its treatment of regexps.
Try escaping the '='s. I think the theory behind this is to
prevent human parsers from confusing the start of the regexp
with the /= operator.

These issues are mentioned, albeit tersely, in the
instructions. I'm also assuming you had all options cleared
since you haven't specified otherwise. --Antony

 

[lorlarz]

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

That's good news.

Quoting a recent post from John Resig to the
grouphttp://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/950b5d64a27994db1697eb4e605f5e...

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

[snip]

Stephan, While we do have all this good news (really a super awesome
response from John Resig), the production version and development
version provided in downloads on http://jquery.com still TODAY is the
one
I ran through JSLint a couple days ago when I started this thread.
Thus, the jQuery versions now made available are not yet JSLint
compliant.

I believe, though, we should show reasonable patience. John et al
may want to make very sure all is done right. John Resig's
response to JSLint has basically been magnificent. I do not know
how long one should wait for the updated production version before
becoming worried. (All these guys do work for free, but I do hope
to see an update soon.)

 

[lorlarz]

 > [...]
 >
 > It is just this stinkin' regular expression stuff I had
 > to comment out a couple days ago which I would still
 > like to hear about: (What are the 'big problems' JSLint
 > sees with these and how do you fix them correctly,
 > maintaining the full intended meaning??):

Looks to me like the big problems are just style warnings.
Though in a large project bad style can become a problem
over time.

 >     /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !==
null ) {
 >         soFar = m[3];
 >
 >         parts.push( m[1] );
 >
 >         if ( m[2] ) {
 >             extra = m[3];
 >             break;
 >         }
 >     }
 >     */

Probably complaining about the comma used as an operator.
Good advice, I'd say.

 > and
 >
 > // replace(/=([^="'>\s]+\/)>/g, '="$1">')
 >
 > and
 >
 > // jsre = /=\?(&|$)/,

JSLint is, IMHO, too zealous with its treatment of regexps.
Try escaping the '='s. I think the theory behind this is to
prevent human parsers from confusing the start of the regexp
with the /= operator.

These issues are mentioned, albeit tersely, in the
instructions. I'm also assuming you had all options cleared
since you haven't specified otherwise. --Antony

Anthony

I checked all the checkboxes in the 2nd of the three columns of
checkboxes when I ran JSLint.

While you did explain how to fix one of the two types of problems
in the reg expressions, you did not say how to fix that comma
problem. I hope someone can provide that fix.

 

[lorlarz]

 > [...]
 >
 > It is just this stinkin' regular expression stuff I had
 > to comment out a couple days ago which I would still
 > like to hear about: (What are the 'big problems' JSLint
 > sees with these and how do you fix them correctly,
 > maintaining the full intended meaning??):

Looks to me like the big problems are just style warnings.
Though in a large project bad style can become a problem
over time.

 >     /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !==
null ) {
 >         soFar = m[3];
 >
 >         parts.push( m[1] );
 >
 >         if ( m[2] ) {
 >             extra = m[3];
 >             break;
 >         }
 >     }
 >     */

Probably complaining about the comma used as an operator.
Good advice, I'd say. [snip]
--Antony

It makes no sense to me that
(chunker.exec(""), m = chunker.exec(soFar)) could be
an expression evaluated as equivalent to null or not OR
VIA !== and thus it makes no sense to me that
((chunker.exec(""), m = chunker.exec(soFar)) !== null )
could be a condition for the while loop, BUT that is
what is happening in the present jQuery code.

What are they trying to do? What are they doing? How
can it be rewritten so JSLint will accept it??

 

[lorlarz]

[...]

It is just this stinkin' regular expression stuff I had
to comment out a couple days ago which I would still
like to hear about: (What are the 'big problems' JSLint
sees with these and how do you fix them correctly,
maintaining the full intended meaning??):

Looks to me like the big problems are just style warnings.
Though in a large project bad style can become a problem
over time.

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

parts.push( m[1] );

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

Probably complaining about the comma used as an operator.
Good advice, I'd say. [snip]
--Antony

It makes no sense to me that
(chunker.exec(""), m = chunker.exec(soFar)) could be
an expression evaluated as equivalent to null or not
VIA !== and thus it makes no sense to me that
((chunker.exec(""), m = chunker.exec(soFar)) !== null )
could be a condition for the while loop, BUT that is
what is happening in the present jQuery code.

What are they trying to do? What are they doing? How
can it be rewritten so JSLint will accept it??

 

[Richard Cornford]

On Mar 2, 6:06 pm, lorlarz wrote:

It makes no sense to me that
(chunker.exec(""), m = chunker.exec(soFar)) could be
an expression evaluated as equivalent to null or not
VIA !==

What does that have to do with anything (that is both your inability
to understand it and comparisons with null)?

and thus it makes no sense to me that
((chunker.exec(""), m = chunker.exec(soFar)) !== null )
could be a condition for the while loop, BUT that is
what is happening in the present jQuery code.

The behaviour of comma operators is known and predictable.

What are they trying to do? What are they doing?

Regular expressions retain some state between uses. Specifically, they
retain there - lastIndex - properties. When a regular expression does
not have the global flag set then the - exec - uses the index of the
last match as the - lastIndex - property's value. This allows the use
of the - exec - (or - test -) methods in - while - loops, where the
body of the loop examines each successive match, without the whole
going back and re-matching previous sections of the input.

This behaviour is very poorly understood by the vast majority of
'javascript developers' and there are a huge number of mystical
incantations that are employed in order to 'work around' it. This
appears to be an example of one of them as a side effect of calling -
exec - on an empty string will be to have the - lastIndex - property
of the regular expression re-set to zero.

The most direct (and very probably fastest) way of setting the -
lastIndex - property of a regular expression to zero is to assign zero
to the property. However, in most cases the use of - exec - with a
regular expression with the global flag set is inappropriate to start
with (as - exec - stops at the first successful match, which is what a
non-global flagged regular expression would do) and so the issue can
be fully mitigated by removing the global flag.

So it may be the case that you 'fix' JQuery by removing the global
flag from chunker's regular expression literal definition and then
delete the - chunker.exec("") -, the comma and the following space
from the expression above.

How
can it be rewritten so JSLint will accept it??

Probably as I just described above.

Richard.

 

[lorlarz]

    // Reset the position of the chunker regexp (start from head)
    do {
        chunker.exec("");
        m = chunker.exec(soFar);

        if ( m ) {
            soFar = m[3];

            parts.push( m[1] );

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

That should make it easier to read and understand.

http://github.com/jeresig/sizzle/blob/master/sizzle.js#L41

Excellent. Thanks stefan. Now I can report the following:

I now have to comment out _nothing_:

With ALL the things ('big errors') that stopped the JSLint scan
of the _present_ development and production versions of jQuery 1.4.2
(which are presently provided via http://jquery.com _and_ will be
for at least a month) _replaced_ with for-certain valid replacement:

The exact same JSLint error set which I last listed in this thread
STILL HOLDS TRUE for this (the current, present) production release
of jQuery (that is jQuery 1.4.2)

I have every reason to expect that any of the problems of real
concern
will be fixed in jQuery 1.4.3 , being released in late March or
April. This is what John Resig says for the expected date of
jquery 1.4.3 (where the concerns will be addressed ),
will likely be released.

It is still important for people to be aware of the present status of
things -- in case things are of concern to them, doing there own
assessment and evaluation of the JSLint error (on the full valid 100%
scan).

 

[lorlarz]

On Mar 2, 6:06 pm, lorlarz wrote:



What does that have to do with anything (that is both your inability
to understand it and comparisons with null)?


The behaviour of comma operators is known and predictable.


Regular expressions retain some state between uses. Specifically, they
retain there - lastIndex - properties. When a regular expression does
not have the global flag set then the - exec - uses the index of the
last match as the - lastIndex - property's value. This allows the use
of the - exec - (or - test -) methods in - while - loops, where the
body of the loop examines each successive match, without the whole
going back and re-matching previous sections of the input.

This behaviour is very poorly understood by the vast majority of
'javascript developers' and there are a huge number of mystical
incantations that are employed in order to 'work around' it. This
appears to be an example of one of them as a side effect of calling -
exec - on an empty string will be to have the - lastIndex - property
of the regular expression re-set to zero.

The most direct (and very probably fastest) way of setting the -
lastIndex - property of a regular expression to zero is to assign zero
to the property. However, in most cases the use of - exec - with a
regular expression with the global flag set is inappropriate to start
with (as - exec - stops at the first successful match, which is what a
non-global flagged regular expression would do) and so the issue can
be fully mitigated by removing the global flag.

So it may be the case that you 'fix' JQuery by removing the global
flag from chunker's regular expression literal definition and then
delete the - chunker.exec("") -, the comma and the following space
from the expression above.


Probably as I just described above.

Richard.

I thank you very much for your most learnied input, Richard.

stefan provided the fix that Resig provided in last night's
official "fix list" -- and I used that
instead of commenting out the block to do the JSLint scan of
the jQuery 1.4.2 code I just did (and referred to in my last post).

I have not fully figured out your response, but I do ask whether
you see the Resig fix as the fix that would indeed not only make
JSLint
happy (which it did), but indeed provide intended (equivalent?) code.

It may be of interest to know that the fix from the "fix list" Resig
apparently provided _also_ does _not_ appear in last night's
"dailies". Apparently the daily are not JSLint fixed. Just
for everyones information.

 

[Garrett Smith]

lorlarz wrote:
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.

What do you mean by argument name? Variable name?

I saw undefined used as a variable name. The reasons were given so that
it would be munged and would be faster lookup.

[...]

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

undefined is not ReadOnly so I don't know if an optimization would be
possible. Recent Mozilla's (Tracemonkey engine) have optimization for
global access. Future version will probably include optimized closure
access.

https://bugzilla.mozilla.org/show_bug.cgi?id=517164

[...]

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?

ASI = Automatic Semicolon Insertion. If the JSON response begins with a
line terminator.

For example, the responseText is - "\n { name : "milo" }" - then the
function body would be

| function()}
| return
|
| { name : "milo" }
| }

ASI would result in the functionBody being reduced to:

| function()}
| return;
|
| { name : "milo" };
| }

And the result o f calling that function would be to return `undefined`
and not the object.

So it's safer to to use grouping operator there.

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

I disagree. I think modifying Object.prototype causes the problem. By
not doing that, filters on for-in loops can be avoided. The filters add
more clutter and slow the loop down anyway.

[...]

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).


I do the exact opposite. Why use strict if you don't have to?

If == is used, the reader has to consider type conversion issues. For
example:

* if(x == 0) ...
* if(x == "object") ...

What are acceptable values for x there? What if x is an Object or false?
It might be that the caller passing objects or booleans should never
happen; that doing so would be a mistake, but then if === is used then
there is no question.

By using strict equality in those tests, there is no ambiguity.

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).

The strict comparison is only true when the values are the same type.
The loose comparisons can be true of the values are of different type.
If the reader wants to know what the real intention of that line of code
(without looking at other parts), then === tells that. Now with a test
inline like:-

typeof x == "object"

- there is no ambiguity because typeof operator results are always
string values.


However with:
x == "object"


Out of context, it is not clear if x is going to be a string or a String.

[...]

Buffoons. I tried to tell them that was ridiculous, but they just
carped about providing "proof" (and something about ad hominem attacks).

"Ridiculous" is a matter of opinion. Fact: It is useless code which is
downloaded along with the rest of Dojo. Useless code should be removed.
So far nobody has questioned that principle.

It shows that they did not know what they were doing.

If they've been made aware of the useless code (and apparently you did
that), then they should probably want to fix it immediately. I know I would.

Do they expect their clients to not recognize it for what it is? Why
would anyone who knows better use that, knowing that the general
userbase is using it out of ignorance?

[...]

 

[lorlarz]

Garrett Smith wrote:

[snip]

Buffoons.  I tried to tell them that was ridiculous, but they just
carped about providing "proof" (and something about ad hominem attacks)..

"Ridiculous" is a matter of opinion. Fact: It is useless code which is
downloaded along with the rest of Dojo. Useless code should be removed.
So far nobody has questioned that principle.

It shows that they did not know what they were doing.

If they've been made aware of the useless code (and apparently you did
that), then they should probably want to fix it immediately. I know I would.

Do they expect their clients to not recognize it for what it is?  Why
would anyone who knows better use that, knowing that the general
userbase is using it out of ignorance?

[...]

I really do not think it is appropriate to discuss the
Dojo library in a jQuery thread. Things are plenty confusing
enough without mixing critiques of different libraries in the
same thread.

 

[Antony Scriven]

[...]

On the other hand, even with that simplification the code
that remains seems overly convoluted to me, so I would
bet that the attention of someone with a real
understanding of javascript regular expressions, and
their use in the language (Lasse would be my optimum
candidate for this), could achieve the same outcome
significantly more simply.

[...]

The code was:

// Reset the position of the chunker regexp (start from head)
do {
chunker.exec("");
m = chunker.exec(soFar);

if ( m ) {
soFar = m[3];

parts.push( m[1] );

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

And, unless I'm missing something, which is quite
likely without more context, this looks like a very
roundabout way of writing:

var split = soFar.split(/subexpr2/);
var chunked = {
parts: split[0].match(/subexpr1/g),
extra: split[1]
};

--Antony

 

[Antony Scriven]

[...]

On the other hand, even with that simplification the code
that remains seems overly convoluted to me, so I would
bet that the attention of someone with a real
understanding of javascript regular expressions, and
their use in the language (Lasse would be my optimum
candidate for this), could achieve the same outcome
significantly more simply.

[...]

The code was:

// Reset the position of the chunker regexp (start from head)
do {
chunker.exec("");
m = chunker.exec(soFar);

if ( m ) {
soFar = m[3];

parts.push( m[1] );

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

And, unless I'm missing something, which is quite
likely without more context, this looks like a very
roundabout way of writing:

var split = soFar.split(/subexpr2/);
var chunked = {
parts: split[0].match(/subexpr1/g),
extra: split[1]
};

--Antony

 

[Peter Michaux]

The real problems with jQuery can't be found by JSLint, because they
are logic and algorithm problems. This simply attempt to solve the
problem in the wrong way. Even if the syntax was correct and passed
JSLint 100%, the logic would still be in error.

The question of whether or not to use jQuery is a cost/benefit
analysis. Sadly, most people using it (IMO) over-estimate the benefit
and are not even capable of understanding the cost.

Which is not to say that you cannot understand each and still decide
to use jQuery. I do. In some situations, for some tasks.

In the past, I seem to remember you weighting the benefits of using
jQuery heavier almost to the point of advocating it was a good idea to
use jQuery. Am I remembering incorrectly or have your opinions of
jQuery deteriorated over time?

What are you using when jQuery is not a good fit?

Peter

 

[David Mark]

David Mark wrote:
lorlarz wrote:
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.

What do you mean by argument name? Variable name?

What do you think I meant?

I saw undefined used as a variable name. The reasons were given so that
it would be munged and would be faster lookup.

It's still a stupid name.

[...]

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

undefined is not ReadOnly so I don't know if an optimization would be
possible. Recent Mozilla's (Tracemonkey engine) have optimization for
global access. Future version will probably include optimized closure
access.

https://bugzilla.mozilla.org/show_bug.cgi?id=517164

[...]

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?

ASI = Automatic Semicolon Insertion. If the JSON response begins with a
line terminator.
Yes.


For example, the responseText is - "\n { name : "milo" }" - then the
function body would be

| function()}
| return
|
| { name : "milo" }
| }

ASI would result in the functionBody being reduced to:

| function()}
| return;
|
| { name : "milo" };
| }

And the result o f calling that function would be to return `undefined`
and not the object.

So it's safer to to use grouping operator there.

Okay, but it that is not how your example reads.

Typo, BTW.

I disagree. I think modifying Object.prototype causes the problem.

It does not matter what "causes" the problem (as if either side can be
given more weight). The fact exists that the problem is out there on
the Web.

By
not doing that, filters on for-in loops can be avoided. The filters add
more clutter and slow the loop down anyway.

That's self-evident, but still bad advice.

[...]

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).


I do the exact opposite. Why use strict if you don't have to?

If == is used, the reader has to consider type conversion issues. For
example:

No, I think it is the exact opposite. If === is used, the reader has to
wonder why the hell it was used (i.e. are the two sides not the same type?)

* if(x == 0) ...
* if(x == "object") ...

What are acceptable values for x there? What if x is an Object or false?
It might be that the caller passing objects or booleans should never
happen; that doing so would be a mistake, but then if === is used then
there is no question.

By using strict equality in those tests, there is no ambiguity.

Yes there is (for the reader of the code). Why use === if there is no
logical requirement for it?

The strict comparison is only true when the values are the same type.
The loose comparisons can be true of the values are of different type.

That's why you use === when necessary, which makes your intentions clear.

If the reader wants to know what the real intention of that line of code
(without looking at other parts), then === tells that. Now with a test
inline like:-

No, I think you have it backwards. It could just be that the author of
that line of code was copying and pasting. The == implies that both
sides of the comparison are the same type.

typeof x == "object"

- there is no ambiguity because typeof operator results are always
string values.

Exactly, and this whole discussion started because of similar code that
used === (which makes me stop and wonder what the author was thinking,
at least for a moment).

However with:
x == "object"


Out of context, it is not clear if x is going to be a string or a String.

If it is ==, then string should be assumed. If the two operators are
used consistently, there is no need to investigate further. Of course,
if they are used haphazardly (as in jQuery), you have to scrutinize
every line.

[...]

Buffoons. I tried to tell them that was ridiculous, but they just
carped about providing "proof" (and something about ad hominem attacks).

"Ridiculous" is a matter of opinion.

I wrote a long post about it. "Ridiculous" is just the synopsis. I
explained _exactly_ why it was wrong, but they wanted "proof" that it
did not work in "all browsers" (try wrapping your brain around that one!)

Fact: It is useless code which is
downloaded along with the rest of Dojo. Useless code should be removed.
So far nobody has questioned that principle.

They have lots of useless code and plenty of useless "programmers"
arguing for it to stay.

It shows that they did not know what they were doing.

Yes, exactly. But the project advertises "unbeatable" JS.

If they've been made aware of the useless code (and apparently you did
that), then they should probably want to fix it immediately. I know I
would.

They don't like to change anything in the core as they don't seem to
understand much of it. I ran into the same sort of attitude when I
pointed out that their attr/removeAttr were worse than jQuery's.

Do they expect their clients to not recognize it for what it is?

I really don't think they realize that it is wrong.

Why
would anyone who knows better use that, knowing that the general
userbase is using it out of ignorance?

Why would anyone in their right mind use Dojo? Mass hysteria?

 

[David Mark]

Garrett Smith wrote: [snip]
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).

"Ridiculous" is a matter of opinion. Fact: It is useless code which is
downloaded along with the rest of Dojo. Useless code should be removed.
So far nobody has questioned that principle.

It shows that they did not know what they were doing.

If they've been made aware of the useless code (and apparently you did
that), then they should probably want to fix it immediately. I know I would.

Do they expect their clients to not recognize it for what it is? Why
would anyone who knows better use that, knowing that the general
userbase is using it out of ignorance?

[...]

I really do not think it is appropriate to discuss the
Dojo library in a jQuery thread. Things are plenty confusing
enough without mixing critiques of different libraries in the
same thread.

Coincidentally, the Dojo contributors used to complain about thread
compartmentalization as well. But I insisted that was the last thing
they should have been worried about. I don't think you should worry
about it either.

 

[Matt Kruse]

In the past, I seem to remember you weighting the benefits of using
jQuery heavier almost to the point of advocating it was a good idea to
use jQuery. Am I remembering incorrectly or have your opinions of
jQuery deteriorated over time?

My opinion of jQuery has deteriorated, yes. I don't care so much about
the attr() problems that DM repeatedly points out, but other things
worried me more.

For example, the response to the selectedIndex discussion really
highlighted the skewed perspective the core developers have when
trying to solve problems "correctly".

Also, I'm seeing more and more people write things "the jQuery way"
and ending up with extremely inefficient code. I've spent too much
time going back and un-jquery-ifying code to speed it up.

Finally, the recent discussion about jquery's xhr implementation kind
of blew me away:
http://groups.google.com/group/jquery-dev/browse_frm/thread/5e63ab0adf17aabc

I hadn't really questioned why jQuery polled the ajax response rather
than triggering based on state changes, but I assumed they had some
reason. At least it still worked. It turns out that they just didn't
know how to fix a memory leak in IE. And when it was pointed out, he
initially made a change that showed he really didn't understand scope
chains and how leaks are created. And in the second issue in the
thread, his quick fixes to the logic were incorrect and needed to be
pointed out. I'm not sure he really grasped what was needed or how to
construct the logical tests. Yet he was very hasty in making fixes and
committing them into the source. Sure seems like development on a
whim. No wonder they release so many versions, and always have quick
minor updates after big releases to patch the holes.

Finally finally, they keep changing the API, removing methods, adding
methods, etc. Seemingly at random, depending on their latest design
ideas. It's a big moving target that wanders around as they get
flashes of inspiration about things that were done well and documented
years ago.

What are you using when jQuery is not a good fit?

I am using more and more of my own code, which is a bummer. It's more
robust and faster, but it takes longer to create and it doesn't get as
much testing as a public, open-source library that is heavily used
across the web would get. Javascript is a very minor part of what I
do, so I can't focus on doing it the way I really would like.

But having said all that, I want to say again that I still use jQuery
and recommend it.

These criticisms are really coming from very experienced js developers
who understand all the fine points of the language and implementation.
jQuery is a good product for the common Joe Coder, but it will _never_
meet the standards of those who are the true wizards of the language.
I don't expect it to.

jQuery is good for simple stuff, grabbing elements by selectors, doing
things like hiding and showing and animating, etc. That's what I
mostly use it for, and that's what I recommend it for. I never
recommend writing complex interfaces "in jQuery". I may fall back to
its selector engine, and I may add my own methods that are optimized
to do what I want, but I don't use the UI components or almost any of
the 3rd-party plugins. I don't do things "the jQuery way". I don't
focus on writing dense code but instead code that is logical and easy
to read and understand.

jQuery is javascript for the masses. And it's great for that, IMO.
Once you progress beyond that and learn more, you will naturally see
its flaws. Then you'll move to something else. Which is great! jQuery
is the first step for most people. Without it, they may not move up at
all. It serves its purpose, even if imperfect.

Matt Kruse

 

[David Mark]

My opinion of jQuery has deteriorated, yes. I don't care so much about
the attr() problems that DM repeatedly points out, but other things
worried me more.

Then you really don't understand how these selector engines work. In a
word, poorly.

For example, the response to the selectedIndex discussion really
highlighted the skewed perspective the core developers have when
trying to solve problems "correctly".

Sheesh. Who sent you on _that_ errand of mercy? You were ready to
suggest some similar BS hack.

Also, I'm seeing more and more people write things "the jQuery way"
and ending up with extremely inefficient code.

And how many times have I warned you about _that_. Are you really
suggesting that I only ever mentioned attr and you came up with these
new theories on your own? LOL.

I've spent too much
time going back and un-jquery-ifying code to speed it up.

Yes, there is a whole industry springing up around fixing bad
library-laden scripts.

Finally, the recent discussion about jquery's xhr implementation kind
of blew me away:
http://groups.google.com/group/jquery-dev/browse_frm/thread/5e63ab0adf17aabc

I don't even want to know. Enough is enough (and has been for years).
IIRC, it does some sort of ridiculous polling.

I hadn't really questioned why jQuery polled the ajax response rather
than triggering based on state changes, but I assumed they had some
reason.


At least it still worked. It turns out that they just didn't
know how to fix a memory leak in IE. And when it was pointed out, he
initially made a change that showed he really didn't understand scope
chains and how leaks are created. And in the second issue in the
thread, his quick fixes to the logic were incorrect and needed to be
pointed out. I'm not sure he really grasped what was needed or how to
construct the logical tests. Yet he was very hasty in making fixes and
committing them into the source. Sure seems like development on a
whim. No wonder they release so many versions, and always have quick
minor updates after big releases to patch the holes.

Glad you could finally see the light. But why did it take this last
debacle to put you over the edge?

Finally finally, they keep changing the API, removing methods, adding
methods, etc. Seemingly at random, depending on their latest design
ideas.

Ah, back to my greatest hits.

It's a big moving target that wanders around as they get
flashes of inspiration about things that were done well and documented
years ago.

They did something well? Name it.

I am using more and more of my own code, which is a bummer.

Well, you wrote it.

It's more
robust and faster, but it takes longer to create and it doesn't get as
much testing as a public, open-source library that is heavily used
across the web would get.

But as you've seen, the testing hasn't led to anything good as the
authors can't really interpret the tests. We've been over this too.

Javascript is a very minor part of what I
do, so I can't focus on doing it the way I really would like.

You would really like to use CSS selector queries? Too bad as they are
not practical at all.

But having said all that, I want to say again that I still use jQuery
and recommend it.

As usual, you are loopy.

These criticisms are really coming from very experienced js developers
who understand all the fine points of the language and implementation.

And you.

jQuery is a good product for the common Joe Coder, but it will _never_
meet the standards of those who are the true wizards of the language.
I don't expect it to.

No, it is a horrible idea for Joe Coder, who needs things to be
simplified, not overly complicated (not to mention unpredictable). How
can you write this after what you wrote above?

jQuery is good for simple stuff, grabbing elements by selectors,

It is horrible for that and that's all it really does.

doing
things like hiding and showing and animating, etc.

The animations have always been sub-standard (and ugly as hell on older
or lesser PC's, phones, etc.)

That's what I
mostly use it for, and that's what I recommend it for.

You really are insane.

I never
recommend writing complex interfaces "in jQuery". I may fall back to
its selector engine, and I may add my own methods that are optimized
to do what I want, but I don't use the UI components or almost any of
the 3rd-party plugins.

Of course not. The add-ons are famously awful. And those were/are a
big "selling point", at least among shills.

I don't do things "the jQuery way".

Horribly inefficent? Buggy as hell? Slow? What is their one way?

I don't
focus on writing dense code but instead code that is logical and easy
to read and understand.

And you don't need jQuery for that.

jQuery is javascript for the masses.

NO. It isn't. It's a lousy script that makes browser scripting much
more difficult than it needs to be. Why would the masses clamor for that?

And it's great for that, IMO.
Nuts.

Once you progress beyond that and learn more, you will naturally see
its flaws. Then you'll move to something else. Which is great!

So you are now using My Library?

jQuery
is the first step for most people. Without it, they may not move up at
all. It serves its purpose, even if imperfect.

The first trip you mean (and it is invariably a bad one). And its only
purpose seems to be to discourage people from learning JS and browser
scripting.