Monday, December 22nd, 2008

jQuery 1.3 beta: Sizzling and feature testing

Category: jQuery

jQuery 1.3 beta 1 has been released with John and the team asking for testing help.

This is a big release as a lot has been changed:

  • Sizzle has been integrated
  • No more browser testing: For example, no more if ( jQuery.browser.msie && !jQuery.isXMLDoc(this) ) { which is replaced with if ( ! && !jQuery.isXMLDoc(this) ) {
  • Live event delegration: Reglib’s claim to fame was how event delegation was “live” meaning that if you added elements later on, they would also fall into the same delegations. With $("#foo > div").live("click", someFn); you get the same in jQuery
  • $(this).closest("div");: Returns this or closest ancestor that matches selector
  • .offset() rewrite – significantly faster, uses no browser sniffing.
  • .hide()/.show() rewrite – 50% – 200% faster.
  • .append/prepend/before/after rewrite – 10-15x faster.

Posted by Dion Almaer at 1:39 pm

3.8 rating from 64 votes


Comments feed TrackBack URI

Looks good.

I’ve been wanting to try out sizzle for a while now.

Comment by JimNeath — December 22, 2008

I thought it was 1.6.
but well, I’m very enthusiast to test it.

Even if I don’t see jQuery as a bottleneck in my realtime JS application, that’s always good to hear that jQuery is even faster than before.

Comment by gokudomatic — December 22, 2008

@gokudomatic: You’re thinking of jQuery UI – the next release of UI (which should be before the end of the month) will be 1.6.

Comment by JohnResig — December 22, 2008

ajaxian? why not $(‘.foo’).delegate(“click”, f….); Hmm maybe you can “delegate” other things than just events or live saves some extra bytes :D

Comment by Aimos — December 22, 2008

@Aimos: We’re not using the name ‘delegate’ because it isn’t normal event delegation (not to mention that there are already a number of delegate plugins using that name). Typically when someone wants to do full delegation they also want to specify the root element – e.g.: $(“#someroot”).delegate(“div”, “click”, someFn); We wanted to provide something that was much simpler than normal delegation but still leave room for people to write their own full delegation code/plugins.

Comment by JohnResig — December 22, 2008

excited…there has been quite for some time now…I was following JR’s work and he seemed too busy for jQuery. Thanks JR for your selfless efforts toward the community. You’ve got my respect!

As per jQuery I am excited there are more speed improvements and I am excited that event delegation is included into the core.

As per jQueryUI… there is stil a loooot to do. Personally I would be glad to see a perfect tree component (dragging, in-place edits, obviously ajax loads, context menus, etc) and a perfect modal window, for now I have to be happy with thickbox.

Keep up with good work!

Comment by DamirSecki — December 22, 2008

John, can you give a little more info on that? Don’t mean to make you retread anything from the devlist or in the trac (which is down, by the way — can’t you guys switch to Google Code or some other service that doesn’t suck?), but in what ways besides syntax does $(‘#someroot div’).live(…) differ from your hypothetical $(‘#someroot’).delegate(‘div’,…)? What would be the benefit of the future “full delegation” plugins that you’ve left room for?

Comment by dtetto — December 22, 2008

Someone set up a slickspeed with jQ 1.3 beta please.

Comment by Aimos — December 22, 2008

Can’t wait to have a go.

Comment by kim3er — December 22, 2008

Woot… jQuery rocks! Time to start upgrading all my plugins.

Comment by ramaboo — December 22, 2008

Here you are.

Comment by bcse — December 22, 2008

@bcse: Thanks for that.
Strange, in FF3 the old jQuery seems to be faster (according to SlickSpeed). O_o

Comment by LeaVerou — December 23, 2008

Thanks bcse, here my results for everyone. I did a quick test with 4 browsers: Opera 9.63, IE7, FF3 latest and Chrome XP, all patches, german, fast Core2Duo E6600 or so PC.
In Chrome, the new jQuery is 3x faster, in FF3 a little slower, in IE7 equal and in Opera slightly faster.
You can also see the “overhead” of jQuery compared to Sizzle.
IE7: Sizzle: 172ms, jQuery: 216ms
FF3: Sizzle: 23ms, jQuery: 128ms
O9: Sizzle: 4ms jQuery: 52ms
C1: Sizzle: 8ms, jQuery: 10ms (2ms “Overhead” yeah!!)
I don’t know what “base2” is in that slickspeed, I never heard of in ajaxian or so. But I found it very strange that all selector engines seem to fail on div ~p, div[class|=dialog], p:contains(selector) and p:only-child. The guy how wrote slickspeed maybe should check if truely every browser in combination with every selector engine can fail on these 4 tasks. I connot belive this.

Comment by Aimos — December 23, 2008

With fail I mean “different returned elements” according to the slickspeed legend at the bottom. I think thats wrong is’nt it?

Comment by Aimos — December 23, 2008

fun to see that peppy is still the fastest..

Comment by V1 — December 23, 2008

@Aimos: “base2” is

Comment by bcse — December 23, 2008

@Aimos: “different returned elements” means not all engine return the same result, not every engine are failed. One failed, then they’re different.

Comment by bcse — December 23, 2008

I checked my screenshots again, for some further conclusions:
Top 4, by browser:
IE7: Ext JS 2.2: 80ms, DOMA 2.7.4: 116ms, peppy 0.1.2b: 114ms, Sizzle: 172ms
FF3: peppy: 21ms, Sizzle: 23ms, base2: 70ms, Ext JS: 80ms
O9: peppy: 0ms!, Sizzle: 4ms, ExtJS and base2: 20ms, DOMA: 24ms
C1: peppy: 7ms, Sizzle: 8ms, jQuery 1.3b: 10ms, DOMA: 14ms
The difference between 80ms and 172ms or 21ms and 80ms is “huge” compared to 7ms and 14ms. I think there is still room for peeking here and there to optimize the own solution. I cannot belive, hence I did not checked the source, that every of these engines ignores the domhaschanged event, mentioned before by ejohn about the peppy engine.
@bsce: I though “different returned elements” means different from the expected. That kinda confuses me every time. I still don#t know which is right with the returned result. If selector engines live in democracy I’ll judge the majority as success and correct. :]

Comment by Aimos — December 23, 2008

I’m always suprised at how much faith is put in slickspeed. In an unaltered form, its results are wildly misleading due to the averaging of tests which, after the first run, are likely to be cached. Furthermore, the speed of some selectors will be based on which selectors have already been run; you can quite easily change the final score just by reordering the selector list.

I’m not saying its useless, just that its not that useful as an indication of how a certain library might actually perform in your web app.

Anyway, good to see jQuery coming on.

Comment by kissmyawesome — December 23, 2008

Wow. No more livequery plugin…

Comment by bunyan — December 23, 2008

I hate IE6, but I have to support it for enterprise web apps at work (testing with, cache is cleared from “Internet Options…”):

base2 1.0 620
dojo 1.2.2 1078
DOMAssistant 2.7.4 368
Ext JS 2.2 354
jQuery 1.2.6 602
jQuery 1.3b1 620
MooTools 1.2.1 924
peppy 0.1.2b 523
prototype 3631
Sizzle 0.9 601
YUI 2.6.0 2183
YUI 3.0.0pr2 2411

The most popular JS Library, prototype, is very disappointing and they been around a long time. I’m also disappointed with YUI coming from a big company.

It’s a good thing I am using jQuery.

Comment by diehardboss — December 23, 2008

“its not that useful as an indication of how a certain library might actually perform in your web app.”

On the contrary, I suspect it reflects real-world usage in that respect. It’s highly unlikely that most apps are going to be breaking both the browser and library caches so as to give “fresh” results at every point.

Comment by eyelidlessness — December 23, 2008

Peppy currently beats all other selector engines, including Sizzle.
Though looking through the code, Sizzle is currently best enginered and more failsafe. However, Peppy is a sure contender if James fixes a few issues.

With these benchmarks and the fact that browsers are implementing faster JS runtimes, speed becomes less and less of an issue. The next step is supporting missing selectors, creating a robuster pattern parser ( for example h1:contains( (((my pretty weird title))) ) breaks on most if not all selector engines.

All engines would also benefit immensly with memoizing instead of the caching they use now.

And for plugging in code into any js library, developers might consider the following pattern:

ns.query = SelectorEngine;

Supports X without sacrificing speed becomes the next holy grail ^^

Comment by BenGerrissen — December 24, 2008

John Resig is a false prophet and jQuery a superstition.

He’s been told repeatedly that his incessant browser sniffing was a sign of incompetence. So he finally figured it out.

Same for the sluggish queries.

None of this matters as the script is still hampered by design flaws that can’t be rectified without a total rewrite.

Comment by DavidMark — December 24, 2008

And nice commentator links on this page (http://null/). It seems the Ajaxians are not friendly.

Comment by DavidMark — December 24, 2008

Am I sad enough to sneak on here on Christmas day? Seems like it!
@ eyelidlessness – I suppose what I meant to say was that a looking at a single list of selectors might not tell the whole story. I’d like to see a version of SlickSpeed that allows me to create a custom list and see the results (without having to download from googlecode etc).
@ BenGerrissen – speed will become less of an issue, but only until IE6 is truly on its way out. Also, could you explain what you mean by memoizing instead of caching? I understand the technique, just not how it could relate to node lookups.
@ DavidMark – hate to say it, but it is you who seems rather unfriendly. Sure there are lots of things to improve about jQuery but the same could be said for any JS library. Nothing’s perfect, and the whole point of this post is about improvements…

Comment by kissmyawesome — December 25, 2008

My opinion towards IE6 is pretty pragmatic and I am very blunt towards clients about it. It’s silly to expect ferari performances from a lada, same goes for RIA in old and new browsers. ps. IE6 was the ferari of it’s time, never compare it with current browser, but compare it with contemporaries like NS4. Like the car industry, don’t dispair at progress because people still like to drive old timers.
As for memoizing, you can cache a lot more then just the end result. For queries there wont be much of a performance boost, you might even lose 1 or 2 ms of speed. But for event delegation, it becomes quite vital since it’s realistic to expect over 100 node-pattern comparison calls in 1-2 second(s), with complex patterns, this will bog down the computer. Not very web2.0.
For methods like :nth-child(2n+1) for example, some extra parsing is required to filter out the formula, you don’t want to do this every single time you try to match a node to a pattern. You can memoize the result easily and next time, it’s like calling cache[:nth-child(2n+1)] and you get the argument set you need right away.
None of the selector engines, are fit enough for web2.0 event delegation imo. until they start memoizing more.
I am working on another query/nodematching engine myself >.<, so I take great interest in the guts of these selector engines, though JR and JD are making me wanna quit my selector engine project =P

Comment by BenGerrissen — December 26, 2008

Leave a comment

You must be logged in to post a comment.