From: Matt Kruse on 11 Dec 2009 09:03
On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> 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.
> >> 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.
> 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.
> >> 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
> Such as?
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
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.
> > 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.
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 :)
From: David Mark on 11 Dec 2009 09:38
On Dec 9, 12:37 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Dec 8, 3:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> > > obviously the attr() method is meant to only set string properties.
> > 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:
> run() is obviously a little eval wrapper that I plugged into jQuery.
> 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 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
That applies to most of the script. :(
> > 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).
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
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...
From: David Mark on 11 Dec 2009 09:56
On Dec 11, 2:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Garrett Smith wrote:
> > Matt Kruse wrote:
> >> On Dec 8, 3:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> >>>> obviously the attr() method is meant to only set string properties.
> >>> It is not set up, nor is it designed for string properties.
> >> 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;
> 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
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.
From: David Mark on 11 Dec 2009 10:03
On Dec 11, 6:40 am, Stefan Weiss <krewech...(a)gmail.com> wrote:
> On 11/12/09 08:35, Garrett Smith wrote:
> > Garrett Smith wrote:
> >> 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.
> The two lines above the quoted part are:
> // Safari mis-reports the default selected property of a hidden option
> // Accessing the parent's selectedIndex property fixes it
This looks like another confused "bug report" that has been translated
to "logic". It is clear that the "default selected property" is not
what this function is after (defaultSelected corresponds to the
We know they intend for this thing to read properties (mostly), so
talk of defaults is evidence of them losing their way. The mention of
a "hidden option" confirms the confusion as there is no way a user
could select something they can't see.
> It would appear that this was intended as a bug workaround, and that
> reading the selectedIndex property is all that's required. Still, it's a
> strange thing to do, and could very well be optimized away by a minifier
> tool or by the JS engine itself.
Definitely not something to rely on.
From: Matt Kruse on 11 Dec 2009 11:13
On Dec 11, 9:31 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> > 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.
> Sounds like you need new programmers. What could be lower than
> jQuery's code?
You must live in a bubble.
I regularly see code that is much, MUCH worse. Less predictable. Less
robust. Less stable.
Telling a team that is writing bad code to "just use jQuery" can
instantly improve performance, reduce bugs, and improve cross-browser
support. Is it perfect? No. But it's better than the status quo. And
it's regularly updated, documented, supported, etc. It takes very
little effort to make a big improvement in code quality. That's why
jQuery is valuable.
Now, if you never have to deal with such a situation, then you're in
luck. No wonder you can't see the value in jQuery.
Think of it this way - When js code quality is at a 1 or 2 on a scale
of 1-10 (10 being best), then introducing jQuery and raising it to a 4
or 5 with virtually no pain is an obvious win. Versus trying to raise
it to an 8 or 9 with considerable coding, time, cost, coaching,
documentation, testing, etc. In a perfect world we could all set our
sights high to ideal coding practices, but in the real world many
people deal with, lowered expectations helps maintain sanity.
Especially when js code quality is less of a concern compared to
other, bigger problems.