2007 / July 15^th/ Why I don’t use jQuery

It’s been said a few times elsewhere, but statistics is a tricky business. Specifically, when using statistics to measure speed improvements. It’s all too easy to slap a sticker on your product with labels like “500% faster!” or “20% more!” — but what does it really mean?

800% faster!!!!!

The idea for this article came about when I read the exploding article all over the interwebs titled: jQuery 1.1.3: 800%+ Faster, still 20KB. If you’re a Javascript developer and just read that, jQuery starts looking mighty promising. Hot damn, 800% faster!?

What is faster?

Well, it turns out they really mean: “Improved speeds, with DOM traversal over 800% faster than in 1.1.2.” Oh, you mean 800% faster DOM Traversal. Well, still that’s damn good! But I’m kinda feeling conned. It’s like saying my car’s 800% faster, and then you find out it’s just my wheels are lighter and can get up to speed 800% faster than before.

And then if you actually look at the results, really that’s 800% mean improvement. The low end is 740% (a 100% difference). Also, you’ll note these results are based off CSS3 selectors. It doesn’t even test CSS 1 or 2 selectors, which are by far the most commonly used selectors in Javascript (Actually, I would bet less than a percent of javascript selectors are CSS3 based at this time).

Manipulating the truth

It’s not that jQuery lied. But they didn’t exactly tell the truth either. What they did was massage their statistics to better (mis)inform the public. By choosing to reveal specific, obscure statistics that show the framework in good light, they’ve made their audience think the whole of the framework is better/faster/stronger than the others. Is it? I don’t honestly know: but I do know the statistics provided do not reach this conclusion.

Frameworks are personal

One of my co-workers asked me a few days ago why I don’t use jQuery. There’s no particular technical reason, it’s just that I’ve always found the development team a bit too “my e-penis is bigger than yours” if that makes much sense. It started off with jQuery misleading the pack and has even been brought up to John publicly in conferences (The Ajax Experience in Boston, for example). I guess it’s these types of reasons I don’t use jQuery: because I don’t particularly want to be associated with a dev team that feels the need to jab other developers to promote their product. I like to use products who promote themselves through their code and results.

But in the end it doesn’t really matter much. John and the team have done a great job with jQuery, and it’s no doubt a great framework. But perhaps it’s just not for me. In the meantime though, I’d appreciate it if they took a little less time (mis)leading people in their blog posts, and a little more time showing off what’s great about jQuery.

1. 

   alvin

   July 16^th | #

   I don’t think John and co. necessarily manipulated the truth. It seems pretty obvious, at least when I first read the release post, that the ‘800% improvement’ is a measurement in relative to their previous DOM engine. At best, you can say that the shortened title is somewhat misleading but there’s so much noise in blogsphere nowadays you can’t really blame anyone for using a controversial or sensational title.

   As for ‘e-penis’, well, everyone does it. Dojo has an article about why they are different from everyone else. Spry and YUI too. And I have heard more than my fair share of prototype’s fanboys stories.

   You can write about why you don’t use Jquery or YUI or etc, but at least be objective about it. Dismissing any web technologies because of its inherently positive argument (I dont think by stating jquery is 800% faster, it is out to promote a negative campaign towards other library) is a bit, uhm, naive I think.

2. 

   stephen

   July 16^th | #

   Like alvin, I don’t see anything John/jQuery wrote that is unlike the self-promotion of most any other JS framework. Besides, if you go by Slicktest, jQuery really needed a speed boost, so I’m actually happy to hear about the improvements in 1.1.3 (although, admittedly, they test against 1.1.2dev). But that’s beside the point. I honestly didn’t find the misleading at all — after all, it says in plain English that the performance increase refers specifically to DOM traversal. Maybe if you go by the headline alone, it could be misconstrued, but c’mon… Everyone should know better than to take a headline as the whole story, no matter WHO the source is.

3. 

   Kyle

   July 16^th | #

   I’m not sure if you guys caught that part that this is DOM Traversal with CSS3 selectors. Huge difference there, in my opinion. And while perhaps you guys didn’t feel mislead — I know there were quite a few IM’s I got asking me what I thought about jQuery being so much faster than any other framework now. It definitely mislead quite a few people.

   Alvin: I think you missed the entire last section of my post. The one where I said why I don’t choose to use jQuery. Dismissing it? Hardly.

4. 

   Rubynho

   July 16^th | #

   What about the article by Jack Slocum (ExtJS fame):
   * CSS Selectors - Speed Myths - http://extjs.com/blog/2007/07/10/css-selectors-speed-myths/#more-6

   The features of jQuery that are important and are not myths make it a good enough framework for general use, which gives the jQuery proponents the confidence to promote it. Features such as non-intrusive JavaScript which plays well with other JavaScript libraries, support for most browsers which is an ongoing job, community that supports the newbies, and so on…

   At the end of the day, speed is about making tradeoffs, profiling, and so on, which can mean that entire JavaScript libraries may turn out to be mostly inadequate when the demand for speed is too great.

5. 

   TRH

   July 16^th | #

   Bravo!

   At least you had the courage to say your opinion which is what a blog is about!

   Apparently any time anyone disagrees with the current software propaganda going on then they get hammered a bit..

   JQuery is nice conceptually - there are also other issues (which may have been corrected - should I repeat the last few words for those that speed read over entire paragraphs and pretend to comprehend?) such as sockets code for other platforms such as prototype - those should be on the front of their website under: “Issues” so everyone knows them up front.

   Good article and to ‘free’: what a commentary…what purpose does that serve?

   TRH

6. 

   tom

   July 16^th | #

   That’s pretty much what Steve Jobs does when he busts out the reality distortion field for new products, particularly when referring to processor speeds (but my favorite is the fudging of iPod HD capacities via rounding).

   Seems to be [sadly] a commonly accepted behavior within various computing-related industries. I tend to ignore statistics in general, and marketed statistics altogether, since they can be easily warped by whoever is crunching/presenting them (especially when the stats are in their favor).

   Thanks for the informative analysis, however!

7. 

   John Resig

   July 16^th | #

   Kyle - interesting entry, but really coming out of left field for me. I’ve been a long-time reader of your blog (at least a couple years now) and was a big fan of Total Spore back when it launched.

   I’m really confused as to the tone of your post. Some important points to consider:

   The primary focus of jQuery is on DOM selection. It’s absolutely core to the construction and use of jQuery. 1/2 of every jQuery statement is a DOM selector. Thus, when the speed of DOM selection improves, the speed of the framework, as a whole, improves.

   We’re very proud of the speed improvements that we made in 1.1.3 - our goal for this recent release was to improve our own personal speeds, and that’s what we did. We focused completely on that. We didn’t “massage” a single iota of statistics, we were very careful about that. To be completely fair we use an unmodified copy of Mootools’ SlickSpeed test suite and left the suite, and the results, online for anyone to try out and verify. Everyone has been pleased with the results, and we are too.

   The only metric that we truly succeeded on was in selector speed in Internet Explorer 6; and as you’ll see with Ext’s latest numbers, Jack has come around and beaten us all again. That’s the way these things work. Thankfully we’ve grown a lot since the first selector comparisons, but that has only helped to benefit the users - giving them an incredibly fast framework to use.

   An important thing to realize is that you can’t ‘not know’ if one framework is faster, or not. It can be pretty clear that it’s the case - especially when everyone is using the same test suite (SlickSpeed) to test their code. Nothing was manipulated to reach the conclusions that we did - and it’s pretty easy to see the same results.

   Your statement on CSS 3 selectors especially confuses me - you do realize that the CSS 3 specification encompasses CSS 1 and 2, right? And that all the major JavaScript frameworks support CSS 1-3? There’s no crazy trickery at play here. We used the same test suite that Mootools used - and it has a variety of focus (CSS 1, 2, and some 3 - even a single XPath selector!).

   As far as the “e-penis” statement goes - you are grossly misinformed (and out of date; that post is almost a year old at this point). Here is, in no particular order, a number of collaborations that we’ve taken up:

   • I’ve worked with Alex Russell, and the Dojo team, to help standardize the functionality for an OpenAjax integration library.

   • I’ve worked with Tobie Langel and Andrew Dupont to help find and fix bugs in Prototype, and to integrate the Prototype test suite into the Mozilla test base. I’m also working with Tobie on a fun, related, side project.

   • I’ve met and worked with the Yahoo UI team, traded tips, and discussed ways to help them standardize their test suite.

   • I’ve talked shop and traded tips with Jack Slocum, of Ext, on numerous occasions. We even collaborated and got Ext to run on top of jQuery.

   • I’ve worked with all of these groups to try and standardize a CSS Selector test suite for further study and comparison. Some great progress is being made on this.

   Additionally, the statement about “showing off what’s great about jQuery” is a little bit strange. Did you see the rest of the entry? Assuming that you don’t think that selector speed is an important feature, you can see all of the other features and fixes that we rolled into 1.1.3 - and the announcement of jQuery UI, and the jQuery books, and the jQuery conference. All of this together is what makes jQuery great. It’s excellent code, with a fantastic community, coming together to do some great JavaScript work.

   I’ve really liked your blog posts and especially your recent analysis of JavaScript frameworks, but I absolutely find this article to be lacking, I guess I expected better from of you. I hope you’ll decide to give jQuery a try, someday.

8. 

   Kyle

   July 16^th | #

   John, I guess I am guilty of judging one by it’s previous covers. As I’m not an active developer of jQuery: I don’t particularly follow your news until it hits the “front page” as so it were to speak. I think it’s great you guys are working with each other: it gives me a better base to start off with no matter the framework I choose.

   In reference to the CSS3 selector test: I was referring to lumping the results together. If we take the selectors from body to #scene1 #speech1 (what I would consider “common” selectors), we see a 300% improvement (Firefox2) which is less than half the speed improvement claimed in Firefox2. To me, as a developer: these are the selectors I’m caring about. More often than not I’m not doing any crazy selectors. Again, much like Apple touted the new Core Duo’s as 4x faster: even though these tests were done under helpful conditions.

   I think that’s what got to me. I have a personal irk with anyone who massages statistics (and trust me, almost everyone that throws out stats today is guilty of this).

   It puts me at a disadvantage as a developer when I’m dealing with semi-technical clients who read headlines like “800% faster” and stop right there. Then I try and explain to them that perhaps jQuery isn’t the best fit (say we’re doing a lot of Drag & Drop work, which while there’s stuff in the works for jQuery, there’s tried and true solutions for YUI/MooTools).

   Don’t get me wrong John, I love jQuery very much (even though I don’t use it), especially since it has helped push so many ideas onto other frameworks. But perhaps it’ll take me another year or so to get over the prototype bashing :) (that hurt, personally). In the future, I’ll try and not assume so much, and give you more benefit of the doubt.

9. 

   Nate Cavanaugh

   July 16^th | #

   I can’t really say anything that John hasn’t more eloquently stated, but here is my question:

   Who in the world chooses a library/framework/whatever based on emotional criteria like the one described above?
   Perhaps you’re indulging in a bit of hyperbole, but I would think that a libraries marketing should be dead last on the priority list of why you wouldn’t use something.

   I can think of a few reasons not to use jQuery, even though I am a part of the team (smallish contributions), but I can think of reasons to not use almost any library, including Prototype.
   It doesn’t mean they’re all crap, but it means that nothing is perfect, and that what is tasty for some is inedible for others.

   I guess overall I am disappointed because I would love to see some actual technical criticisms, not anal nitpicking over the fine print.

   And yes, jQuery’s javascript penis is quite enviable. I’ve seen it.

10. 

    Kyle

    July 16^th | #

    Nate: I would say most people choose frameworks based on non-technical reasons, actually.

    When you’re first browsing frameworks, there’s usually a half-dozen that share common features or the features you need. Even today, while I prefer MooTools I can’t say that comparable frameworks like Prototype + Script.aculo.us, or ext, or YUI don’t share common features. None can do something the other can’t (relatively speaking). The difference for me, is left up to the community (highly motivated by the development team), and overall image the framework choses to project.

    As I’ve explicitly said several times before this is why I with a giant capital I, me, myself, and I sticker don’t use jQuery.

11. 

    stephen

    July 17^th | #

    Kyle: You’re right, I should probably drink my own Kool-ade before offering it to others. I did gloss over the part where you mentioned CSS3 selectors, and my initial response reflected that. However, I’m glad John weighed in with his explanation that CSS3 encompasses 1-3.

    I myself have not committed entirely to any one framework yet, although I’m duly impressed with MooTools, Prototype, and jQuery at this stage.

12. 

    Casey Wise

    July 17^th | #

    As a programmer, I’m reading your thoughts to glean something insightful from your programmer brain. This article raised the question in my head “Why would Kyle Neath seek to discredit the jQuery library?”

    We tested MooTools, Dojo, ProtoType, Ext and jQuery (they had just released 1.1.2). I honestly couldn’t tell a difference between them. Our development team picked jQuery because we saw how active John and his team were/are in the jQuery Google discussion group.

    Regards,
    Casey Wise

13. 

    Kyle

    July 17^th | #

    Casey, exactly where did I discredit jQuery library?

14. 

    Andy Kant

    July 17^th | #

    @Nate
    I’d agree with Kyle that a lot of decisions are based on non-technical reasons. Another example: All the hate for Microsoft despite that their development technologies (C#, .NET, CLR/DLR, Visual Studio) are head and shoulders above almost most other technologies. C# is probably one of the best things to ever happen to software (including the Mono implementation), but a lot of people shrug it off due to disliking Microsoft.

    As far as JS frameworks though, I tend to prefer Mootools as well. Nothing against jQuery or any other framework, I just prefer Mootools’ organization, cleanliness, and coding style.

    Honestly, as dumb it sounds, the main reason that I don’t use jQuery is because its source code isn’t particularly readable. Inconsistent white-space and obscure internal object naming makes it difficult to navigate.

15. 

    riper

    July 20 | #

    you blame them just because they made a marketing anouncement…
    the lib is great, maybe “800% faster…” doesn’t mean anything but it still a great lib

16. 

    Rick

    August 20 | #

    I have found jQuery’s community/authors way more helpful and willing to help compared to other frameworks (points at MooTools).

    Of course, it doesn’t say anything about the code itself. I have used both, preferred MooTools for a while, but then I saw that in most projects I was working on, jQuery fitted better. Unless you’re writing science project in Javascript, I’d say DOM manipulation is the most important thing a framework should highlight. It’s the most practical.

17. 

    Anonymous

    August 29^th | #

    “I have found jQuery’s community/authors way more helpful and willing to help compared to other frameworks (points at MooTools).”

    There’s an extensive debate about that in ajaxian.com, in which I participated. Basically I just found unfair the popularity jQuery haves, and the misunderstood potential of mootools, because you have to learn 1h more how a real OO framework works to make the things right (if you have no experience with frameworks), and with jQuery you can do your effect for retarded people. I personally prefer to understand what I’m doing, because a js framework is for devs not for designers, even if they want to add cool effects to their blogs. Instead of that, use mooFX designers!

18. 

    A prueba: Frameworks Javascript — yukei.net

    September 15^th | #

    […] paso, también recordé un artículo de Kyle Neath, en el que reflexionaba sobre el anuncio de lanzamiento de jQuery 1.1.3, tentadoramente titulado […]

19. 

    Constantine

    December 1^st | #

    Nice

20. 

    W.ordPress » A prueba: Frameworks Javascript

    December 23^rd | #

    […] paso, también recordé un artículo de Kyle Neath, en el que reflexionaba sobre el anuncio de lanzamiento de jQuery 1.1.3, tentadoramente titulado […]

Name

Email (will not be published)

Website (optional)