JSLint Reports on last 2 Production Versions of jQuery
lorlarz
on JSLint
( http://www.jslint.com/ )
1.4.2 ,new jQuery production version (compared to the last 'production
version', 1.3.2).
The new one seems to have about
20% more errors _and_, more importantly, seems (to me) to have more
serious errors.
**I need more opinions.**
I have a zip on my web site containing:
jQuery 1.4.2 all on one line, comments left out
jQuery 1.3.2 all on one line, comments left out
The JSLint report on each (clearly labeled).
This zip is at: http://mynichecomputing.org/JSLintCompare.zip .
Download it an unzip and
take a look.
Frankly, I used to be unconcerned about the JSLint errors in 1.3.2
_but_ really do most certainly
_not_ know whether it would be reasonable to be not concerned about
some of the errors shown
by 1.4.2 .
Is it as bad as it looks? Is the credibility of the newest jQuery core
production release
on the line? Or, at least in part, should the credibility of JSLint be
wondered about?
John Resigs position: (quoting directly):
"Doesn't worry me at all - we don't follow JSLint and it's obsessively
strict style guidelines"
David Mark
> Results of jQuery new production version and last production version
> on JSLint
> ( http://www.jslint.com/ )
>
> 1.4.2 ,new jQuery production version (compared to the last 'production
> version', 1.3.2).
How can you release a production version of a script for Websites once a
month? I can't understand how people can see that as sane.
> The new one seems to have about
> 20% more errors _and_, more importantly, seems (to me) to have more
> serious errors.
They've never been close on that. They really need to worry about their
bogus _logic_ before the style. In contrast, the full build of My
Library has 6 or 7 flagged lines in roughly 10,000 (and two of them are
Function constructor is eval). :)
>
> **I need more opinions.**
>
>
> I have a zip on my web site containing:
>
> jQuery 1.4.2 all on one line, comments left out
> jQuery 1.3.2 all on one line, comments left out
Don't bother running the minified versions through. That won't be
productive. Use the full versions.
> The JSLint report on each (clearly labeled).
>
> This zip is at: http://mynichecomputing.org/JSLintCompare.zip .
> Download it an unzip and
> take a look.
>
> Frankly, I used to be unconcerned about the JSLint errors in 1.3.2
> _but_ really do most certainly
> _not_ know whether it would be reasonable to be not concerned about
> some of the errors shown
> by 1.4.2 .
It indicates sloppiness and makes it impossible for them to use such a
tool to catch obvious mistakes like typos (which is a definite concern).
When I was rewriting Dojo, I ran every file through JSLint and found
(and fixed) lots of typos, undeclared variables, etc. It's funny,
because a few months later, there was a movement to un-declare _all_ of
their globals as somebody had posted some meaningless numbers that
seemed to indicate to them that Dojo would run _faster_ that way. They
have a lint that runs on check-ins, but they all bypass it every time
with a !strict directive. :(
>
> Is it as bad as it looks? Is the credibility of the newest jQuery core
> production release
> on the line?
They never _had_ any credibility. And, as documented to death, their
logic is largely bunk, so it would hardly matter if it were packaged as
stylish code.
> Or, at least in part, should the credibility of JSLint be
> wondered about?
No, JSLint may be overbearing (but is configurable of course), but it is
quite credible.
>
> John Resigs position: (quoting directly):
> "Doesn't worry me at all - we don't follow JSLint and it's obsessively
> strict style guidelines"
They don't follow anything but delusions. And I've noticed a
correlation between bad coders and the misuse of its/it's. There seems
to be a pattern there, but the data is not conclusive (kind of like the
implied global/fast code theory).
Try their raw version and see how that does. I predict it will be
better, but still won't come close to finishing the verification process.
lorlarz
> lorlarz wrote:
> > Results of jQuery new production version and last production version
When I send the non-minimized version through, only 41% gers scanned,
though
the 'errors' do look a lot more benign. I wish I could get the whole
thing
through.
I have noticed a trend to. It's not certain but many JS programmers
seem to
be meaner than junk yard dog, whether they/it know their/its butt from
a hole
in the ground or not.
rf
"lorlarz" <lor...@gmail.com> wrote in message
news:20592e13-21c3-4e14...@z11g2000yqz.googlegroups.com...
Good luck getting your next question answered.
lorlarz
> > Results of jQuery new production version and last production version
> > on JSLint
> > (http://www.jslint.com/)
>
> Don't bother running the minified versions through. That won't be
> productive. Use the full versions.
>
I commented out a couple of regular expression things JSLint could not
stand and
made what I saw as about a half dozen corrections AND was able to run
all the
non-minimized _WITH_ COMMENTS REMOVED jQuery 1.4.2 through JSLint and
get
a full report. Looks quite benigh (though there were the half dozen
errors and
a couple or regular expressions commented out). Here is the report
AFTER those
changes: Most, _though NOT all_ of the report, look benign AFTER all
that:
Error:
Problem at line 1 character 20: Expected an identifier and instead saw
'undefined' (a reserved word).
(function( window, undefined ) {
Problem at line 13 character 48: Unescaped '-'.
quickExpr = /^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/,
Problem at line 33 character 20: 'hasOwnProperty' is a really bad
name.
hasOwnProperty = Object.prototype.hasOwnProperty,
Problem at line 145 character 20: Use '===' to compare with 'null'.
return num == null ?
Problem at line 261 character 41: Use '!==' to compare with 'null'.
if ( (options = arguments[ i ]) != null ) {
Problem at line 356 character 48: Use '===' to compare with 'null'.
toplevel = window.frameElement == null;
Problem at line 488 character 20: Use '!==' to compare with 'null'.
if ( array != null ) {
Problem at line 489 character 31: Use '===' to compare with 'null'.
if ( array.length == null || typeof array === "string" ||
jQuery.isFunctio...
Problem at line 536 character 18: Confusing use of '!'.
if ( !inv !== !callback( elems[ i ], i ) ) {
Problem at line 536 character 18: Confusing use of '!'.
if ( !inv !== !callback( elems[ i ], i ) ) {
Problem at line 550 character 24: Use '!==' to compare with 'null'.
if ( value != null ) {
Problem at line 593 character 4: Mixed spaces and tabs.
[];
Problem at line 689 character 21: Missing '()' invoking a constructor.
return (new Date).getTime();
Problem at line 753 character 13: 'e' is already defined.
} catch(e) {
Problem at line 1270 character 28: Expected an assignment or function
call and instead saw an expression.
parent.selectedIndex;
Problem at line 1273 character 43: Expected an assignment or function
call and instead saw an expression.
parent.parentNode.selectedIndex;
Problem at line 1362 character 55: 'eventHandle' is already defined.
eventHandle = elemData.handle, eventHandle;
Problem at line 1471 character 106: Missing semicolon.
jQuery.map( namespaces.slice(0).sort(), fcleanup ).join("\\.(?:.*\
\.)?")...
Problem at line 1495 character 25: 'j' is already defined.
for ( var j = pos || 0; j < eventType.length; j++ ) {
Problem at line 1500 character 34: Use '===' to compare with 'null'.
if ( pos == null ) {
Problem at line 1509 character 30: Use '!==' to compare with 'null'.
if ( pos != null ) {
Problem at line 1515 character 48: Use '!==' to compare with 'null'.
if ( eventType.length === 0 || pos != null && eventType.length === 1 )
{
Problem at line 1619 character 26: 'e' is already defined.
} catch (e) {}
Problem at line 1633 character 30: Bad assignment.
event = arguments[0] = jQuery.event.fix( event || window.event );
Problem at line 1644 character 20: 'events' is already defined.
var events = jQuery.data(this, "events"), handlers =
events[ event.type ];
Problem at line 1644 character 60: 'handlers' is already defined.
var events = jQuery.data(this, "events"), handlers =
events[ event.type ];
Problem at line 1704 character 26: Use '===' to compare with 'null'.
if ( event.pageX == null && event.clientX != null ) {
Problem at line 1704 character 51: Use '!==' to compare with 'null'.
if ( event.pageX == null && event.clientX != null ) {
Problem at line 1955 character 19: Use '!==' to compare with 'null'.
if ( data != null || val ) {
Problem at line 2154 character 39: Use '!==' to compare with 'null'.
while ( (type = types[ i++ ]) != null ) {
Problem at line 2182 character 18: Don't make functions within a loop.
});
Problem at line 2190 character 6: Missing semicolon.
}
Problem at line 2283 character 56: Unescaped '['.
var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
[^'"]*['"]...
Problem at line 2283 character 81: Unescaped '['.
var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
[^'"]*['"]...
Problem at line 2347 character 21: 'ret' is already defined.
var ret = seed ?
Problem at line 2367 character 26: Use '===' to compare with 'null'.
if ( pop == null ) {
Problem at line 2383 character 23: 'cur' used out of scope.
Sizzle.error( cur || selector );
Problem at line 2390 character 42: Use '!==' to compare with 'null'.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2396 character 25: 'i' is already defined.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2396 character 42: Use '!==' to compare with 'null'.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2443 character 40: 'match' is already defined.
var type = Expr.order[i], match;
Problem at line 2452 character 26: Use '!==' to compare with 'null'.
if ( set != null ) {
Problem at line 2473 character 64: Use '!==' to compare with 'null'.
if ( (match = Expr.leftMatch[ type ].exec( expr )) != null &&
match[2] ) {
Problem at line 2498 character 58: Use '!==' to compare with 'null'.
for ( var i = 0; (item = curLoop[i]) != null; i++ ) {
Problem at line 2503 character 51: Use '!==' to compare with 'null'.
if ( inplace && found != null ) {
Problem at line 2534 character 27: Use '===' to compare with 'null'.
if ( anyFound == null ) {
Problem at line 2554 character 35: Unescaped '-'.
ID: /#((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
Problem at line 2555 character 39: Unescaped '-'.
CLASS: /\.((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
Problem at line 2556 character 48: Unescaped '-'.
NAME: /\[name=['"]*((?:[\w\u00c0-\uFFFF-]|\\.)+)['"]*\]/,
Problem at line 2557 character 41: Unescaped '-'.
ATTR: /\[\s*((?:[\w\u00c0-\uFFFF-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)
\3|)\s*...
Problem at line 2558 character 38: Unescaped '-'.
TAG: /^((?:[\w\u00c0-\uFFFF\*-]|\\.)+)/,
Problem at line 2559 character 65: Unescaped '-'.
CHILD: /:(only|nth|last|first)-child(?:\((even|odd|[\dn+-]*)\))?/,
Problem at line 2560 character 69: Unescaped '-'.
POS: /:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/,
Problem at line 2561 character 39: Unescaped '-'.
PSEUDO: /:((?:[\w\u00c0-\uFFFF-]|\\.)+)(?:\((['"]?)((?:\([^\)]+\)|[^\
(\)]*)...
Problem at line 2611 character 29: 'i' is already defined.
for ( var i = 0, l = checkSet.length; i < l; i++ ) {
Problem at line 2611 character 36: 'l' is already defined.
for ( var i = 0, l = checkSet.length; i < l; i++ ) {
Problem at line 2612 character 30: 'elem' is already defined.
var elem = checkSet[i];
Problem at line 2633 character 61: 'nodeCheck' used out of scope.
checkFn("parentNode", part, doneName, checkSet, nodeCheck, isXML);
Problem at line 2643 character 66: 'nodeCheck' used out of scope.
checkFn("previousSibling", part, doneName, checkSet, nodeCheck,
isXML);
Problem at line 2678 character 56: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = curLoop[i]) != null; i++ ) {
Problem at line 2758 character 29: Expected an assignment or function
call and instead saw an expression.
elem.parentNode.selectedIndex;
Problem at line 2771 character 20: Wrap the /regexp/ literal in parens
to disambiguate the slash operator.
return /h\d/i.test( elem.nodeName );
Problem at line 2801 character 20: Wrap the /regexp/ literal in parens
to disambiguate the slash operator.
return /input|select|textarea|button/i.test(elem.nodeName);
Problem at line 2841 character 29: 'i' is already defined.
for ( var i = 0, l = not.length; i < l; i++ ) {
Problem at line 2865 character 32: Expected a 'break' statement before
'case'.
node = elem;
Problem at line 2915 character 34: Use '!==' to compare with 'null'.
elem[ name ] != null ?
Problem at line 2922 character 27: Use '===' to compare with 'null'.
return result == null ?
Problem at line 2958 character 6: Don't make functions within a loop.
}));
Problem at line 2973 character 77: Expected an assignment or function
call and instead saw an expression.
Array.prototype.slice.call( document.documentElement.childNodes, 0 )
[0].node...
Problem at line 2987 character 29: 'i' is already defined.
for ( var i = 0; array[i]; i++ ) {
Problem at line 3070 character 34: Missing '()' invoking a
constructor.
id = "script" + (new Date).getTime();
Problem at line 3298 character 11: 'slice' is already defined.
slice = Array.prototype.slice;
Problem at line 3303 character 20: Confusing use of '!'.
return !!qualifier.call( elem, i, elem ) === keep;
Problem at line 3706 character 49: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = this[i]) != null; i++ ) {
Problem at line 3723 character 49: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = this[i]) != null; i++ ) {
Problem at line 3891 character 22: 'root' was used before it was
defined.
function root( elem, cur ) {
Problem at line 3990 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4049 character 25: 'i' is already defined.
for ( var i = 0; ret[i]; i++ ) {
Problem at line 4070 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4175 character 13: Function statements cannot be
placed in blocks. Use a function expression or move the statement to
the top of the outer function.
function getWH() {
Problem at line 4281 character 24: 'name' is already defined.
for ( var name in options ) {
Problem at line 4385 character 24: Use '===' to compare with 'null'.
return val == null ?
Problem at line 4542 character 41: Bad operand.
if ( s.global && ! jQuery.active++ ) {
Problem at line 4694 character 17: 'e' is already defined.
} catch(e) { }
Problem at line 4706 character 17: 'e' is already defined.
} catch(e) {
Problem at line 4725 character 26: 'complete' was used before it was
defined.
function complete() {
Problem at line 4739 character 25: 'trigger' is already defined.
function trigger(type, args) {
Problem at line 4828 character 29: 'buildParams' was used before it
was defined.
function buildParams( prefix, obj ) {
Problem at line 4838 character 45: Use '!==' to compare with 'null'.
} else if ( !traditional && obj != null && typeof obj === "object" ) {
Problem at line 4856 character 19: Unescaped '-'.
rfxnum = /^([+-]=)?([\d+-.]+)(.*)$/,
Problem at line 4935 character 24: Use '===' to compare with 'null'.
} else if ( fn == null || bool ) {
Problem at line 4990 character 31: Use '!==' to compare with 'null'.
if ( opt.overflow != null ) {
Problem at line 5134 character 35: Use '!==' to compare with 'null'.
if ( this.elem[this.prop] != null && (!this.elem.style ||
this.elem.style[t...
Problem at line 5134 character 94: Use '===' to compare with 'null'.
if ( this.elem[this.prop] != null && (!this.elem.style ||
this.elem.style[t...
Problem at line 5195 character 43: Use '!==' to compare with 'null'.
if ( this.options.display != null ) {
Problem at line 5259 character 1: Mixed spaces and tabs.
fast: 200,
Problem at line 5260 character 1: Mixed spaces and tabs.
_default: 400
Problem at line 5269 character 60: Use '!==' to compare with 'null'.
if ( fx.elem.style && fx.elem.style[ fx.prop ] != null ) {
Problem at line 5286 character 15: 'genFx' was used before it was
defined.
function genFx( type, num ) {
Problem at line 5558 character 25: Use '===' to compare with 'null'.
return size == null ? null : this;
lorlarz
This summarizes (I believe completely) what I commented out or fixed
to make
JSLint make it all the way through: The following refers to the
development version
of 1.4.2 which you can download from http://jquery.com :
2649 changed to: var origContext = context || document; // = contents
before = contents removed
lines 2663 to 2673 commented out
2985 changed to: var nodeCheck = part.toLowerCase(); // = part
before = part removed
2995 changed to: var nodeCheck = part.toLowerCase(); // = part before
= part removed
3317 changed to Expr.match[ type ] = new
RegExp( Expr.match[ type ].source + (/(?![^\[]*\])(?![^\(]*
\))/.source) ); // parentheses added on expression after + sign
4167 commented out
4775 commented out
5994 prevOffsetParent = offsetParent; offsetParent =
elem.offsetParent; // (comma that was in middle changed to semi-colon)
6035 checkDiv.style.position = "fixed"; checkDiv.style.top =
"20px"; // (comma that was in middle changed to semi-colon)
6040 innerDiv.style.overflow = "hidden"; innerDiv.style.position =
"relative"; // (comma that was in middle changed to semi-colon)
lorlarz
> "lorlarz" <lorl...@gmail.com> wrote in message
I thought the insulting was all in fun. Mark did it.
You mean I can't give it back?
Did you moice I used the wrong "too" ("to" instead of "too"). I also
left the 's' off of dogs. Gee, I must be *** one dumb sob *** .
I apologize if I hurt anyone's feelings. I shall try to just except
insults without giving any retort (<- good word, check your
dictionaries).
But, I am a very nice guy compared to the way I often get treated
here.
So, please forgive any small infraction.
I hope people will evaluate what I have found in my last couple of
posts.
I do very much value all your inputs. They are almost always helpful
--
even when some meaness is thrown in. David Mark did help me.
Thanks, David
lorlarz
> Results of jQuery new production version and last production version
> on JSLint
> (http://www.jslint.com/)
>
> 1.4.2 ,new jQuery production version (compared to the last 'production
> version', 1.3.2).
> The new one seems to have about
> 20% more errors _and_, more importantly, seems (to me) to have more
> serious errors.
>
> **I need more opinions.**
>
> I have a zip on my web site containing:
>
> jQuery 1.4.2 all on one line, comments left out
> jQuery 1.3.2 all on one line, comments left out
> The JSLint report on each (clearly labeled).
>
> This zip is at:http://mynichecomputing.org/JSLintCompare.zip.
> Download it an unzip and
> take a look.
[snip]
I have removed that zip file, since the information in the
posts below is much better.
You no longer need to see that zip.
David Mark
> On Feb 28, 8:49 pm, "rf" <r...@z.invalid> wrote:
>> "lorlarz" <lorl...@gmail.com> wrote in message
>>
>> news:20592e13-21c3-4e14...@z11g2000yqz.googlegroups.com...
>> On Feb 28, 4:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>>> lorlarz wrote:
>>> I have noticed a trend to. It's not certain but many JS programmers
>>> seem to
>>> be meaner than junk yard dog, whether they/it know their/its butt from
>>> a hole
>>> in the ground or not.
>> Good luck getting your next question answered.
>
> I thought the insulting was all in fun. Mark did it.
> You mean I can't give it back?
But I wasn't insulting _you_. I referred to a Resig quote. And I am
just plain tired of the dumbing down of programming in general. Seems
like every time I read a "critique" of my stuff, it is filled with
misspelled words, odd slang, irrational conclusions and plenty of
juvenile insults to boot. Why aren't these people digging ditches?
> Did you moice I used the wrong "too" ("to" instead of "too"). I also
> left the 's' off of dogs. Gee, I must be *** one dumb sob *** .
You said it, not me. :)
>
> I apologize if I hurt anyone's feelings. I shall try to just except
> insults without giving any retort (<- good word, check your
> dictionaries).
I think most people here will recognize that word.
>
> But, I am a very nice guy compared to the way I often get treated
> here.
Again, I didn't say anything about you. In fact, I applaud you for
applying JSLint to jQuery and even questioning the validity of the
results. That shows that you are thinking, which is more than I can say
for the typical jQuery user (if in fact that is what you are).
> So, please forgive any small infraction.
Say what you want. It won't bother me. But as RF pointed out, it may
make me less likely to help you in the future.
>
> I hope people will evaluate what I have found in my last couple of
> posts.
Yes, I saw those. I'll look at them when I have a chance. But
basically it indicates what I expected (even after all of these years,
the code is still hopelessly amateurish). And I'm not at all surprised
that Resig is quick to dismiss the results. That's what he does.
That's all he does. And he absolutely will not stop until his project
is dead. :)
> I do very much value all your inputs. They are almost always helpful
> --
> even when some meaness is thrown in. David Mark did help me.
> Thanks, David
NP. Thanks for asking. It is good to question jQuery. If more people
would take the time to do that, perhaps it would fade away. Take bad
logic and bad style and authors who clearly won't consider anything but
their own delusions and you've got a clear candidate for history's bit
bucket.
David Mark
Both of those argument names are ridiculous. I'm surprised it only
flagged one of them. Of all of the names available, why would you
choose "window" unless you are trying to cause problems? I suspect they
don't pass a second argument, so they end up with an undefined variable
named "undefined". I know they don't care about ancient browsers, so I
can only assume that they are trying to squeeze a few extra characters
out of their minified version. You know code is bad when you have to
squint at the very first line to determine what the coders were trying
to accomplish (and particularly when it is obvious that they are trying
to accomplish it in the worst possible way).
>
> Problem at line 13 character 48: Unescaped '-'.
>
> quickExpr = /^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/,
I'm no RegExp expert, but I think JSLint is being picky there.
>
> Problem at line 33 character 20: 'hasOwnProperty' is a really bad
> name.
>
> hasOwnProperty = Object.prototype.hasOwnProperty,
Really, really bad name. It's like every other line in this thing must
be scrutinized carefully to determine if it is not a typo. Worse still,
because this thing is so haphazardly written, you know the authors have
no reliable way to ferret out typos. This is more minification-driven
design I take it.
>
> Problem at line 145 character 20: Use '===' to compare with 'null'.
>
> return num == null ?
It's just ugly. Upon further inspection, it is likely that - num - can
be null or undefined, which makes you wonder just what the hell that
variable is supposed to be.
>
> Problem at line 261 character 41: Use '!==' to compare with 'null'.
>
> if ( (options = arguments[ i ]) != null ) {
It didn't flag the assignment in the conditional too?
>
> Problem at line 356 character 48: Use '===' to compare with 'null'.
>
> toplevel = window.frameElement == null;
That's rather bizarre for a host object property comparison. Again, it
makes you stop and ponder just what the hell - toplevel - is supposed to
mean (and furthermore, what the hell do the programmers _think_ it is
supposed to mean). This is already a failing grade in my book and it
appears there are tons more after this, despite the fact that the
verification couldn't even reach the halfway point.
>
> Problem at line 488 character 20: Use '!==' to compare with 'null'.
>
> if ( array != null ) {
I certainly don't care for - array - as a variable name either. It's
worse than - num - and why should it have the potential to be null _or_
undefined? Perhaps it doesn't and they are just being sloppy? Who knows?
>
> Problem at line 489 character 31: Use '===' to compare with 'null'.
>
> if ( array.length == null || typeof array === "string" ||
> jQuery.isFunctio...
There's that isFunction thing again. We've been over that. The
"overloading" they do is completely inappropriate for JS. This looks
like the mother of all confused comparisons (from what I can see of it),
which is standard for such inappropriate designs. And why did they use
a strict comparison to compare two strings?
>
> Problem at line 536 character 18: Confusing use of '!'.
>
> if ( !inv !== !callback( elems[ i ], i ) ) {
Dear God. If a single line of code induces an instant migraine, you've
got a serious problem. And consider who is charged with maintaining
this illegible mess. No wonder this stuff gets broken so often.
>
> Problem at line 536 character 18: Confusing use of '!'.
>
> if ( !inv !== !callback( elems[ i ], i ) ) {
Again. You don't have to be a computer scientist to write scripts, but
going all-out the other way with insane constructs like this (which
would result in an instant failing grade in any first-year CS course)
precludes any possibility of success.
>
> Problem at line 550 character 24: Use '!==' to compare with 'null'.
>
> if ( value != null ) {
>
> Problem at line 593 character 4: Mixed spaces and tabs.
That's just ugly.
>
> [];
>
> Problem at line 689 character 21: Missing '()' invoking a constructor.
>
> return (new Date).getTime();
I haven't the slightest idea if that will cause cross-browser
compatibility issues or not (and I doubt they do either). Best to stick
to what you know and not assume it is fine because it appears to work in
the latest versions of IE, FF, Opera and Safari. I assume they just
wanted to save two characters (at a cost they can't calculate).
>
> Problem at line 753 character 13: 'e' is already defined.
>
> } catch(e) {
Sloppy. It shouldn't take a competent JS programmer more than an hour
to clean this slate (and then you could see issues that have the
potential for harm).
>
> Problem at line 1270 character 28: Expected an assignment or function
> call and instead saw an expression.
>
> parent.selectedIndex;
LOL. I remember that one. Rather than checking the selectedIndex to
get the information they need, they prefer to resort to a mystical
incantation (that "works" because they saw it work once) and then check
some other property. This is about as hare-brained as it gets (in any
language).
>
> Problem at line 1273 character 43: Expected an assignment or function
> call and instead saw an expression.
>
> parent.parentNode.selectedIndex;
Yes, I'm partially responsible for doubling this particular incantation
(by proxy of course). Sorry, but I really tried to give them the right
answer (they just took the bits they thought were justified).
>
> Problem at line 1362 character 55: 'eventHandle' is already defined.
>
> eventHandle = elemData.handle, eventHandle;
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?
>
> Problem at line 1471 character 106: Missing semicolon.
That's not going to be good for minification.
>
> jQuery.map( namespaces.slice(0).sort(), fcleanup ).join("\\.(?:.*\
> \.)?")...
>
> Problem at line 1495 character 25: 'j' is already defined.
>
> for ( var j = pos || 0; j < eventType.length; j++ ) {
Sloppy. Again, makes you wonder if there is a mistake or not. This is
just not how competent software is developed.
>
> Problem at line 1500 character 34: Use '===' to compare with 'null'.
>
> if ( pos == null ) {
>
> Problem at line 1509 character 30: Use '!==' to compare with 'null'.
>
> if ( pos != null ) {
>
> Problem at line 1515 character 48: Use '!==' to compare with 'null'.
>
> if ( eventType.length === 0 || pos != null && eventType.length === 1 )
> {
They mix and match strict and loose like it doesn't matter. Who knows
if they fat-fingered the key or really wanted to write the most obscure
code possible?
>
> Problem at line 1619 character 26: 'e' is already defined.
>
> } catch (e) {}
>
> Problem at line 1633 character 30: Bad assignment.
>
> event = arguments[0] = jQuery.event.fix( event || window.event );
Bad assignment indeed. Never seen that one before.
>
> Problem at line 1644 character 20: 'events' is already defined.
>
> var events = jQuery.data(this, "events"), handlers =
> events[ event.type ];
Typo or not? Hard to say without wading through additional code.
>
> Problem at line 1644 character 60: 'handlers' is already defined.
>
> var events = jQuery.data(this, "events"), handlers =
> events[ event.type ];
Same.
>
> Problem at line 1704 character 26: Use '===' to compare with 'null'.
>
> if ( event.pageX == null && event.clientX != null ) {
Again with the nutty host property comparisons. Do they really expect
those properties to be null?
>
> Problem at line 1704 character 51: Use '!==' to compare with 'null'.
>
> if ( event.pageX == null && event.clientX != null ) {
>
> Problem at line 1955 character 19: Use '!==' to compare with 'null'.
>
> if ( data != null || val ) {
>
> Problem at line 2154 character 39: Use '!==' to compare with 'null'.
>
> while ( (type = types[ i++ ]) != null ) {
>
> Problem at line 2182 character 18: Don't make functions within a loop.
>
> });
I am not sure if that one is valid or not. The idea is that it could
create the same function multiple times for no reason (so why not create
it once before entering the loop?) I fixed a few of those in My Library
a ways back. I don't know for sure that it helped anything, but I know
it couldn't have hurt anything.
>
> Problem at line 2190 character 6: Missing semicolon.
>
> }
Odd for a project so obsessed with minification. I guess their bloat is
starting to get them down (up to a required minimum of 70K minified IIRC).
>
> Problem at line 2283 character 56: Unescaped '['.
>
> var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
> [^'"]*['"]...
That makes my eyes hurt.
>
> Problem at line 2283 character 81: Unescaped '['.
>
> var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
> [^'"]*['"]...
Same.
>
> Problem at line 2347 character 21: 'ret' is already defined.
>
> var ret = seed ?
>
> Problem at line 2367 character 26: Use '===' to compare with 'null'.
>
> if ( pop == null ) {
>
> Problem at line 2383 character 23: 'cur' used out of scope.
That means they declared the variable in a block. As there is no block
scope in JS, it won't cause a problem, but could confuse readers
(especially those coming from other languages).
>
> Sizzle.error( cur || selector );
>
> Problem at line 2390 character 42: Use '!==' to compare with 'null'.
>
> for ( var i = 0; checkSet[i] != null; i++ ) {
>
> Problem at line 2396 character 25: 'i' is already defined.
>
> for ( var i = 0; checkSet[i] != null; i++ ) {
>
> Problem at line 2396 character 42: Use '!==' to compare with 'null'.
>
> for ( var i = 0; checkSet[i] != null; i++ ) {
>
> Problem at line 2443 character 40: 'match' is already defined.
>
> var type = Expr.order[i], match;
>
> Problem at line 2452 character 26: Use '!==' to compare with 'null'.
>
> if ( set != null ) {
>
> Problem at line 2473 character 64: Use '!==' to compare with 'null'.
>
> if ( (match = Expr.leftMatch[ type ].exec( expr )) != null &&
> match[2] ) {
>
> Problem at line 2498 character 58: Use '!==' to compare with 'null'.
>
> for ( var i = 0; (item = curLoop[i]) != null; i++ ) {
>
> Problem at line 2503 character 51: Use '!==' to compare with 'null'.
>
> if ( inplace && found != null ) {
>
> Problem at line 2534 character 27: Use '===' to compare with 'null'.
>
> if ( anyFound == null ) {
Sheesh! Not very exacting are they? Seeing as
>
> Problem at line 2554 character 35: Unescaped '-'.
>
> ID: /#((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
>
> Problem at line 2555 character 39: Unescaped '-'.
>
> CLASS: /\.((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
>
> Problem at line 2556 character 48: Unescaped '-'.
>
> NAME: /\[name=['"]*((?:[\w\u00c0-\uFFFF-]|\\.)+)['"]*\]/,
>
> Problem at line 2557 character 41: Unescaped '-'.
>
> ATTR: /\[\s*((?:[\w\u00c0-\uFFFF-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)
> \3|)\s*...
>
> Problem at line 2558 character 38: Unescaped '-'.
>
> TAG: /^((?:[\w\u00c0-\uFFFF\*-]|\\.)+)/,
>
> Problem at line 2559 character 65: Unescaped '-'.
>
> CHILD: /:(only|nth|last|first)-child(?:\((even|odd|[\dn+-]*)\))?/,
>
> Problem at line 2560 character 69: Unescaped '-'.
>
> POS: /:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/,
>
> Problem at line 2561 character 39: Unescaped '-'.
>
> PSEUDO: /:((?:[\w\u00c0-\uFFFF-]|\\.)+)(?:\((['"]?)((?:\([^\)]+\)|[^\
> (\)]*)...
Again, not sure on those. These appear to be the selector parsing
expressions. I avoided using Regular expressions there, though my own
parsing has gotten fairly messy too (nothing compared to this stuff though).
>
> Problem at line 2611 character 29: 'i' is already defined.
>
> for ( var i = 0, l = checkSet.length; i < l; i++ ) {
>
> Problem at line 2611 character 36: 'l' is already defined.
>
> for ( var i = 0, l = checkSet.length; i < l; i++ ) {
>
> Problem at line 2612 character 30: 'elem' is already defined.
>
> var elem = checkSet[i];
>
> Problem at line 2633 character 61: 'nodeCheck' used out of scope.
>
> checkFn("parentNode", part, doneName, checkSet, nodeCheck, isXML);
>
> Problem at line 2643 character 66: 'nodeCheck' used out of scope.
>
> checkFn("previousSibling", part, doneName, checkSet, nodeCheck,
> isXML);
>
> Problem at line 2678 character 56: Use '!==' to compare with 'null'.
>
> for ( var i = 0, elem; (elem = curLoop[i]) != null; i++ ) {
>
> Problem at line 2758 character 29: Expected an assignment or function
> call and instead saw an expression.
>
> elem.parentNode.selectedIndex;
Again?! That's right, they did that stupid spell in two places, so they
actually quadrupled it after my input. Odd for people so concerned with
file size.
>
> Problem at line 2771 character 20: Wrap the /regexp/ literal in parens
> to disambiguate the slash operator.
>
> return /h\d/i.test( elem.nodeName );
I don't think it will cause problems, but then I haven't tested every
browser ever made. ;)
That's about enough. As I've said before, avoid this junk like the
plague. This is simply another level of validation for that basic
message. Of course, most Web developers don't get it as they see all
scripts as indecipherable voodoo.
David Mark
[...]
>
> This summarizes (I believe completely) what I commented out or fixed
> to make
> JSLint make it all the way through: The following refers to the
> development version
> of 1.4.2 which you can download from http://jquery.com :
No thanks! :)
>
> 2649 changed to: var origContext = context || document; // = contents
> before = contents removed
>
>
> lines 2663 to 2673 commented out
LOL.
>
> 2985 changed to: var nodeCheck = part.toLowerCase(); // = part
> before = part removed
>
> 2995 changed to: var nodeCheck = part.toLowerCase(); // = part before
> = part removed
Huh?
>
>
>
> 3317 changed to Expr.match[ type ] = new
> RegExp( Expr.match[ type ].source + (/(?![^\[]*\])(?![^\(]*
> \))/.source) ); // parentheses added on expression after + sign
>
>
> 4167 commented out
>
> 4775 commented out
>
>
> 5994 prevOffsetParent = offsetParent; offsetParent =
> elem.offsetParent; // (comma that was in middle changed to semi-colon)
>
> 6035 checkDiv.style.position = "fixed"; checkDiv.style.top =
> "20px"; // (comma that was in middle changed to semi-colon)
>
> 6040 innerDiv.style.overflow = "hidden"; innerDiv.style.position =
> "relative"; // (comma that was in middle changed to semi-colon)
Yeah, I hate that one. Dojo was (is) chock full of those too. Makes
you stop and wonder if there is a missing "var".
lorlarz
It occurs to me it would be useful to provide modified jquery txt --
1.4.2 the corrected and commented out
version (with comments OTHERWISE deleted) SO you can line up the line
numbers in the report, quoted above with the actual lines of text
where the errors occur. FOR this I provide that modified 1.4.2 I fed
in the get the JSLint report. You can find it at:
David Mark
Thanks, but it doesn't really matter. Even if _all_ of those issues
turn out to be "benign", their very presence ensures mass confusion for
those who have to maintain the code (and we know that they are not
exactly proficient with JS to begin with).
Michael Haufe ("TNO")
> if ( (options = arguments[ i ]) != null ) {
David Mark wrote:
> It didn't flag the assignment in the conditional too?
Common practice dictates that the extra parenthesis make explicit that
the assignment was intentional. Mozilla strict warnings honor this
pattern. Perhaps other engines do as well but I haven't tested.
David Mark
Thanks, I missed that. So many warnings, so little time. :)
I'm not big on Mozilla strict mode though. IIRC, many of its warnings
are arbitrary (even more so than JSLint). Complaining about anonymous
functions that don't return anything comes to mind.
Michael Haufe ("TNO")
> I'm not big on Mozilla strict mode though. IIRC, many of its warnings
> are arbitrary (even more so than JSLint). Complaining about anonymous
> functions that don't return anything comes to mind.
I haven't seen such an issue myself. Take for example:
--------------------------------
function foo1(){}
function foo2(){ return false; }
function foo3(){
if(true)
return 1;
else
return 0;
}
function foo4(){
if(true)
return 1
}
(function(){})();
--------------------------------
The only warning you'll receive is from foo4. I think this is
reasonable. If it was smarter it could flag the anonymous function and
foo1 as useless statements as well which would be reasonable as well
IMO.
Michael Haufe ("TNO")
<t...@thenewobjective.com> wrote:
> The only warning you'll receive is from foo4. I think this is
> reasonable. If it was smarter it could flag the anonymous function and
> foo1 as useless statements as well which would be reasonable as well
> IMO.
s/be reasonable as well/be reasonable
David Mark
> On Mar 1, 1:19 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>> I'm not big on Mozilla strict mode though. IIRC, many of its warnings
>> are arbitrary (even more so than JSLint). Complaining about anonymous
>> functions that don't return anything comes to mind.
>
> I haven't seen such an issue myself. Take for example:
It's been a while since I used it. I may be remembering the lint that
runs on Dojo check-ins. It was passable for 99% of their files (once
they were cleaned up and cleared by JSLint, of course), but for the
remainder I had to disable verification with a !strict directive. As an
aside, every time I visit their trac, I see that virtually every
check-in uses !strict, which is self-defeating and what led to the
various typos and other mistakes I found when going through their stuff.
Some people never learn.
> --------------------------------
> function foo1(){}
> function foo2(){ return false; }
> function foo3(){
> if(true)
> return 1;
> else
> return 0;
> }
> function foo4(){
> if(true)
> return 1
> }
>
> (function(){})();
> --------------------------------
>
> The only warning you'll receive is from foo4. I think this is
> reasonable. If it was smarter it could flag the anonymous function and
> foo1 as useless statements as well which would be reasonable as well
> IMO.
Yes, I agree with that.
lorlarz
> On Feb 28, 9:09 pm, lorlarz <lorl...@gmail.com> wrote:
>
For convenience, I thought it would be good to just refer to ONE file
(one document) regarding all the changes I needed to make to get
jQuery 1.4.2 all the way through JSLint **_AND_** the remaining
errors found (in particular, their line numbers) NOW referring to the
SAME jQuery 1.4.2 Development Verson (obtainable from http://jquery.ocm
).
OK. Here it is. Directions: Simply make the following changes to
the Development version of jQuery 1.4.2 :
2649 changed to: var origContext = context || document; // = contents
before = contents removed
lines 2663 to 2673 commented out
2985 changed to: var nodeCheck = part.toLowerCase(); // = part
before = part removed
2995 changed to: var nodeCheck = part.toLowerCase(); // = part before
= part removed
3317 changed to Expr.match[ type ] = new
RegExp( Expr.match[ type ].source + (/(?![^\[]*\])(?![^\(]*
\))/.source) ); // parentheses added on expression after + sign
4167 commented out
4775 commented out
5994 prevOffsetParent = offsetParent; offsetParent =
elem.offsetParent; // (comma in middle changed to semi-colon)
6035 checkDiv.style.position = "fixed"; checkDiv.style.top =
"20px"; // (comma in middle changed to semi-colon)
6040 innerDiv.style.overflow = "hidden"; innerDiv.style.position =
"relative"; // (comma in middle changed to semi-colon)
***********************
***********************
**THEN** run that file (documewnt) as so changed through JSLint and
you get the following
error report of remaining errors: (line numbers now referring to lines
in that document):
Error:
Problem at line 16 character 20: Expected an identifier and instead
saw 'undefined' (a reserved word).
(function( window, undefined ) {
Problem at line 38 character 48: Unescaped '-'.
quickExpr = /^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/,
Problem at line 69 character 20: 'hasOwnProperty' is a really bad
name.
hasOwnProperty = Object.prototype.hasOwnProperty,
Problem at line 204 character 20: Use '===' to compare with 'null'.
return num == null ?
Problem at line 330 character 41: Use '!==' to compare with 'null'.
if ( (options = arguments[ i ]) != null ) {
Problem at line 441 character 48: Use '===' to compare with 'null'.
toplevel = window.frameElement == null;
Problem at line 595 character 20: Use '!==' to compare with 'null'.
if ( array != null ) {
Problem at line 599 character 31: Use '===' to compare with 'null'.
if ( array.length == null || typeof array === "string" ||
jQuery.isFunctio...
Problem at line 648 character 18: Confusing use of '!'.
if ( !inv !== !callback( elems[ i ], i ) ) {
Problem at line 648 character 18: Confusing use of '!'.
if ( !inv !== !callback( elems[ i ], i ) ) {
Problem at line 665 character 24: Use '!==' to compare with 'null'.
if ( value != null ) {
Problem at line 713 character 4: Mixed spaces and tabs.
[];
Problem at line 823 character 21: Missing '()' invoking a constructor.
return (new Date).getTime();
Problem at line 913 character 13: 'e' is already defined.
} catch(e) {
Problem at line 1476 character 28: Expected an assignment or function
call and instead saw an expression.
parent.selectedIndex;
Problem at line 1480 character 43: Expected an assignment or function
call and instead saw an expression.
parent.parentNode.selectedIndex;
Problem at line 1592 character 55: 'eventHandle' is already defined.
eventHandle = elemData.handle, eventHandle;
Problem at line 1724 character 106: Missing semicolon.
jQuery.map( namespaces.slice(0).sort(), fcleanup ).join("\\.(?:.*\
\.)?")...
Problem at line 1748 character 25: 'j' is already defined.
for ( var j = pos || 0; j < eventType.length; j++ ) {
Problem at line 1754 character 34: Use '===' to compare with 'null'.
if ( pos == null ) {
Problem at line 1763 character 30: Use '!==' to compare with 'null'.
if ( pos != null ) {
Problem at line 1770 character 48: Use '!==' to compare with 'null'.
if ( eventType.length === 0 || pos != null && eventType.length === 1 )
{
Problem at line 1893 character 26: 'e' is already defined.
} catch (e) {}
Problem at line 1907 character 30: Bad assignment.
event = arguments[0] = jQuery.event.fix( event || window.event );
Problem at line 1919 character 20: 'events' is already defined.
var events = jQuery.data(this, "events"), handlers =
events[ event.type ];
Problem at line 1919 character 60: 'handlers' is already defined.
var events = jQuery.data(this, "events"), handlers =
events[ event.type ];
Problem at line 1989 character 26: Use '===' to compare with 'null'.
if ( event.pageX == null && event.clientX != null ) {
Problem at line 1989 character 51: Use '!==' to compare with 'null'.
if ( event.pageX == null && event.clientX != null ) {
Problem at line 2275 character 19: Use '!==' to compare with 'null'.
if ( data != null || val ) {
Problem at line 2487 character 39: Use '!==' to compare with 'null'.
while ( (type = types[ i++ ]) != null ) {
Problem at line 2516 character 18: Don't make functions within a loop.
});
Problem at line 2525 character 6: Missing semicolon.
}
Problem at line 2632 character 56: Unescaped '['.
var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
[^'"]*['"]...
Problem at line 2632 character 81: Unescaped '['.
var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"]
[^'"]*['"]...
Problem at line 2702 character 21: 'ret' is already defined.
var ret = seed ?
Problem at line 2722 character 26: Use '===' to compare with 'null'.
if ( pop == null ) {
Problem at line 2738 character 23: 'cur' used out of scope.
Sizzle.error( cur || selector );
Problem at line 2745 character 42: Use '!==' to compare with 'null'.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2751 character 25: 'i' is already defined.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2751 character 42: Use '!==' to compare with 'null'.
for ( var i = 0; checkSet[i] != null; i++ ) {
Problem at line 2798 character 40: 'match' is already defined.
var type = Expr.order[i], match;
Problem at line 2807 character 26: Use '!==' to compare with 'null'.
if ( set != null ) {
Problem at line 2828 character 64: Use '!==' to compare with 'null'.
if ( (match = Expr.leftMatch[ type ].exec( expr )) != null &&
match[2] ) {
Problem at line 2853 character 58: Use '!==' to compare with 'null'.
for ( var i = 0; (item = curLoop[i]) != null; i++ ) {
Problem at line 2858 character 51: Use '!==' to compare with 'null'.
if ( inplace && found != null ) {
Problem at line 2890 character 27: Use '===' to compare with 'null'.
if ( anyFound == null ) {
Problem at line 2910 character 35: Unescaped '-'.
ID: /#((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
Problem at line 2911 character 39: Unescaped '-'.
CLASS: /\.((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
Problem at line 2912 character 48: Unescaped '-'.
NAME: /\[name=['"]*((?:[\w\u00c0-\uFFFF-]|\\.)+)['"]*\]/,
Problem at line 2913 character 41: Unescaped '-'.
ATTR: /\[\s*((?:[\w\u00c0-\uFFFF-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)
\3|)\s*...
Problem at line 2914 character 38: Unescaped '-'.
TAG: /^((?:[\w\u00c0-\uFFFF\*-]|\\.)+)/,
Problem at line 2915 character 65: Unescaped '-'.
CHILD: /:(only|nth|last|first)-child(?:\((even|odd|[\dn+-]*)\))?/,
Problem at line 2916 character 69: Unescaped '-'.
POS: /:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/,
Problem at line 2917 character 39: Unescaped '-'.
PSEUDO: /:((?:[\w\u00c0-\uFFFF-]|\\.)+)(?:\((['"]?)((?:\([^\)]+\)|[^\
(\)]*)...
Problem at line 2967 character 29: 'i' is already defined.
for ( var i = 0, l = checkSet.length; i < l; i++ ) {
Problem at line 2967 character 36: 'l' is already defined.
for ( var i = 0, l = checkSet.length; i < l; i++ ) {
Problem at line 2968 character 30: 'elem' is already defined.
var elem = checkSet[i];
Problem at line 2989 character 61: 'nodeCheck' used out of scope.
checkFn("parentNode", part, doneName, checkSet, nodeCheck, isXML);
Problem at line 2999 character 66: 'nodeCheck' used out of scope.
checkFn("previousSibling", part, doneName, checkSet, nodeCheck,
isXML);
Problem at line 3034 character 56: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = curLoop[i]) != null; i++ ) {
Problem at line 3120 character 29: Expected an assignment or function
call and instead saw an expression.
elem.parentNode.selectedIndex;
Problem at line 3133 character 20: Wrap the /regexp/ literal in parens
to disambiguate the slash operator.
return /h\d/i.test( elem.nodeName );
Problem at line 3163 character 20: Wrap the /regexp/ literal in parens
to disambiguate the slash operator.
return /input|select|textarea|button/i.test(elem.nodeName);
Problem at line 3203 character 29: 'i' is already defined.
for ( var i = 0, l = not.length; i < l; i++ ) {
Problem at line 3227 character 32: Expected a 'break' statement before
'case'.
node = elem;
Problem at line 3277 character 34: Use '!==' to compare with 'null'.
elem[ name ] != null ?
Problem at line 3284 character 27: Use '===' to compare with 'null'.
return result == null ?
Problem at line 3320 character 6: Don't make functions within a loop.
}));
Problem at line 3339 character 77: Expected an assignment or function
call and instead saw an expression.
Array.prototype.slice.call( document.documentElement.childNodes, 0 )
[0].node...
Problem at line 3354 character 29: 'i' is already defined.
for ( var i = 0; array[i]; i++ ) {
Problem at line 3443 character 34: Missing '()' invoking a
constructor.
id = "script" + (new Date).getTime();
Problem at line 3686 character 1: Unreachable 'window' after 'return'.
window.Sizzle = Sizzle;
Problem at line 3693 character 11: 'slice' is already defined.
slice = Array.prototype.slice;
Problem at line 3699 character 20: Confusing use of '!'.
return !!qualifier.call( elem, i, elem ) === keep;
Problem at line 4114 character 49: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = this[i]) != null; i++ ) {
Problem at line 4131 character 49: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = this[i]) != null; i++ ) {
Problem at line 4320 character 9: Inner functions should be listed at
the top of the outer function.
function root( elem, cur ) {
Problem at line 4320 character 22: 'root' was used before it was
defined.
function root( elem, cur ) {
Problem at line 4424 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4492 character 25: 'i' is already defined.
for ( var i = 0; ret[i]; i++ ) {
Problem at line 4513 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4628 character 13: Function statements cannot be
placed in blocks. Use a function expression or move the statement to
the top of the outer function.
function getWH() {
Problem at line 4749 character 24: 'name' is already defined.
for ( var name in options ) {
Problem at line 4868 character 24: Use '===' to compare with 'null'.
return val == null ?
Problem at line 5052 character 41: Bad operand.
if ( s.global && ! jQuery.active++ ) {
Problem at line 5238 character 17: 'e' is already defined.
} catch(e) { }
Problem at line 5253 character 17: 'e' is already defined.
} catch(e) {
Problem at line 5276 character 26: 'complete' was used before it was
defined.
function complete() {
Problem at line 5293 character 25: 'trigger' is already defined.
function trigger(type, args) {
Problem at line 5404 character 9: Inner functions should be listed at
the top of the outer function.
function buildParams( prefix, obj ) {
Problem at line 5404 character 29: 'buildParams' was used before it
was defined.
function buildParams( prefix, obj ) {
Problem at line 5423 character 45: Use '!==' to compare with 'null'.
} else if ( !traditional && obj != null && typeof obj === "object" ) {
Problem at line 5444 character 19: Unescaped '-'.
rfxnum = /^([+-]=)?([\d+-.]+)(.*)$/,
Problem at line 5531 character 24: Use '===' to compare with 'null'.
} else if ( fn == null || bool ) {
Problem at line 5589 character 31: Use '!==' to compare with 'null'.
if ( opt.overflow != null ) {
Problem at line 5744 character 35: Use '!==' to compare with 'null'.
if ( this.elem[this.prop] != null && (!this.elem.style ||
this.elem.style[t...
Problem at line 5744 character 94: Use '===' to compare with 'null'.
if ( this.elem[this.prop] != null && (!this.elem.style ||
this.elem.style[t...
Problem at line 5816 character 43: Use '!==' to compare with 'null'.
if ( this.options.display != null ) {
Problem at line 5887 character 1: Mixed spaces and tabs.
fast: 200,
Problem at line 5888 character 1: Mixed spaces and tabs.
// Default speed
Problem at line 5889 character 1: Mixed spaces and tabs.
_default: 400
Problem at line 5898 character 60: Use '!==' to compare with 'null'.
if ( fx.elem.style && fx.elem.style[ fx.prop ] != null ) {
Problem at line 5915 character 15: 'genFx' was used before it was
defined.
function genFx( type, num ) {
Problem at line 6203 character 25: Use '===' to compare with 'null'.
lorlarz
>
> Yes, I saw those. I'll look at them when I have a chance. But
> basically it indicates what I expected (even after all of these years,
> the code is still hopelessly amateurish). And I'm not at all surprised
> that Resig is quick to dismiss the results. That's what he does.
> That's all he does. And he absolutely will not stop until his project
> is dead. :)
>
> > I do very much value all your inputs. They are almost always helpful
> > --
> > even when some meaness is thrown in. David Mark did help me.
> > Thanks, David
>
> NP. Thanks for asking. It is good to question jQuery. If more people
> would take the time to do that, perhaps it would fade away. Take bad
> logic and bad style and authors who clearly won't consider anything but
> their own delusions and you've got a clear candidate for history's bit
>
> - Show quoted text -
David, It my brief communication with John Resig _and_, given the
errors I
found and had to correct to get more than 41% of jQuery 1.4.2 through
JSLint, I do not believe Resig even sent jQuery 1.4.2 through JSLint.
I have emailed him. But if he looks at JSLint results, I believe it
is likely
the run results I provided may well be the first he has seen.
lorlarz
[snip]
>
> 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. It is by far the
most used JS library and has had and continues to have the fastest
growth. Moreover, jQuery is now used somewhere in a full 20% of
web sites on the Earth.
We must stay critical about it. But, while other libraries may be
failing, from any use standpoint, jQuery is not.
lorlarz
> On Mar 1, 12:04 am, lorlarz <lorl...@gmail.com> wrote:> On Feb 28, 9:09 pm, lorlarz <lorl...@gmail.com> wrote:
>
> [snip]
>
> For convenience, I thought it would be good to just refer to ONE file
> (one document) regarding all the changes I needed to make to get
> jQuery 1.4.2 all the way through JSLint **_AND_** the remaining
> errors found (in particular, their line numbers) NOW referring to the
> ).
>
> OK. Here it is. Directions: Simply make the following changes to
> the Development version of jQuery 1.4.2 :
>
> 2649 changed to: var origContext = context || document; // = contents
> before = contents removed
>
> lines 2663 to 2673 commented out
>
> 2985 changed to: var nodeCheck = part.toLowerCase(); // = part
> before = part removed
>
> 2995 changed to: var nodeCheck = part.toLowerCase(); // = part before
> = part removed
>
> 3317 changed to Expr.match[ type ] = new
> RegExp( Expr.match[ type ].source + (/(?![^\[]*\])(?![^\(]*
> \))/.source) ); // parentheses added on expression after + sign
>
> 4167 commented out
>
> 4775 commented out
>
> 5994 prevOffsetParent = offsetParent; offsetParent =
> elem.offsetParent; // (comma in middle changed to semi-colon)
>
> 6035 checkDiv.style.position = "fixed"; checkDiv.style.top =
> "20px"; // (comma in middle changed to semi-colon)
>
> 6040 innerDiv.style.overflow = "hidden"; innerDiv.style.position =
> "relative"; // (comma in middle changed to semi-colon)
>
The problems I would _really_ like to see addressed are what
JSLInt saw as *big problems* and I did not correct, but rather
commented out to even get through jQuery 1.4.2 with JSLint .
Below are the 3 bits of code I had to comment out.:
The block I had to comment out: (all line no. now refer to
development
version of jQuery 1.4.2 , as provided by http://jquery.com ):
lines 2663 to 2673
/* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== null ) {
soFar = m[3];
parts.push( m[1] );
if ( m[2] ) {
extra = m[3];
break;
}
}
*/
and
line 4167:
// replace(/=([^="'>\s]+\/)>/g, '="$1">')
and
line 4775:
// jsre = /=\?(&|$)/,
How big are these problems? Can they be viewed as benign?
I sure do NOT know.
lorlarz
> lorlarz wrote:
[snip]
> > 2985 changed to: var nodeCheck = part.toLowerCase(); // = part
> > before = part removed
> > 2995 changed to: var nodeCheck = part.toLowerCase(); // = part before
> > = part removed
> Huh?
[snip]
Here's what I mean:
There were 2 cases in which they had the following):
(JSLInt considered this too big a problem to continue BUT
since toLowercase() does not alter the string it is applied
to but returns a modified copy, it is possibly what is wanted.
Makes me wonder if
JSLInt is not a bit "wack" on this):
var nodeCheck = part = part.toLowerCase();
There where 2 other exactly similar cases other than the 2 of those.
lorlarz
>
> - Show quoted text -
P.S. To my above quoted post (sorry):
The things of concern to me among the remaining 'errors' in the
JSLint
report, these seem to be the most worrisome:
Problem at line 2989 character 61: 'nodeCheck' used out of scope.
checkFn("parentNode", part, doneName, checkSet, nodeCheck, isXML);
---------------
Problem at line 2999 character 66: 'nodeCheck' used out of scope.
checkFn("previousSibling", part, doneName, checkSet, nodeCheck,
isXML);
--------------
Problem at line 4628 character 13: Function statements cannot be
placed in blocks. Use a function expression or move the statement to
the top of the outer function.
function getWH() {
---------------
Gregor Kofler
> David,
>
> I don't think you know how well jQuery is doing.
I'm pretty sure he knows.
> It is by far the
> most used JS library and has had and continues to have the fastest
> growth. Moreover, jQuery is now used somewhere in a full 20% of
> web sites on the Earth.
>
> We must stay critical about it. But, while other libraries may be
> failing, from any use standpoint, jQuery is not.
And? You should know by now, that there is no relation between code
quality and widespread use. (After all Internet Explorer 6 is still the
most popular browser on this planet's face...)
Zillions of web pages claim to be XHTML 1.0 strict - hardly anyone
really is. Bottom line: Most web authors are quite incompetent when it
comes to web authoring, and they are *completely* clueless when it comes
to browser scripting. Tthat's why the resort to some library or -
frequently - a bunch of them (I once had to work on a site sporting
jQuery, Spry and mootools plus "plugins" and "extensions"; it was
"leaking badly").
Gregor
lorlarz
>
I really wrongly 'fixed' lines 2985 and 2995: They should have been
fixed
to read: part = part.toLowerCase(); var nodeCheck = part;
I though this might cure the 'nodeCheck' used out of scope JSLint
error
but it did not.
Still, people should change the fix for lines 2985 and 2995 and rerun
JSLInt via http://jslint.org to see a possibly truer error list --
I.E.
since I really made a wrong 'correction' before. Also, of course,
the
three things I had to comment out to get jQuery 1.4.2 all the way
through
JSLint may have wrongfully created an error by JSLint.
This may irritate people, but after fixing my wrong fix, here is the
JSLint 'error' list (recall 3 commented out areas may still have
falsely caused problems, but at least now nothing else would do that).
UPDATE: JSLint remaining 'errors':
(function( window, undefined ) {
hasOwnProperty = Object.prototype.hasOwnProperty,
[];
return (new Date).getTime();
} catch(e) {
parent.selectedIndex;
parent.parentNode.selectedIndex;
eventHandle = elemData.handle, eventHandle;
} catch (e) {}
});
}
Sizzle.error( cur || selector );
Problem at line 2989 character 61: 'nodeCheck' used out of scope.
checkFn("parentNode", part, doneName, checkSet, nodeCheck, isXML);
Problem at line 2999 character 66: 'nodeCheck' used out of scope.
checkFn("previousSibling", part, doneName, checkSet, nodeCheck,
isXML);
Problem at line 3034 character 56: Use '!==' to compare with 'null'.
elem.parentNode.selectedIndex;
node = elem;
}));
window.Sizzle = Sizzle;
slice = Array.prototype.slice;
the top of the outer function.
function root( elem, cur ) {
Problem at line 4320 character 22: 'root' was used before it was
defined.
function root( elem, cur ) {
Problem at line 4424 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4492 character 25: 'i' is already defined.
for ( var i = 0; ret[i]; i++ ) {
Problem at line 4513 character 50: Use '!==' to compare with 'null'.
for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
Problem at line 4628 character 13: Function statements cannot be
placed in blocks. Use a function expression or move the statement to
the top of the outer function.
function getWH() {
Problem at line 4749 character 24: 'name' is already defined.
for ( var name in options ) {
Problem at line 4868 character 24: Use '===' to compare with 'null'.
return val == null ?
Problem at line 5052 character 41: Bad operand.
if ( s.global && ! jQuery.active++ ) {
Problem at line 5238 character 17: 'e' is already defined.
} catch(e) { }
Problem at line 5253 character 17: 'e' is already defined.
} catch(e) {
Problem at line 5276 character 26: 'complete' was used before it was
defined.
function complete() {
Problem at line 5293 character 25: 'trigger' is already defined.
function trigger(type, args) {
Problem at line 5404 character 9: Inner functions should be listed at
the top of the outer function.
function buildParams( prefix, obj ) {
lorlarz
This might make a lot of JS people here mad, but I _want_ to use
jQuery. I just want to have all assurance or reasonable
quality control. At the very least, jQuery is very close to
OK. I just really want to know if there are any _real_ errors
that make things work wrong.
Matt Kruse
> This might make a lot of JS people here mad, but I _want_ to use
> jQuery. I just want to have all assurance or reasonable
> quality control. At the very least, jQuery is very close to
> OK. I just really want to know if there are any _real_ errors
> that make things work wrong.
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.
Matt Kruse
Gregor Kofler
> This might make a lot of JS people here mad, but I _want_ to use
> jQuery. I just want to have all assurance or reasonable
> quality control. At the very least, jQuery is very close to
> OK. I just really want to know if there are any _real_ errors
> that make things work wrong.
JSLint won't tell you anything about code quality. Well, at least not
much. JSLint won't tell you anything about efficiency of scripts. It
can't tell you anything about *browser* scripting (it's not interested
in host objects). It won't tell you whether the script being checked is
up to the task it was written for.
Even if scripts don't pass JSLint they can be perfectly ok (which
doesn't apply to jQuery) - one just has to understand the warnings issued.
Gregor
lorlarz
> On Mar 1, 11:11 am, lorlarz <lorl...@gmail.com> wrote:
>
>
>
>
>
> > On Mar 1, 10:22 am, lorlarz <lorl...@gmail.com> wrote:
[snip]
You may be interested to know that in response to this JSLint barrage
(which I have also contacted John Resig personally about), John
has decided to make a couple of changes and is considering making
a couple (or some) others. The following links, provided by J. Resig
supposedly have something to do with 2 changes made so far:
http://github.com/jquery/jquery/commit/a18f682012ae8e63f3b43b39375b3c5ce0a561e3
http://github.com/jeresig/sizzle/commit/89dd2b35d51693f46b2043149243920b380ad474
He also said he has one thing to investigate and another he is unsure
of.
Also: It is also noteworthy that at least one of the errors cited
by JSLint was seen as a real error _needing_ fixing.
John Resig encourages people to keep up on any changes by getting
the most recent release always: http://code.jquery.com/jquery-nightly.js
I shall not pass any judgement on any of this.
lorlarz
> On Mar 1, 11:50 am, lorlarz <lorl...@gmail.com> wrote:> On Mar 1, 11:11 am, lorlarz <lorl...@gmail.com> wrote:
>
> > > On Mar 1, 10:22 am, lorlarz <lorl...@gmail.com> wrote:
>
> [snip]
>
> You may be interested to know that in response to this JSLint barrage
> (which I have also contacted John Resig personally about), John
> has decided to make a couple of changes and is considering making
> a couple (or some) others. The following links, provided by J. Resig
> supposedly have something to do with 2 changes made so far:
>
>
> He also said he has one thing to investigate and another he is unsure
> of.
> Also: It is also noteworthy that at least one of the errors cited
> by JSLint was seen as a real error _needing_ fixing.
>
> John Resig encourages people to keep up on any changes by getting
> the most recent release always:http://code.jquery.com/jquery-nightly.js
>
> I shall not pass any judgement on any of this.
P.S. John adds that he has also made this fix:
http://github.com/jeresig/sizzle/commit/bba54187feed83914d9a83b4b74c51168e816073
Unfortunately, he will not participate here and has basically
insisted
that these issues be discussed in the following forum:
http://forum.jquery.com/developing-jquery-core
(I did put my last big post ( http://tinyurl.com/yc6gf5m ) there,
as he seemed to request)
john
> (After all Internet Explorer 6 is still the
> most popular browser on this planet's face...)
according to what statistics? fortunately all of the references i looked
at (those linked from the wikipedia page on browser usage) contradict
that. checking the logs for 15 client sites (none of which are tech
oriented) i see a similar pattern of IE6 being anywhere from 3rd to 5th
most used browser.
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
http://www.w3counter.com/globalstats.php?year=2010&month=1
http://gs.statcounter.com/#browser_version-ww-monthly-200902-201003
http://www.w3schools.com/browsers/browsers_stats.asp
<http://statowl.com/web_browser_usage_by_version.php?1=1&timeframe=last_6&interval=month&chart_id=4&fltr_br=&fltr_os=&fltr_se=&fltr_cn=&limit[]=ie>
lorlarz
[snip see 2 posts earlier for this material snipped}
> P.S. John adds that he has also made this fix:http://github.com/jeresig/sizzle/commit/bba54187feed83914d9a83b4b74c5...
>
> Unfortunately, he will not participate here and has basically
> insisted
> that these issues be discussed in the following forum:
>
> http://forum.jquery.com/developing-jquery-core
>
> (I did put my last big post (http://tinyurl.com/yc6gf5m) there,
> as he seemed to request)- Hide quoted text -
>
>
I have changed another correction I make to make sure jQuery is
left at no wrong disadvantage. In my instructions for running
the JSLint on jQuery 1.4.2 Development version, yourself:
Change the instruction for line 2649:
NOW: 2649 is to be changed to:
context = context || document; var origContext = context;
** I reran JSLint and nothing whatsoever. **
You will have to see earlier posts in this thread for
other changes you must make to get jQuery 1.4.2 to
get all the way through JSLint.
The dialog over on http://forum.jquery.com/developing-jquery-core on
the thread "jQuery 1.4.2 : JSlint" could be interesting. Perhaps
you will want to at least view it. This is where the jQuery
community
will reapond to the JSLint results. John Resig has already
personally
responded to what he has done.
Gregor Kofler
Indeed. On statcounter it currently occupies the second place...
If you look at Europe or perhaps Germany the situation improves further.
It was just the usual reply, when someone tries to rate the "quality" of
product by its widespread use and acceptance.
Gregor
Stefan Weiss
> On Mar 1, 12:45 pm, lorlarz <lorl...@gmail.com> wrote:
>> You may be interested to know that in response to this JSLint barrage
>> (which I have also contacted John Resig personally about), John
>> has decided to make a couple of changes and is considering making
>> a couple (or some) others. The following links, provided by J. Resig
>> supposedly have something to do with 2 changes made so far:
>>
>>
>> He also said he has one thing to investigate and another he is unsure
>> of.
>> Also: It is also noteworthy that at least one of the errors cited
>> by JSLint was seen as a real error _needing_ fixing.
That's just a missing semicolon. It's not an "error _needing_ fixing"
(in this case), and John Resig didn't say it was. It's good style to add
the semicolon even if it's not strictly required, that's all.
>> John Resig encourages people to keep up on any changes by getting
>> the most recent release always:http://code.jquery.com/jquery-nightly.js
>>
>> I shall not pass any judgement on any of this.
>
> P.S. John adds that he has also made this fix:
> http://github.com/jeresig/sizzle/commit/bba54187feed83914d9a83b4b74c51168e816073
>
> Unfortunately, he will not participate here
I'm not surprised.
> and has basically insisted
> that these issues be discussed in the following forum:
>
> http://forum.jquery.com/developing-jquery-core
Looks like the logical place for your report. Apparently Resig has
already fixed many of the minor issues you mentioned, and decided to
look into some others. I wouldn't worry too much if JSLint still comes
up with some "problems" after he's done; not everything it finds is
actually a problem.
JSLint has always had its little idiosyncrasies. It doesn't check
syntax, it checks code style - and in the absence of official style
guidelines (like they are used in many companies and projects), you'll
have trouble getting any two developers to agree on a single set of
rules. JSLint uses the subset of JS that Crockford has defined in his
book as the "Good Parts", and a number of other rules which he considers
important.
Unfortunately, not all of these rules make sense for everybody, and many
of them are hardcoded. The regex lints you posted are a good example:
JSLint will complain about something like /[ab-]/ ("Unescaped '-'"), but
there's nothing wrong or ambigous about it. Adding escapes where none
are necessary is, IMHO, the opposite of good style. There are many other
examples, like the inability to call functions in a line earlier than
their declaration, the inevitable warning if functions are created in a
loop, and more regex hysteria.
To the best of my knowledge, there are no alternatives to JSLint, so we
have to take the good with the annoying, or do without a lint checker.
The JQuery team has decided to go with the latter option, which is
understandable, but it made them miss some of the issues you pointed
out. Personally, I usually just roll my eyes and change a few characters
to make JSLint happy, or use a wrapper script which lets me insert
inline comments to suppress JSLint output.
So, I don't see a problem with JQuery not passing JSLint. If you trust
the JQuery developers to write the code you're using, you might as well
trust them to decide which JSLint problems are worth fixing (as long as
they're aware of them, which they now are).
--
stefan
lorlarz
> On 01/03/10 20:22, lorlarz wrote:
>
> > On Mar 1, 12:45 pm, lorlarz <lorl...@gmail.com> wrote:
> >> You may be interested to know that in response to this JSLint barrage
> >> (which I have also contacted John Resig personally about), John
> >> has decided to make a couple of changes and is considering making
> >> a couple (or some) others. The following links, provided by J. Resig
> >> supposedly have something to do with 2 changes made so far:
>
> >> [snipped mangled link]
>
> >> He also said he has one thing to investigate and another he is unsure
> >> of.
> >> Also: It is also noteworthy that at least one of the errors cited
> >> by JSLint was seen as a real error _needing_ fixing.
>
> That's just a missing semicolon. It's not an "error _needing_ fixing"
> (in this case), and John Resig didn't say it was. It's good style to add
> the semicolon even if it's not strictly required, that's all.
>
> >> John Resig encourages people to keep up on any changes by getting
> >> the most recent release always:http://code.jquery.com/jquery-nightly.js
>
> >> I shall not pass any judgement on any of this.
>
> > P.S. John adds that he has also made this fix:
Stefan
Yes, indeed it looks like it was a semicolon that really
did _not_ need to be fixed, thus I misspoke.
I appreciate your assessment of jQuery. I do have yet to
see anyone, even the biggest critics, provide any information
about anything really wrong with jQuery -- in the sense that
something does not work (and when things like that come up,
they tend to be minor an tend to be caught by the jQuery
community itself).
The ones with the incredibly negative opinions of jQuery
have not, in my view, made a case. But I will be watching.
Here are the links to changes John Resig made (since one
link was apparently mangled in an earlier post):
http://github.com/jquery/jquery/commit/a18f682012ae8e63f3b43b39375b3c5ce0a561e3
http://github.com/jeresig/sizzle/commit/89dd2b35d51693f46b2043149243920b380ad474
http://github.com/jeresig/sizzle/commit/bba54187feed83914d9a83b4b74c51168e816073
Stefan Weiss
> On Mar 1, 4:29 pm, Stefan Weiss <krewech...@gmail.com> wrote:
>> So, I don't see a problem with JQuery not passing JSLint. If you trust
>> the JQuery developers to write the code you're using, you might as well
>> trust them to decide which JSLint problems are worth fixing (as long as
>> they're aware of them, which they now are).
> I appreciate your assessment of jQuery.
I don't use jQuery, and I haven't seen enough of its code to give any
sort of assessment, positive or negative. I was only talking about the
JSLint results. I do appreciate the manner in which they were received
(prompt fix, no excuses, no hyperbole).
> I do have yet to
> see anyone, even the biggest critics, provide any information
> about anything really wrong with jQuery -- in the sense that
> something does not work (and when things like that come up,
> they tend to be minor an tend to be caught by the jQuery
> community itself).
>
> The ones with the incredibly negative opinions of jQuery
> have not, in my view, made a case. But I will be watching.
A lot of problematic passages in JQuery have been identified and posted
in this group, mostly by David Mark. They can be a little hard to find
among all the noise, but there definitely are problems. Matt Kruse
recently posted a short meta-list of common complaints. It is
unfortunate that the person who usually finds these problems and the
person who could fix them are currently not on talking terms.
--
stefan
David Mark
> On Mar 1, 11:50 am, lorlarz <lorl...@gmail.com> wrote:
>> On Mar 1, 11:11 am, lorlarz <lorl...@gmail.com> wrote:
>>
>>
>>
>>
>>
>>> On Mar 1, 10:22 am, lorlarz <lorl...@gmail.com> wrote:
> [snip]
>
>
> You may be interested to know that in response to this JSLint barrage
> (which I have also contacted John Resig personally about), John
> has decided to make a couple of changes and is considering making
> a couple (or some) others.
Highly uninteresting as that's what he does. A couple of changes?!
He'll veto the rest as a waste of time.
> The following links, provided by J. Resig
> supposedly have something to do with 2 changes made so far:
>
> http://github.com/jquery/jquery/commit/a18f682012ae8e63f3b43b39375b3c5ce0a561e3
> http://github.com/jeresig/sizzle/commit/89dd2b35d51693f46b2043149243920b380ad474
He's only got 998 or so to go. :)
>
> He also said he has one thing to investigate and another he is unsure
> of.
So two more. And this will lead to another release, which will lead to
some small percentage of sites "upgrading" (and likely breaking), all
because he couldn't be bothered with QA for the first few years. Why
would anyone wait around for him to reach a suitable level of
proficiency? I don't think he'll ever get there.
> Also: It is also noteworthy that at least one of the errors cited
> by JSLint was seen as a real error _needing_ fixing.
I'm not shocked. They could have found it themselves. Who knows how
long it has been festering?
>
> John Resig encourages people to keep up on any changes by getting
> the most recent release always: http://code.jquery.com/jquery-nightly.js
I bet. But you can't re-download, re-test and re-deploy every freaking
day! Software is supposed to be tested by the authors _before_ it is
released.
>
> I shall not pass any judgement on any of this.
>
I shall. They suck at this stuff.
David Mark
I just don't care. It's 2010 and they still can't deal with basic DOM
inconsistencies in IE6 (which came out last century). These are not the
people you should look to for browser scripts. Their constant struggles
to get their 70K of BS up to par are just an irritation for those who
know they shouldn't have to struggle with something they claimed to have
mastered years ago.
David Mark
Then you haven't been paying attention. Not only have I pointed out a
boatload of things that don't work, but I have then documented the
futility that followed when they were informed about them (i.e. they
didn't fix the problems as they couldn't understand them).
>
> The ones with the incredibly negative opinions of jQuery
> have not, in my view, made a case. But I will be watching.
You just missed it somehow. The case was built over the course of
_years_ and it is airtight.
Here's one thing to look at:-
http://www.cinsoft.net/queries.html
Here's another:-
http://www.cinsoft.net/jquerysucks.html
Search the CLJ archive for tons more.
David Mark
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.
There _are_ and JSLint is oblivious to them (as is John Resig).
lorlarz
> On Mar 1, 1:22 pm, lorlarz <lorl...@gmail.com> wrote:
> [snip see 2 posts earlier for this material snipped}
>
> > P.S. John adds that he has also made this fix:http://github.com/jeresig/sizzle/commit/bba54187feed83914d9a83b4b74c5...
>
> > Unfortunately, he will not participate here and has basically
> > insisted
> > that these issues be discussed in the following forum:
>
> >http://forum.jquery.com/developing-jquery-core
>
> > (I did put my last big post (http://tinyurl.com/yc6gf5m) there,
> > as he seemed to request)- Hide quoted text -
>
> I have changed another correction I make to make sure jQuery is
> left at no wrong disadvantage. In my instructions for running
> the JSLint on jQuery 1.4.2 Development version, yourself:
> Change the instruction for line 2649:
>
> NOW: 2649 is to be changed to:
>
> context = context || document; var origContext = context;
>
> ** I reran JSLint and nothing whatsoever. **
>
> You will have to see earlier posts in this thread for
> other changes you must make to get jQuery 1.4.2 to
> get all the way through JSLint.
>
Holy crap. I have got to edit better. I am sorry.
While I may be inclined to be hopeful about
jQuery, I do not want to say something that indicates
it is anywhere close to getting a clean report on
JSLInt.
I wrote:
> ** I reran JSLint and nothing whatsoever. **
Wrong. Subject to great misinterpretation!!
What I meant was:
** 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.)
Big question is: which of these 'errors' are real errors and have
any importance. The last report of the errors reported by JSLint
are still all there (and I doubt the 3 things I had to comment
out to get JSLint to scan all the way through have anything to
do with them).
STILL, can someone simply fix the three things I had to comment out
so I can run JSLint with the complete jQuery fully intact? Please,
some regular expression guru. Help. This is a pressing need.
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.
>
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).
Stefan Weiss
> ** 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).
> Big question is: which of these 'errors' are real errors and have
> any importance. The last report of the errors reported by JSLint
> are still all there (and I doubt the 3 things I had to comment
> out to get JSLint to scan all the way through have anything to
> do with them).
What's a real error? None of them are syntax errors. None of them affect
the library's behavior. A few, like the while condition with several
side effects, are quite ugly, and I wouldn't like them in my code, but
they're valid enough. So what's a real error for you?
> STILL, can someone simply fix the three things I had to comment out
> so I can run JSLint with the complete jQuery fully intact? Please,
> some regular expression guru. Help. This is a pressing need.
I suppose I could look into it, but I don't see what good it would do.
You'd only be changing a local copy, and if you can't get convince the
developers to apply your changes, it's a waste of time. And why is it
suddenly so urgent?
--
stefan
David Mark
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.
Andrew Poulos
> lorlarz wrote:
>> On Mar 1, 6:27 pm, David Mark<dmark.cins...@gmail.com> wrote:
>>> 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).
Andrew Poulos
David Mark
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
> On 02/03/10 01:32, lorlarz wrote:
>
> > ** 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]
> --
> stefan
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:
lorlarz
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).
>
>
> --
> stefan
** 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
> On Feb 28, 11:52 pm, David Mark <dmark.cins...@gmail.com> wrote:
> [snip]
>
>> 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
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.
Stefan Weiss
> ** BIG UPDATE **:
> jQuery now passes JSLint 100% but with noted exceptions:
That's good news.
> 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
| 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.
| * "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. Funny, I never had a problem with this
warning; I usually either check for "really not null", or truthy.
Anything more complicated than that tends to end up in a function.
| * "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.
| 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 :only-child selector checks, reducing
| code and improving performance.
I suggested that JSLint should accept a /*fallthrough*/ comment here,
but Douglas Crockford didn't agree.
| 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. Which means that neither jQuery nor my code will
work alongside Prototype.js; I don't have a problem with that.
--
stefan
David Mark
> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> wrote:
>> On 02/03/10 01:32, lorlarz wrote:
>>
>>> ** 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]
>> --
>> stefan
>
> ** 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 :only-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
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 :only-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
> On Mar 1, 11:34 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>> "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.
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
> lorlarz wrote:
>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> 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.
[...]
>
> 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
comp.lang.javascript FAQ: http://jibbering.com/faq/
Garrett Smith
> On 02/03/10 04:57, lorlarz wrote:
>> ** 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
> David Mark wrote:
>> lorlarz wrote:
>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> 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.
>
> [...]
>
>>
>> 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();
>
>> ""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".
And round and round it goes. Regardless, it doesn't make sense to use
unfiltered for-in loops on the Web.
>
>> 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.
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. :)
>
>> "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"`.
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
> Stefan Weiss wrote:
>> On 02/03/10 04:57, lorlarz wrote:
>>> ** 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?
>
>> 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.
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
> 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
> David Mark wrote:
>> lorlarz wrote:
>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> 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.
>
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.
Richard Cornford
> 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"
Proof of what exactly?
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".
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?
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?
Richard.
David Mark
> David Mark wrote:
>> 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"
> <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
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. :)
Stefan Weiss
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.
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.
--
stefan
David Mark
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
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
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
Stefan Weiss
> On Mar 2, 3:28 am, Gregor Kofler <use...@gregorkofler.com> wrote:
>> 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?
> 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 ) {
The fact that "chunker" references a RegExp has nothing to do with the
JSLint warnings. JSLint's parser doesn't understand the comma operator
here; it can't make head or tails of the condition syntax, and exits
with an error ("unable to continue"). That's most likely because this
usage of the comma operator isn't part of Crockford's Good Parts.
The solution is to refactor the while loop, for example by replacing it
with do...while.
> // replace(/=([^="'>\s]+\/)>/g, '="$1">')
>
> and
>
> // jsre = /=\?(&|$)/,
JSLint: "A regular expression literal can be confused with '/='".
The author of JSLint thinks that the /= operator could be confused with
the start of these regular expression literals. To eliminate the
warning, escape the "=":
replace(/\=([^="'>\s]+\/)>/g, '="$1">')
jsre = /\=\?(&|$)/,
--
stefan
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
> On 02/03/10 04:57, lorlarz wrote:
>
> > ** BIG UPDATE **:
> > jQuery now passes JSLint 100% but with noted exceptions:
>
> That's good news.
>
>
>
>
>
> > Quoting a recent post from John Resig to the
>
> > 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:
>
> > 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
>
> --
> stefan- Hide quoted text -
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
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
> On Mar 2, 3:54 pm, lorlarz <lorl...@gmail.com> wrote:
> > [...]
> >
> > 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
<snip>
>>>/* while ( (chunker.exec(""), m = chunker.exec(soFar)) !==
> 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.
Stefan Weiss
> On Mar 2, 11:27 am, Antony Scriven <adscri...@gmail.com> wrote:
>> On Mar 2, 3:54 pm, lorlarz <lorl...@gmail.com> wrote:
>> > /* 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.
Yup. That condition made my eyes bleed.
> 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??
lolarz, this has already been fixed (you posted the announcement here
yourself). The problematic passage is part of Sizzle, and has now been
replaced with a do..while loop:
// 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
--
stefan
lorlarz
[snip]
>
> // 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
wrote:
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
> Garrett Smith wrote:
>> David Mark wrote:
>>> lorlarz wrote:
>>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> 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.
[...]
>> 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.
>
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.
>> 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".
>
> 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).
>
>> 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?
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.
[...]
>>>
>> 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?
[...]
lorlarz
> David Mark wrote:
> > Garrett Smith wrote:
>
> >> 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?
>
> [...]
> --
> Garrett
> comp.lang.javascript FAQ:http://jibbering.com/faq/
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.
Richard Cornford
>On Mar 2, 12:40 pm, Richard Cornford wrote:
>> On Mar 2, 6:06 pm, lorlarz wrote:
<snip>
>>>>>/* while ( (chunker.exec(""), m = chunker.exec(soFar)) !==
>><snip>
>>> 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)?
Is it reasonable to be asking supplementary questions when you have
neglected to answer the questions you have been asked?
<snip>
> 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.
Why equivalent code? An Equivalent outcome is all that is necessary. The
modified code posted by Stefan Weiss (and purported to originate with
Resig) is the equivalent of the original, in that it does everything
that the original does (plus a bit more), and it will have the same
outcome. However, it is an elaboration on a poor strategy for mitigating
the consequences of what informed judgment would have to categorise as a
mistake (setting the global flag on a regular expression that did not
need it).
My proposal is to correct the mistake, and then just remove the
'workaround' that is intended to mitigate its consequences. The result
is an overall simplification, but no change in outcome.
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.
> 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.
I doubt that anyone here cares.
Richard.
Antony Scriven
wrote:
> [...]
>
> 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
wrote:
> [...]
>
> 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;
}
}
Peter Michaux
> On Mar 1, 11:57 am, lorlarz <lorl...@gmail.com> wrote:
>
> > This might make a lot of JS people here mad, but I _want_ to use
> > jQuery. I just want to have all assurance or reasonable
> > quality control. At the very least, jQuery is very close to
> > OK. I just really want to know if there are any _real_ errors
> > that make things work wrong.
>
> 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:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> lorlarz wrote:
>>>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> 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. :(
>
> [...]
>
>>> 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.
>>
>
> 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.
>
>>> var f = new Function("return("+responseText");");
Typo, BTW.
>>>
>>> // 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".
>>
>> 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.
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).
>>
>>> 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?
>
> 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?
>
>> 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.
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.
>
> [...]
>
>>>>
>>> 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.
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
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
> On Mar 2, 5:18 pm, Peter Michaux <petermich...@gmail.com> wrote:
>> 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.
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.
>
>> 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.
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.
Garrett Smith
> On Mar 2, 5:18 pm, Peter Michaux <petermich...@gmail.com> wrote:
[...]
>
> But having said all that, I want to say again that I still use jQuery
> and recommend it.
>
Yes, I know you do, but do not understand why.
> 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,
The amount of code required to make possible css-selector queries is not
worth the amount of convenience it adds.
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.
>
So jQuery is good for simple things but not complicated things, huh? Can
you show us an example?
> 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.
Or maybe you started out studying and reading the pertinent standards
and jQuery is irrelevant to solving simple problems and probably a bad
choice for building sophisticated applications.
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.
>
If jQuery is the starting point, then how do you propose one advance
from that?
I fail to see how jQuery is good starting point for progressing to learn
how to program rich web interfaces.
Based on what you've written, you seem to indicate that you have not
moved on, but still in fact do use jQuery for simple things.
I recommend a different strategy: Read the pertinent standards (they are
listed in the FAQ), and study OOP and Agile programming, as it pertains
to TDD, interface design, and code organization.
Disclaimer: I am not a "wizard" just a guy who RTFM.
"Everybody wants to be a bodybuilder but nobody wants to lift no heavy
ass weights".
Garrett Smith
> Garrett Smith wrote:
>> David Mark wrote:
>>> Garrett Smith wrote:
>>>> David Mark wrote:
>>>>> lorlarz wrote:
>>>>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> wrote:
>>>>>>> On 02/03/10 01:32, lorlarz wrote:
[...]
> What do you think I meant? :)
>
I thought you meant 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.
>
> It's still a stupid name. :(
>
The comment in the code made sense to me. I understand why they do that.
They want undefined to be munged and faster lookup. The outcome should
be slightly smaller and slightly faster, and the code still looks
"normal" in the sense of comparing things to `undefined` in un-minified
code.
The only downside would be to rely on using `undefined` instead of
typeof, where the typeof helps swallow an error.
[...]
>>>> // Use grouping operator to avoid ASI-related error.
>>> Huh?
>>>
>> ASI = Automatic Semicolon Insertion. If the JSON response begins with a
>> line terminator.
>
> Yes.
>
[example]
>>
>> So it's safer to to use grouping operator there.
>
> Okay, but it that is not how your example reads.
>
>>>> var f = new Function("return("+responseText");");
>
> Typo, BTW.
>
Yes, but if responseText has the json after a line terminator, the
function will end up returning undefined.
Some APIs encourage the use of JSONP via dynamic script loading.
http://suggestqueries.google.com/complete/search?qu=fuck&jsonp=while
while(["fuck",[]])
Profanity results in a cleaner example here, the "while" method is a
joke. No innuendos there.
For XHR, a proxy would need to be used. If the proxy introduces a line
terminator -- and it is very easy to do this inadvertently -- then the
fist statement in the function would be "return", and the result of that
function would be to return undefined.
If it sounds like I tripped over this before -- I did.
>>>> // 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".
>>> 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.
>
> 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 don't really agree. I think modifying Object.prototype is wrong. If
you, the developer, add a script that modifies Object.prototype, my API
will not work properly. That is my contract to you.
[...]
>
> Why would anyone in their right mind use Dojo? Mass hysteria?
"We don't have time to write everything from scratch".
"There's no sense in reinventing the wheel".
"There is a lot of functionality that we can leverage".
Well that's the reasons I've been given. Writing a javascript library is
time consuming and the manager faced with a project wants to use
*something* and if Dojo is something of an industry standard, then that
becomes an option.
David Mark
> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> David Mark wrote:
>>>>>> lorlarz wrote:
>>>>>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...@gmail.com> wrote:
>>>>>>>> On 02/03/10 01:32, lorlarz wrote:
> [...]
>
>> What do you think I meant? :)
>>
>
> I thought you meant 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.
>>
>> It's still a stupid name. :(
>>
>
> The comment in the code made sense to me. I understand why they do that.
> They want undefined to be munged and faster lookup. The outcome should
> be slightly smaller and slightly faster, and the code still looks
> "normal" in the sense of comparing things to `undefined` in un-minified
> code.
How is it a good idea to make code look like something it is not?
>
> The only downside would be to rely on using `undefined` instead of
> typeof, where the typeof helps swallow an error.
And readers thinking - undefined - is something that it isn't.
>
> [...]
>
>>>>> // Use grouping operator to avoid ASI-related error.
>>>> Huh?
>>>>
>>> ASI = Automatic Semicolon Insertion. If the JSON response begins with a
>>> line terminator.
>>
>> Yes.
>>
> [example]
>
>>>
>>> So it's safer to to use grouping operator there.
>>
>> Okay, but it that is not how your example reads.
>>
>>>>> var f = new Function("return("+responseText");");
>>
>> Typo, BTW.
>>
>
> Yes, but if responseText has the json after a line terminator, the
> function will end up returning undefined.
Yes, unless you stripped the leading line terminator. But what does any
of this have to do with the above example (which has a typo?)
>
> Some APIs encourage the use of JSONP via dynamic script loading.
Yes.
>
> http://suggestqueries.google.com/complete/search?qu=fuck&jsonp=while
> while(["fuck",[]])
>
> Profanity results in a cleaner example here, the "while" method is a
> joke. No innuendos there.
I don't follow that at all. How is using a profanity "cleaner" and what
is the joke?
>
> For XHR, a proxy would need to be used. If the proxy introduces a line
> terminator -- and it is very easy to do this inadvertently -- then the
> fist statement in the function would be "return", and the result of that
> function would be to return undefined.
Yes.
>
> If it sounds like I tripped over this before -- I did.
That's how you learn about things. I've heard of these issues, but I
can't make heads of tails of any of your examples.
It's not about right and wrong. It's about the reality of deploying a
script on the Web (at least for scripts that must run on any random page).
>
>
> [...]
>
>>
>> Why would anyone in their right mind use Dojo? Mass hysteria?
> "We don't have time to write everything from scratch".
Well, get some programmers who aren't fresh off the banana boat and you
very likely won't be writing much of anything from scratch (and you sure
as hell won't be using Dojo!)
> "There's no sense in reinventing the wheel".
See previous answer and realize that Dojo is not a wheel. It's a whole
bunch of mostly unrelated scripts, most (especially at its core) are
inarguably rotten and clearly written by people who are both unfamiliar
with Javascript and certainly new to the world of cross-browser
scripting. They certainly haven't invented any wheels, they don't have
any wheel blueprints and as somebody who has been through _all_ of their
code, it is my studied opinion that they wouldn't recognize a wheel as
such if they saw one. Furthermore, based on interactions with their
developers, I don't see this changing ever. They say they are working
on some wildly new version for release in 2011 or something, but why
would anyone wait around for that bunch to put out another load of drivel?
> "There is a lot of functionality that we can leverage".
You'll leverage yourself right into bankruptcy. The stuff is all based
on browser sniffing, so you will be in maintenance hell forever. Do you
really want to be asking them why your app has broken (again) and be
told that it is because version xyz never claimed to support IE9 (or
IE10 or Safari 5 or whatever). Furthermore, do you want to have to
explain to your visitors after the requisite "upgrade" fails to support
IE8 (or Safari 4 or whatever) that they are out of luck if they can't
immediately upgrade their browsers? And what about browsers that the
Dojo developers have never heard of or "don't care" about? You'll find
that visitors using those browsers will dutifully stop caring about your
sites. Of course it is a moot point as the whole bloated mess is
perfectly unsuitable for use on the Web anyway, which is why you never
see it out there. No amount of disingenuous "wowie" marketing (as
recently proposed in their forum) is going to make people mistake it for
something usable.
>
> Well that's the reasons I've been given. Writing a javascript library is
> time consuming and the manager faced with a project wants to use
> *something* and if Dojo is something of an industry standard, then that
> becomes an option.
And what defines an "industry standard?" Wide-spread use. Scratch
that. Perhaps some small portion of it is best in class? Not even
close. Take two examples, queries and Flash. Dojo's is renditions are
awful and unusable respectively. Of course, you can build your own
library with far better modules at:-
http://www.cinsoft.net/mylib.html
...and get support from me, rather than the people who wrote Dojo. It's
a no-brainer. Dojo has more modules, but quantity doesn't count for
much in this business, particularly when people aren't going to need
anywhere near all of them. Their modularity is a joke (everything
requires virtually everything else) and their widgets are so obviously
incompetent as to insult your intelligence (e.g. slow as molasses,
crawling with browser sniffs, accessibility nightmares, primary "owner"
of them is demonstrably out of his mind, etc.)
I could go on and on about Dojo and "Dijit" and the rest of their
bullshit and I very likely will. Libraries and the loose nuts behind
them are themes of the new site I've been working on. The two test
pages and counterpoint example library are just for starters. A review
of Dojo 1.4 will be one of the first features and will also be the first
one I've done on the Web (with lots of pretty code examples) rather than
on Usenet. Anyone who can get all the way through it and still thinks
Dojo is a good idea would have to be... well, one of the Dojo authors. :)
Garrett Smith
The value is the same as window.undefined.
>> [...]
>>
>>>>>> // Use grouping operator to avoid ASI-related error.
>>>>> Huh?
>>>>>
>>>> ASI = Automatic Semicolon Insertion. If the JSON response begins with a
>>>> line terminator.
>>> Yes.
>>>
>> [example]
>>
>>>> So it's safer to to use grouping operator there.
>>> Okay, but it that is not how your example reads.
>>>
>>>>>> var f = new Function("return("+responseText");");
>>> Typo, BTW.
>>>
>> Yes, but if responseText has the json after a line terminator, the
>> function will end up returning undefined.
>
> Yes, unless you stripped the leading line terminator. But what does any
> of this have to do with the above example (which has a typo?)
>
>> Some APIs encourage the use of JSONP via dynamic script loading.
>
> Yes.
>
>> http://suggestqueries.google.com/complete/search?qu=fuck&jsonp=while
>> while(["fuck",[]])
>>
>> Profanity results in a cleaner example here, the "while" method is a
>> joke. No innuendos there.
>
> I don't follow that at all. How is using a profanity "cleaner" and what
> is the joke?
>
No, if you try a non-profane word:
http://suggestqueries.google.com/complete/search?qu=fuck&jsonp=while
Then the resulting jsonp function call arg has a lot of results.
[...]
I read through the rest but did not have time to reply.
David Mark
Yes, the value is. Still seems like a silly idea to use that name as
the local identifier.
Okay. And yeah, at second glance I get the joke, but why make a joke in
an example?
>
> [...]
>
> I read through the rest but did not have time to reply.
I don't remember what the rest was. :(
Andrea Giammarchi
all this fuss around JSLint.
I have already commented "JSLint The Bad Part" and everybody seems to
agree about the fact JSLint is for Junior, is an extra hint during
development, but surely it's not the bible.
The == null is a JSLint *error*, specs clearly says that there is NO
COERCION against null.
null == undefined AND null == null are the only TRUE value, everything
else compared with null and == will be FALSE.
The only thing that JSLint should do to avoid blames against
developers that MEANT something, is a bloody flag:
/*jslint ignore:true*/ ... the code you meant like that ... /*jslint
ignore:false*/
or
/*jslint meant:true*/ ... the code you meant like that ... /*jslint
meant:false*/
This will make JSLint useful to get all "gotchas" and document or
ignore all those piece of code that should be exactly like that.
This will make good JS code as jQuery is valid and will make all those
developers unable to understand WHY IT'S NOT AN ERROR happy (plus
automation against validation)
I tried to sign into the JSLint group but AFAIK I am not in yet to
propose this change.
Regards
David Mark
> JSLint does not accept more prepared/expert developers and I don't get
> all this fuss around JSLint.
What does that first part mean?
>
> I have already commented "JSLint The Bad Part" and everybody seems to
> agree about the fact JSLint is for Junior, is an extra hint during
> development, but surely it's not the bible.
It's good for spotting mistakes (like typos), as well as ambiguous and
or potentially problematic structures. It's not meant to be a bible.
You should be able to interpret the results, else it will just confuse you.
>
> The == null is a JSLint *error*, specs clearly says that there is NO
> COERCION against null.
>
> null == undefined AND null == null are the only TRUE value, everything
> else compared with null and == will be FALSE.
You would seem to have (loudly) contradicted yourself. Two (2)
warnings, unable to continue. :)