New jQuery announced!
in [JavaScript]
|
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? 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. > > 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 :) Matt Kruse
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: > > $(':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 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. 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 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.
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 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.
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 SELECTED _attribute_). 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. Matt Kruse |