New jQuery announced!

[David Mark]

But it has the same old attr method.

attr: function( elem, name, value ) {

// don't set attributes on text and comment nodes

Don't pass them! Put that in the docs.


if (!elem || elem.nodeType == 3 || elem.nodeType == 8) {
return undefined;
}

Don't pass null, 0, '', undefined, etc. for elem either. What would
be the point of this, other than to make it harder to find bugs?


if ( name in jQuery.fn && name !== "attr" ) {
return jQuery(elem)[name](value);
}


It's the do-everything function.


var notxml = elem.nodeType !== 1 || !jQuery.isXMLDoc( elem ),
// Whether we are setting (or getting)
set = value !== undefined;


They still seem to think this method is appropriate for XML. Why not
call get/setAttribute on XML nodes? That's all this ends up doing.


// Try to normalize/fix the name
name = notxml && jQuery.props[ name ] || name;


Normalize/fix? And jQuery.props is still a long way from complete:-

jQuery.props = {
"for": "htmlFor",
"class": "className",
readonly: "readOnly",
maxlength: "maxLength",
cellspacing: "cellSpacing",
rowspan: "rowSpan",
colspan: "colSpan",
tabindex: "tabIndex",
usemap: "useMap",
frameborder: "frameBorder"
};

How many years does it take for a million code monkeys to come up with
the list of attributes that have camel-case property names? More than
three apparently.


// Only do all the following if this is a node (faster for style)


What?!

if ( elem.nodeType === 1 ) {

// These attributes require special treatment
var special = /href|src|style/.test( name );


What sort of "special" treatment? How are href, src and style
related?


// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
}

Mystical incantation.

// If applicable, access the attribute via the DOM 0 way

Read its property?

if ( name in elem && notxml && !special ) {

So, if it is - in - the elem, elem is not an XML node and it is not
href, src or style, get or set the property.


if ( set ) {
// We can't allow the type property to be changed (since it
causes problems in IE)
if ( name == "type" && /(button|input)/i.test(elem.nodeName) &&
elem.parentNode ) {
throw "type property can't be changed";
}

Misguided waste of space.

elem[ name ] = value;
}

// browsers index elements by id/name on forms, give priority to
attributes.
if( jQuery.nodeName( elem, "form" ) && elem.getAttributeNode
(name) ) {
return elem.getAttributeNode( name ).nodeValue;
}
// elem.tabIndex doesn't always return the correct value when it
hasn't been explicitly set
// http://fluidproject.org/blog/2008/0...and-removing-tabindex-values-with-javascript/


That article is very confused.


if ( name == "tabIndex" ) {
var attributeNode = elem.getAttributeNode( "tabIndex" );
return attributeNode && attributeNode.specified
? attributeNode.value

That's a string.


: /(button|input|object|select|textarea)/i.test(elem.nodeName)
? 0

That's a number.


: /^(a|area)$/i.test(elem.nodeName) && elem.href
? 0
: undefined;
}


So, tabindex is treated very oddly, returning a string, number or
undefined. This attribute is singled out because that article singled
it out. This is programming by observation of misinterpreted
observations.


return elem[ name ];
}

Then it switches gears to attributes.

if ( !jQuery.support.style && notxml && name == "style" ) {
if ( set ) {
elem.style.cssText = "" + value;

What sort of value would this be that it would make sense to convert
it to a string?


}
return elem.style.cssText;
}

if ( set ) {
// convert the value to a string (all browsers do this but IE) see
#1070


LOL. I'll pass on #1070. They seem to think all IE's are the same.
Of course, IE8 varies wildly here depending on the mode.


elem.setAttribute( name, "" + value );


But they already "fixed" the name (converted to a property name):-

// Try to normalize/fix the name
name = notxml && jQuery.props[ name ] || name;

This doesn't make any sense. By coincidence, the - in - check above
keeps some properties out of here. One that would fall through (in
some browsers, e.g. FF) is "onclick". Passing a function like this:-

attr(el, 'onclick', function() { ... });

Would set an odd attribute indeed, considering what
Function.prototype.toString does. Of course, if the property existed
previously, the previous fork would apply and the method would seem to
work.

}
var attr = !jQuery.support.hrefNormalized && notxml && special
// Some attributes require a special call on IE

More than they know.


? elem.getAttribute( name, 2 )
: elem.getAttribute( name );

This will vary across IE versions and modes.

http://www.cinsoft.net/attributes.html


// Non-existent attributes return null, we normalize to undefined


They don't in IE (except IE8 standards mode).

return attr === null ? undefined : attr;
}

// elem is actually elem.style ... set the style
// Using attr for specific style information is now deprecated. Use
style insead.
return jQuery.style(elem, name, value);
}

I thought they were going to re-factor this for 2010? I thought they
would install at least some versions of IE for testing as well. Maybe
next year.

So they still have trouble reading documents. Odd handicap for a DOM
library. And how many times have they been told about these
problems? They did like the event detection bit. I don't care for
the copy and paste implementation though.

// Technique from Juriy Zaytsev

I guess they didn't read the article.

// http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/
var eventSupported = function( eventName ) {
var el = document.createElement("div");
eventName = "on" + eventName;

var isSupported = (eventName in el);

Spotty inference. Keeps IE out of the following:-

if ( !isSupported ) {
el.setAttribute(eventName, "return;");
isSupported = typeof el[eventName] === "function";

Won't work in IE6/7 or 8 in compatibility mode. But by coincidence,
those never get here. Standard IE8 should get here, but relies on the
weaker inference above.

}
el = null;

return isSupported;
};

 

[David Mark]

But it has the same old attr method.  

And a new removeAttr "companion" method!

removeAttr = function(el, name ) {
attr( el, name, "" );
if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Keeping with the confusion about attributes/properties, this also
tries to do both (poorly). Basically, this sets a property or an
attribute to "" (creating one if it does not exist). Then it tries to
remove the attribute.

The first line attempts to set a property in IE. So this, for
example, will throw a wonderful exception in IE < 8 or IE8 in
compatibility mode:-

removeAttr(el, 'colspan'); // Boom

I added a jQuery set to the attribute tests and found that, in
addition to all manner of inconsistencies and errors in IE, FF throws
an exception on using attr to set DOM0 event handler properties (due
to the aforementioned Function to string conversion). They've really
got the DOM bumps smoothed over now.

After three years of testing and discussion, how can these bugs exist
so deep in the core? The only answer is that the authors and
community have failed to live up to their press clippings. The
revered unit tests are obviously flawed to the point of being useless
(not surprising as they were written by the same people who wrote the
code). Same for the docs. You just can't test or document what you
don't understand. But when things go wrong, you can always blame the
browsers, users, etc. Those heroic Ninjas are doing the best they
can.

 

[Matt Kruse]

removeAttr(el, 'colspan'); // Boom

Why would you do this, other than to break things?

I added a jQuery set to the attribute tests and found that, in
addition to all manner of inconsistencies and errors in IE, FF throws
an exception on using attr to set DOM0 event handler properties (due
to the aforementioned Function to string conversion).

Why would you do this, other than to break things?

Obviously the code is still not perfect, but as long as you use it for
its intended purposes, does it cause problems?

I don't think a lib should be bullet-proof against users trying to do
things that they aren't supposed to do.

Matt Kruse

 

[Michael Haufe (\TNO\)]

Why would you do this, other than to break things?

Quality code is measured not only by common usages, but by how it
handles edge cases as well. I for one welcome these types of reviews,
not having time to do them myself.

Obviously the code is still not perfect, but as long as you use it for
its intended purposes, does it cause problems?

If a method claims to remove an attribute, you would assume it could
remove an attribute regardless of what it is.

I don't think a lib should be bullet-proof against users trying to do
things that they aren't supposed to do.

If you're a developer trying to maintain someone else's code, and you
see that they are using library X, it would be nice to know that you
can look at a method library and assume it does what it's advertised
to do.

 

[Michael Haufe (\TNO\)]

If you're a developer trying to maintain someone else's code, and you
see that they are using library X, it would be nice to know that you
can look at a method library and assume it does what it's advertised
to do.

correction: "method library" -> "method of that library"

 

[David Mark]

Why would you do this, other than to break things?

Why would I do what? Remove an attribute? To get back to the default
colspan, I expect. Why does the method exist at all?

And you do understand that this is but one example.

Why would you do this, other than to break things?

See above.

Obviously the code is still not perfect, but as long as you use it for
its intended purposes, does it cause problems?

First you would have to define its intended purposes. The logic of
jQuery's attr/removeAttr "pair" demonstrates a stunning lack of
comprehension about basic DOM operations? The unfounded assumptions
that stick out are:

1. Attributes and properties are the same thing
2. All versions and of IE treat attributes and properties the same

As for #1, the domain and range for an attribute-based function is
quite different from that of a property-based function. If you look
at what jQuery does in attr, it clearly shows a botched design that
has been fiddled with just enough to make their limited unit tests
work. There's no rational logic present, so clearly the authors have
no idea what they are doing with attributes or properties. (!)

As for #2, pressing the compatility mode button in IE8 changes the
behavior of these functions. As these functions (attr at least) are
used in every jQuery example and book ever written, it seems ludicrous
that they should fail even in an IE8-only environment (unless you
somehow locked out compatibility mode as an option).

And the mere demonstration (even if these functions weren't used
pervasively) of such monumental incompetence and apathy (as you know,
they've been told about this problem numerous times) should be enough
to convince you that the effort is worthless. If a DOM library makes
it _harder_ to read/write/remove attributes and/or read/write
properties (note the difference), what purpose is it serving?
Browsers don't have any trouble doing the latter and you rarely need
to do the former.

It also displays that the unit testing is worthless. How can it pass
such obviously broken logic (and why would you need them to tell you
it is wrong?) When you write software as a series of haphazard
observations, you end up with a haphazard collection of unit tests,
each confirming a sighting. It's the bugs (or implementation
variations) they don't see (and therefore don't test for) that cause
the problems.

I don't think a lib should be bullet-proof against users trying to do
things that they aren't supposed to do.

What the hell does that mean? What is it you think these functions
are supposed to do? Is there some white list of attributes/properties
that are allowed by jQuery? And I can't believe I'm asking you any of
this. Are you some other Matt Kruse or are seriously starting this
ridiculous discussion again?

jQuery does _not_ simplify DOM scripting. The authors do _not_
understand DOM scripting or the Javascript language and especially not
IE. The CSS selector stuff is ludicrous and incompatible with QSA.
Almost every browser "supported" by jQuery _has_ QSA now anyway. The
animations are third-rate, everything it does is incredibly slow,
inefficient and resource intensive. It leaks memory, throws
exceptions, sets expandos and many other bad practices (and yes it
still uses forms of browser sniffing too). And the much-cited
documentation is horrible (look up attr and removeAttr for examples).
You couldn't pick a worse script and you know it (and the whole idea
of picking one script for every context is the ludicrous anyway).

I think that about says it. Feel free to silently skulk off.

 

[David Mark]

Quality code is measured not only by common usages, but by how it
handles edge cases as well. I for one welcome these types of reviews,
not having time to do them myself.

Seems most who don't are using or advocating the library in question.

If a method claims to remove an attribute, you would assume it could
remove an attribute regardless of what it is.

Yes and it seems reasonable to assume it will not throw an
exception.

If you're a developer trying to maintain someone else's code, and you
see that they are using library X, it would be nice to know that you
can look at a method library and assume it does what it's advertised
to do.

Yes, that's the main selling point for these libraries. That and the
great support. Unfortunately, as is the case here, the support from
the community often turns into chiding (you are using it wrong),
defensiveness (it's just an edge case) and ultimately petulance. No
wonder seemingly every "Dear jQuery" message in the forums starts out
with "I really love jQuery, but..," or "Don't get me wrong, it's
great, but..."

It's not enough you have to put up with bugs and constant revisions,
but you must be positively obsequious to deluded neophytes just to get
them to field questions. Then their answers are invariably and
predictably of the shit variety. Seems a very rough way to go, mostly
taken by those without an alternative.

 

[RobG]

Why would you do this, other than to break things?

To test the code?

Given the vaguaries of browsers, I would expect a unit test for
library methods that add and remove HTML attributes and properties
would test every standard attribute and property in as many browsers
as is reasonable - adding, modifying and deleting, including cases
where attributes are set or omitted in the source HTML.

[...]

Obviously the code is still not perfect, but as long as you use it for
its intended purposes, does it cause problems?

If there are shortcomings, they should be documented. Paricularly if
there are methods to modify attributes and properties that will fail
with particular values that should be expected to work.

I don't think a lib should be bullet-proof against users trying to do
things that they aren't supposed to do.

You can only say users "aren't suppposed to do" something if either it
is *very* well known that something causes an issue or there's
documentation to say "don't to it".

Is there any jQuery documentation listing the standard HTML attributes
that won't be correctly handled by removeAttr?

 

[rf]

To test the code?


Is there any jQuery documentation listing the standard HTML attributes
that won't be correctly handled by removeAttr?

Perhaps the function should be called
removeSomeAttrsButPotLuckWhichOnes.

 

[David Mark]

Perhaps the function should be called
removeSomeAttrsButPotLuckWhichOnes.

The _very_ funny thing is that (as mentioned) it's a two line
function. Let us see if we can pin its failings on the hapless
users.

removeAttr = function(el, name ) {
attr( el, name, "" );
if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Hmmm. First line looks out of place. You'd think it would be in the
conditional clause (or not there at all as it is doing the opposite of
removing an attribute).

Question #1: What other type of node makes sense here?

The second line is obviously the right host method call.

Question #2: What could have gone wrong with this call to make them
add the first line?

Question #3: Why would a function designed to remove attributes add
one (or set a property to '' in some cases) as its first order of
business?

That's more questions than there are lines of code, so I think it
makes sense to simplify the equation at this point:-

removeAttr = function(el, name ) {
if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Don't really need that nodeType test (should be documented). But more
importantly, the host method call will fail for _some_ attributes in
IE < 8 and IE8 compatibility mode. Anybody who has scripted an MSHTML
DOM (or read this group) knows exactly why. Broken MSHTML
implementations want a property name here (in most cases). It's been
like that since the 90's and was only recently fixed in IE8 (standards
mode).

Now imagine you have no idea of the cause. There are two ways to go:
research (e.g. try MSDN) or haphazard observations. Clearly the
latter was chosen, leading to a mystical incantation rather than a
solution. Should have been clear to the authors that their
incantation is not only illogical, but it doesn't work at all. Surely
the unit tests would catch this, but then the unit tests were written
by the same confused people.

So these examples (among others) will not work:-

removeAttr(el, 'colspan'); // Boom
removeAttr(el, 'rowspan'); // Boom
removeAttr(el, 'longdesc'); // Silent failure

Imagine one of the Ninjas testing that last one, which has a
corresponding string property. They can't figure out why the
attribute won't go away. It might seem a reasonable "workaround" to
them to set the corresponding property to '' as they clearly don't
understand the difference between attributes and properties. Perhaps
they dismissed the other two as "edge cases".

So three years into building this "wonderful" DOM scripting library,
jQuery still can't read (or write) documents. And it's not as if they
haven't been schooled.

That covers #2 and #3, as for the first:-

The attr method tangles up properties, attributes _and_ style.

removeAttr(el.style, 'color'); // el.style.color = '';

That's just silly, but there it is. Great API. Concise and simple
and "just works" as long as you avoid attributes/properties that throw
errors or fail silently.

It's obvious why most Web developers see basic DOM scripting as
impossible. Never mind cross-browser scripting, this crap won't even
be consistent in an IE-only environment. Something that seems to work
in IE7 may well fail in IE8 (and vice versa). If developers only know
jQuery, the only recourse is to post to their mailing list. A typical
synopsis would be "My app used to work in IE and now it doesn't.
PLEASE HELP!!" As even well thought out messages on this subject have
been ignored or mistakenly dismissed over the years, the chance of
getting any satisfaction from the Ninjas seems nil.

So I can't see the selling points. Perhaps those completely
unfamiliar with browser scripting might be able to copy and paste an
example from a book and modify it a bit. I suppose that gullible site
owners might look at such things in IE and FF and think they are
really cool, but the honeymoon won't last.

 

[Matt Kruse]

On Dec 7, 6:04 pm, "Michael Haufe (\"TNO\")"

Agreed. I make exceptions for client-side js, because the size and
speed of code is important. It is better to make it clear in the API
docs what should and shouldn't be passed into functions rather than
doing lots of type-checking of arguments, etc. That stuff can be left
in a "debug" version, however.

As David says early in his criticism:

// don't set attributes on text and comment nodes
Don't pass them! Put that in the docs.
....

Seems most who don't are using or advocating the library in question.

I definitely welcome these kinds of reviews and criticisms. I only
wish there was less snarkiness, better formatting, and a lot less
bias. I am thankful for David's continued criticism of jQuery et al,
because it lets people know of the short-comings and also points of
things that the developers can work on. These aren't perfect
solutions, but are works in progress. jQuery especially has made
progress and addressed some criticisms like browser sniffing, etc. Yet
some people ignore the progress and instead focus on the stuff that
still needs work.

That may not be a justified assumption. It can do whatever it wants,
but should be clear and documented. There are exceptions and
unsupported conditions to many methods and algorithms.

If the docs are not clear about the exceptions and situations where
the assumed behavior will not work as you might expect, then the docs
should certainly be corrected if the code is not. For example,
obviously the attr() method is meant to only set string properties.
I'm not sure why anyone would want to pass a function(){} to attr()
when you can use the event methods instead. But as David points out,
if you try to it will fail. This kind of stuff should be clearly
documented. I don't think it's a bug (it's unintended use of the
function) but the decision to NOT work in this way should be
intentional, not just an unintended side-effect of poor coding. Which
may be the case here, I don't know.

Matt Kruse

 

[David Mark]

[...]

For example,

obviously the attr() method is meant to only set string properties.

It is not set up, nor is it designed for string properties. Which of
these will check a box in jQuery?

attr(el, 'checked', true);
attr(el, 'checked', 'true');
attr(el, 'checked', '');
attr(el, 'checked', 'checked');

Bonus, in which browsers?

I've seen all of them in practice and lots of questions about this and
similar issues in the various jQuery support forums, blog posts, etc.

I know the first works for most, except for XML, which jQuery seems to
want to support with this method. See how mixing up attributes and
properties and trying to support both XML and HTML DOM's all in one
magic function has led to an interface with so many wires crossed it's
hard to predict the outcome of even one single menial line of code.
Now imagine an array of components and plug-ins built on top of this
rickety foundation. Of course, you don't have to imagine it. You've
blogged about it. Predictably, it's all a bunch of unpredictable,
ever-shifting rubbish.

Don't ask me what the other three do (or in which browsers). I'd have
to go back and look at the code again. That cannot be a good sign
when I have to read the code to predict what the thing will do to the
DOM. Where does that leave the average code monkey? In the jQuery
mailing list where nobody has a clue what is going on under the hood
of this clunker.

Glad you liked the review (as much as I could be glad about it). Now
stop using this junk.

 

[Michael Haufe (\TNO\)]

Why is nobody writing a competing library, maybe a good subset
of jQuery, but without the foul spots?

No doubt there are, but I think its safe to say they don't have the
same marketing and/or don't care to share.

There is an obvious need for such a critter, otherwise people wouldn't flock to jQuery,
and I wouldn't like to miss it either.

Define what you mean when you say "...such a critter"

Why isn't anyone sending John Resig a big, fat set of test
cases?

Time better spent elsewhere?

 

[Matt Kruse]

It is not set up, nor is it designed for string properties.

Oops, meant to say attributes.

 Which of
these will check a box in jQuery?
attr(el, 'checked', true);
attr(el, 'checked', 'true');
attr(el, 'checked', '');
attr(el, 'checked', 'checked');

I don't even know, because I'm not sure why anyone would do that.

I've seen all of them in practice and lots of questions about this and
similar issues in the various jQuery support forums, blog posts, etc.

Agreed. It is a side-effect of people trying to "jQuery-ize"
everything in their code. It's ridiculous to use a lib method like attr
() just to check a checkbox.

Although, I have done something like this:

$(':checkbox[name=foo]').run("this.checked==true");

run() is obviously a little eval wrapper that I plugged into jQuery. I
like using jQuery to conveniently grab a set of elements that I want
in order to manipulate them, but I don't really like it's methods that
do the manipulation.

I know the first works for most, except for XML, which jQuery seems to
want to support with this method.

I think they try to support XML because of XHTML. It seems terribly
misguided, and I don't know what rationale they have for doing it, if
any.

Glad you liked the review (as much as I could be glad about it).  Now
stop using this junk.  

I will when there is a suitable replacement that fills a variety of
needs better than jQuery does (despite its problems, if you use jQuery
only for the things it does do well and avoid the problem areas, it's
very convenient). How's the Dojo work coming?

I would really like to see a long, formal analysis of jQuery. Since it
still seems to be the dominant js framework available, I would like to
have a polished, well-written critique of its design decisions and
code quality, pros and cons, so everyone could properly evaluate the
library and decide if and when to use it. If it were written as a
wiki, it would allow multiple contributors to this group to refine the
writing and would probably become a valuable resource for the
thousands of developers on the web who are using the library.
Unfortunately, those who have the knowledge and expertise to write up
such an analysis rarely have the time or interest in doing so. So the
blind following the blind continues...

Matt Kruse

 

[David Mark]

David,

it is really a pity. The fundamental ideas of jQuery,
particularly to use CSS selectors and a functional style of
programming, are sound, as far as I can tell, and they often
allow you to write as a one-liner, what would otherwise be half
a page of JavaScript code.

I suppose any library of functions can make that claim. I don't
care for querying by CSS selectors though. To do it in older browsers
requires a heart-stopping amount of error-prone code. The typical
jQuery line takes 10,000 function calls to do what a few lines of JS
could do with standard host methods. I think reliability trumps the
number of lines of code every time (and what do lines of code matter
if the end result is minified?)

Why is nobody writing a competing library, maybe a good subset
of jQuery, but without the foul spots? There is an obvious need
for such a critter, otherwise people wouldn't flock to jQuery,
and I wouldn't like to miss it either.

Most professionals who write JS can see the folly in choosing one
monolith in advance for every context, so they don't write such
things. I made an exception a couple of years back (Google "browser
scripting library" and click the first hit). It is a functional API
with an optional jQuery-like (but competently designed) "chainable" OO
interface (or you could write your own that is exactly like jQuery if
that's what you really want). I don't recommend using such interfaces
as they just slow things down, but at least mine is a fairly
"unobtrusive" layer.

I don't really care to market a free library, but if anyone cares to
help with the documentation, evangelizing, etc. they have whatever
limited support I can muster.

Why isn't anyone sending John Resig a big, fat set of test
cases?

What good would that do? He needs to understand why. It was
explained to him years ago (by me). He didn't get it then and
apparently he's still in the dark today.

 

[Garrett Smith]

Oops, meant to say attributes.

As in:
| obviously the attr() method is meant to only set string attributes.

jQuery.attr has specific handling for many odd cases. What does attr
have to do with:

| if ( name == "selected" && elem.parentNode )
| elem.parentNode.selectedIndex;

That's a boolean property, not an attribute, right?

Or:
| if ( !jQuery.support.opacity && name == "opacity" ) {
| if ( set ) {
| // IE has trouble with opacity if it does not have layout
| // Force it by setting the zoom level
| elem.zoom = 1;

A method dealing with attributes working to do modify style properties
of objects, then providing workarounds for IE, not checking to see
currentStyle.hasLayout (the object migh have a layout already).

That method is doing way too much.

I don't even know, because I'm not sure why anyone would do that.

Probably to try and check a checkbox. What attr does is not entirely
distinct. It's sometimes attributes, other times properties.

I've seen all of them in practice and lots of questions about this and
similar issues in the various jQuery support forums, blog posts, etc.

Agreed. It is a side-effect of people trying to "jQuery-ize"
everything in their code. It's ridiculous to use a lib method like attr
() just to check a checkbox.

Although, I have done something like this:

$(':checkbox[name=foo]').run("this.checked==true");

run() is obviously a little eval wrapper that I plugged into jQuery.

That sounds dangerous. Calling eval, you know the thisArg and Variable
is from the calling context. Eval works differntly in ES5, but that's on
the horizon as far as implementations are concerned. Passing in
something that is used in the calling context would be modifying variables.

[sni[p]

I will when there is a suitable replacement that fills a variety of
needs better than jQuery

Such as?

I would really like to see a long, formal analysis of jQuery. Since it
still seems to be the dominant js framework available, I would like to
have a polished, well-written critique of its design decisions and
code quality, pros and cons, so everyone could properly evaluate the
library and decide if and when to use it. If it were written as a
wiki, it would allow multiple contributors to this group to refine the
writing and would probably become a valuable resource for the
thousands of developers on the web who are using the library.
Unfortunately, those who have the knowledge and expertise to write up
such an analysis rarely have the time or interest in doing so. So the
blind following the blind continues...

If you really want it, then do it. I'll provide feedback on it and
comments to your efforts.

 

[Garrett Smith]

As in:
| obviously the attr() method is meant to only set string attributes.

jQuery.attr has specific handling for many odd cases. What does attr
have to do with:

| if ( name == "selected" && elem.parentNode )
| elem.parentNode.selectedIndex;

Note that the statement inside the if test is entirely useless, as it is
not assigned to anything.

 

[Matt Kruse]

Matt Kruse wrote:
| obviously the attr() method is meant to only set string attributes.
jQuery.attr has specific handling for many odd cases. What does attr
have to do with:
| if ( name == "selected" && elem.parentNode )
|    elem.parentNode.selectedIndex;
That's a boolean property, not an attribute, right?

I didn't look at the source closely enough. I thought they got rid of
accessing properties of elements and went purely to get/setAttribute.
I was incorrect. Disappointing.

Probably to try and check a checkbox. What attr does is not entirely
distinct. It's sometimes attributes, other times properties.

Indeed, which has been David's criticism for a long time. It looks
like Resig still doesn't get it.

$(':checkbox[name=foo]').run("this.checked==true");
run() is obviously a little eval wrapper that I plugged into jQuery.

That sounds dangerous.

Not if you know what you are doing. I use it for very simple things,
to avoid lots of anonymous functions.

Such as?

Documented well
Lots of examples
Printed material available for developers to read from
An active support community
Active development and bug fixing
Supported by various editors and environments
etc

If you're just a stand-alone developer choosing the best tool, jQuery
may not be the best pick. If you're trying to organize a team of 10-20
developers, some onshore some offshore, all of differing experience
levels, who all need to touch the js of the webapp, then having a tool
like jQuery is very important. In my experience, I have found that
without such a library the code quality is consistently lower and the
number of problems is way higher. jQuery sure has its problems, and
it's not a perfect solution, but it's way better than the other
alternatives I've found. When I find a better option, I'll switch.

If you really want it, then do it. I'll provide feedback on it and
comments to your efforts.

That would be great, but I have no desire to write it. I know what
problems I have with jQuery, and I code around them. If I were being
paid for it, I would certainly write such an article

Matt Kruse

 

[David Mark]

It is not set up, nor is it designed for string properties.

Oops, meant to say attributes.

 Which of
these will check a box in jQuery?
attr(el, 'checked', true);
attr(el, 'checked', 'true');
attr(el, 'checked', '');
attr(el, 'checked', 'checked');

I don't even know, because I'm not sure why anyone would do that.

I've seen all of them in practice and lots of questions about this and
similar issues in the various jQuery support forums, blog posts, etc.

Agreed. It is a side-effect of people trying to "jQuery-ize"
everything in their code. It's ridiculous to use a lib method like attr
() just to check a checkbox.

Although, I have done something like this:

$(':checkbox[name=foo]').run("this.checked==true");

run() is obviously a little eval wrapper that I plugged into jQuery.

Dear God.

I
like using jQuery to conveniently grab a set of elements that I want
in order to manipulate them, but I don't really like it's methods that
do the manipulation.

That is inconvenient. All grabbed up and nothing to do with them.

I think they try to support XML because of XHTML. It seems terribly
misguided, and I don't know what rationale they have for doing it, if
any.

That applies to most of the script.

I will when there is a suitable replacement that fills a variety of
needs better than jQuery does (despite its problems, if you use jQuery
only for the things it does do well and avoid the problem areas, it's
very convenient).

And... how would one know what the problem areas are? Also, how is
it convenient to have to upgrade something that is constantly changed
to (sort of) keep up with just the latest major browsers, usually
breaking backwards compatibility in lots of little ways?

How's the Dojo work coming?

I rewrote virtually all of it in competent fashion last summer. Of
course...

So, in my limited spare time, I have been working on a new scrapbook
of code (working title is My Library, Too) and accompanying book.
Basically, it's the foundation that jQuery, Dojo, etc. should have
started with in the first place (they can't really go back now).

I would really like to see a long, formal analysis of jQuery.

Haven't you seen enough?

Since it
still seems to be the dominant js framework available, I would like to
have a polished, well-written critique of its design decisions and
code quality, pros and cons, so everyone could properly evaluate the
library and decide if and when to use it.

I've done all I can do in that area. Perhaps somebody else should
aggregate and format the information as they see fit.

If it were written as a
wiki, it would allow multiple contributors to this group to refine the
writing and would probably become a valuable resource for the
thousands of developers on the web who are using the library.

So set it up.

Unfortunately, those who have the knowledge and expertise to write up
such an analysis rarely have the time or interest in doing so. So the
blind following the blind continues...

Exactly.

 

[David Mark]

Note that the statement inside the if test is entirely useless, as it is
not assigned to anything.

It's a mystical incantation. See the related comment.

And yes, jQuery's attr doesn't know what it wants to be. Some of it
deals with attributes (substituting undefined for null when they are
missing), other bits will cheerfully return DOM defaults/
interpretations and even user input. (!)

I tried to replicate both the realAttr and prop patterns from my
attribute test page and neither was do-able with the jQuery methods.
As it sits, I have almost 100 picky unit tests for each method and
nothing outside of the presented wrappers can come close to passing
them. jQuery can't even pass the gauntlet without blowing up (several
times). (!) I will post the results shortly (new chapter: J is for
Junk).

For something that is focused on querying the document, jQuery is
startlingly illiterate. As for writing (e.g. removing attributes), it
is prone to throwing exceptions, failing silently, stepping on user
input, etc. It's a stretch to think the authors are going to suddenly
"get it" after all of these years of futility. Same goes for the rest
of the open source Frankenscript projects. Those who can rarely
bother constructing ill-advised monoliths as context is what keys
competent browser scripting designs.

You had asked before about why such methods would ever be necessary
and as I'm working on that chapter, I have given it some more
thought. For one, a CSS selector query should ignore DOM defaults,
user input, etc. For two, a more practical concern is form
serialization. We know that determining the value of a SELECT
requires at least a hasAttribute wrapper (in case the selected option
has a value of ''). ISTM that WYSIWYG editors would need a clear and
consistent view of the underlying markup as well.