Friday, February 19th, 2010

jQuery 1.4.2: performance and a few APIs

Category: JavaScript, jQuery

jQuery 1.4.2 has been released today and it comes with some performance bumps (aggressive ones according to Taskspeed). Benchmarks are challenging, and John even calls that out:

For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $(“body”) selector because it’s called hundreds of times within the tests. Additionally we saw large gains by optimizing .bind() and .unbind() by a fraction of a millisecond – an inconsequential amount – especially considering that any cases where you would bind hundreds of events you would likely want to use .live() or .delegate() instead.

There are some new APIs a bunch of them around ergonomics:

In this release we’ve added two new methods: .delegate() and .undelegate(). These methods serve as complements to the existing .live() and .die() methods in jQuery. They simplify the process of watching for specific events from a certain root within the document.

For example:


  1. $("table").delegate("td", "hover", function(){
  2.     $(this).toggleClass("hover");
  3. });

This is equivalent to the following code written using .live():


  1. $("table").each(function(){
  2.     $("td", this).live("hover", function(){
  3.         $(this).toggleClass("hover");
  4.     });
  5. });

Additionally, .live() is roughly equivalent to the following .delegate() code.


  1. $(document).delegate("td", "hover", function(){
  2.     $(this).toggleClass("hover");
  3. });

The jQuery team continues to really put the pedal to the metal.

Posted by Dion Almaer at 6:59 pm

3.5 rating from 79 votes


Comments feed TrackBack URI

Congrats, good work. The race continues. Bring on Dojo vNext ;-)

Comment by sos — February 19, 2010

Great! It has to make you wonder though, how slow and inefficient jQuery was before, and how inefficient it still is. It seems like ever few months they come out with these HUGE SPEED INCREASE announcements.. but geez, how slow was it before? makes me wonder..

Comment by leptons — February 19, 2010

Here’s a MooTools plugin to do the very same !

Comment by sixtyseconds — February 20, 2010

Good stuff! I hope for the 1.4.3 release the jQuery team adds require().
I like what is proposed here:

Comment by Les — February 20, 2010

“For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $(“body”) selector because it’s called hundreds of times within the tests.”

So… That shiny graph at the top is relevant if your app is silly enough to call $(‘body’) hundreds of times. (?)

var body = document.body; // No jQuery necessary


Comment by DavidMark — February 20, 2010

So, where is the article on My Library?
/points David Mark to ‘contribute news’ link in top menu.

Comment by BenGerrissen — February 20, 2010

David, we meet again. As with your posts on the Dojo list, please be mindful of your tone, as it tends to be overly aggressive and offputting.

Is you “My Library” the modified version of Dojo? In that case, I’d imagine that only people on the dojo-committers mailing list are aware of it, and the Ajaxian folks can certainly be excused for not following your every move. If you haven’t even given it a name yet….

I looked for info on your library, but doesn’t work. Where/what is it?

Comment by sos — February 21, 2010

Well, how hard should I have to look for a library that Ben & Dion should be fully aware of? At the very least, should have a landing page, or David could have posted a link in his comment, rather than asking why we weren’t all fully aware of his work.

Comment by sos — February 22, 2010


it doesn’t (always) matter what is faster, introducing/using a library is about community, stability, documentation… who cares how fast something is if nobody can discuss with other users, it crashes or you don’t even know how to use it properly. (theres more, but in the interest of time)

jQuery does this and this is its strength, the fact that it can compete with the streamline libraries too, and keeps getting faster… well that’s just sexy ;`x

Comment by Loque — February 22, 2010

If you wasn’t such an arrogant douche in your way of writing i might even read your posts one day. You wont change people’s view on “My Library” by trying to make jQuery look bad. Instead admit that the work done on jQuery is awesome, but there is other alternatives out there. Why do many people fail to understand that all the work done one many of these open source libraries benefits us all. I bet “My Library” would never have been what it is today without learning from all the others and that goes all the way around.

Comment by Iumentum — February 22, 2010

I have to agree that David’s tone and attitude is wack…

I will add a column for their latest incompatible script-of-the-month.

well David, I hope other people return the same courtesy to you if you ever make a mistake or have something up with code related to a project of yours…

And on what planet is it sane to swap out complicated scripts every other month?

Who said you had too, and guess what jQuery is dam stable doing this anyway, I know! also… I think it was almost a year between 1.3* and 1.4*, meh, ZzZz

Comment by Loque — February 22, 2010

Awesome, I’m looking forward to running 1.4.2. Also, does anyone know if there is a performance benefit to using delegate() in place of live(), or is it just syntactic sugar?

Comment by WillPeavy — February 22, 2010

For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $(“body”) selector because it’s called hundreds of times within the tests.

This sounds worrying to me. Is this optimization in any way written to help the user, or is it (as it sounds) purely to make jQuery look better in the almighty Taskspeed pissing contest? I would suggest that there are hundreds of better ways for the jQuery team to spend their time.

Comment by timdown — February 22, 2010

@davidmark it probably help to not insult peoples…

But then again, I would not expect you to do anything else.

Comment by karnius — February 22, 2010

> is there a performance benefit to using delegate() in place of live()?

Yes, but mostly because it makes setting your context very explicit. It’s possible to do with live() but with really awkward syntax. Therefore most live() calls are bound at the document level, which is very wasteful from a delegation point of view. Using delegate makes you do delegation in the best way possible, and reduces delegation overhead by like 80% or so.

> Taskspeed pissing contest?


While they certainly will help the user, they likely have a more direct impact on the sort of tests in taskspeed. (IMHO the document.body optimization is smart and worthwhile) And FWIW it was less than a day of development time for John, so not a lot of time spent. :)

Comment by PaulIrish — February 22, 2010

Benchmarks for the most part are not very useful, they are more like a guide. The $(body) example shows that if you code for the benchmark you can get outstanding numbers but in the end doesn’t really help anyway. Video card companies got caught up in the “code for the benchmark” crap a while back and reputations were harmed for years because of it.
As for My Library, I think i shall never try it based solely on the attitude of DavidMark. But this quote from his site I find amusing: “My Library works in browsers that do not yet exist. Furthermore, it works in theoretical browsers that may never exist.” That’s just funny.
But I still don’t understand this need for raw speed in most cases. So one library finishes a severe task, that most people will never actually use in a real-world project, less than half-a-second faster than another library. So what? If the library one uses completes the task at hand in a timely manner and suits the coding style of the person using it then what difference does it make?

Comment by travisalmand — February 22, 2010

@travisal well DOM traversal and injection can be quite slow, it can make a small difference, specially on IE, on large documents

But at this point, it’s more about the style of framework you like than speed for sure.

Comment by karnius — February 22, 2010

Despite the Ajaxian community’s general opinion of David, he’s also an epic troll by the looks of it; posting some slander and then disappearing while the rest of us reply about his general lack of humanity… xD

Comment by sixtyseconds — February 23, 2010


I have to disagree. I’ve had an extended debate with David here, for at least a couple days past the posting of the parent article, and he did nothing of the sort. Those whose answer to David is to attack his character are both missing the point and disarming your arguments against his points (insofar as you have them). He knows quite a bit more about the subject than he tends to let on, and is quite a bit more involved in the Javascript libraries communities than he tends to let on as well.

* * *


With all of the above said, I hope you’ll consider that your argument style does your own argument no justice, and you’d do well to frame your objections to jQuery (some of which are well-founded and others of which should be challenged) in a more informative and less combative manner. I said this the last time we went back and forth, and almost jumped in for another back and forth here but got distracted and I expect it’s too late to pick it back up now.

Comment by eyelidlessness — February 23, 2010


DavidMark is not a troll. He has a deep understanding of JavaScript and browser differences. You can learn a lot from some people if you can put up with their communication style.

Comment by Les — February 23, 2010

@eyelidlessness + @Les – I meant no offence by that remark. :) David has a very aggressive communication style, but you can’t fault the man for technical knowledge…

Comment by sixtyseconds — February 23, 2010

Hey guys , check this feature, a good way to use easeOutBounce…

Comment by AndreAssis — March 11, 2010

seems amazing these numbers, gonna rock !!

Comment by agenceweb — March 16, 2010

Leave a comment

You must be logged in to post a comment.