Monday, August 25th, 2008

Sizzle: John Resig has a new selector engine

Category: CSS, JavaScript

John Resig is working on a new selector engine called Sizzle:

This is a new selector engine that I’m working on.

It’s a work in progress! Not ready for use yet!

It’s definitely not ready yet (got some minor outlier bugs in the standards-compliant browsers – and a bunch of major bugs in IE still left to tackle) but the results are already promising.

4x faster in Firefox 3, 3x faster in Opera 9, 1.5x faster in Safari 3 than the other major JavaScript libraries. It’s completely standalone (no library dependencies) and clocks in at under 4kb.

I’m just committing my code before moving on to work on IE – so beware. And yes, I expect this engine to become the new default selector engine in jQuery.

Just 594 lines of code so far, check it out.

Posted by Dion Almaer at 12:48 am

4.3 rating from 37 votes


Comments feed TrackBack URI

Shameless plug :), GwtQuery, a selector engine written in GWT, is also ~2x=4x faster on most selectors than the old JQuery engine (see benchmark:, supports querySelectorAll, getElementsByClassName, document.evaluate, and raw DOM ops.

It can get impressive speedups and side reductions if you choose to use compile-time selectors. There are parsed and translated before your code is downloaded from the server, and only the code needed to evaluate them is shipped, or in the case of querySelectorAll supporting browsers, no evaluation code is needed.

Comment by cromwellian — August 25, 2008

Not that it’s that hard though..

Comment by Mikael Bergkvist — August 25, 2008

What’s not hard? Beating jQuery? The current selector libraries are fairly well tuned and hand optimized (e.g. DOMAssistant), so eeking out additional performance across very difference browser JS engines is not straightforward, but requires constantly profiling and tweaking. For example, many of the pseudo-element routines in various libraries appear to be nearly optimal, essentially DOM-call limited.

Speeding up the parser helps, but it produces somewhat misleading benchmarks, since by caching the parsed query, and tossing out the slowest result, you end up only benchmarking the evaluator, but most selector user code doesn’t run these queries dozens or hundreds of times.

Most the rest of the speedup in various libraries seems to come from aggressively caching snippets of queries to avoid expensive DOM calls.

Comment by cromwellian — August 25, 2008

It’s been known for some time that writing a loop like this:

for(i=0 ; i=0 ; i–)

I know that for small bounds it’s not going to make a noticeable difference, but still, I wonder why everyone isn’t writing their loops backwards like this as a matter of course?

Comment by user24 — August 25, 2008

ah, you’re stripping everything between chevrons, oops.

“for i = 1 to 10” is slower than “for i=10 to 1” is what I was saying ;)

Comment by user24 — August 25, 2008

I assume you mean something like this;
var i = someArray.length;
while(–i) {
/*…do stuff*/
…which is “proved” to be the faster solution, though none of those “extreme optimalizations” will matter very much when all browsers are running JS as JIT code. Just as most people stopped unrolling loops when moving from ASM to C since updated processors. But until then the above will perform better than most other loops (and in fact also be smaller ;)

Comment by ThomasHansen — August 25, 2008

I meant of course ;)

Comment by ThomasHansen — August 25, 2008

Hmm the “-” part is supposed to be TWO hyphens (-)
I don’t know why but keeps stripping my code ;)

Comment by ThomasHansen — August 25, 2008

double hyphen is a SQL comment..probably paranoid

Comment by TNO — August 25, 2008

Has anyone else been able to view the code from the given link ( It seems that there is some embedded link at the bottom, which causes a reset, and both FF and IE would rather display the error message than the 99% of the page that downloaded.

Comment by JamesCurran — August 25, 2008

@JamesCurran: Works fine for me, maybe your DNS cache is poisoned |o_0| .

Comment by tj111 — August 25, 2008

I hope the speed is still there after John addresses the IE challenges.

Comment by Nosredna — August 25, 2008

And I hope one day IE will just go away. :)

Comment by cromwellian — August 25, 2008

cromwellian: I recently saw your talk about GWT and GWTQuery. It sure look fast and all but server side UA sniffing screams 1997 to me. I’d rather serve John’s whooping 4kb library that gets the job done right and fast by doing proper client side feature detection than gamble and risk to serve a sub-optimal code path to cloaked user agents or UAs not listed correctly in GWTQuery’s sniffing mechanism.

Comment by p01 — August 25, 2008

@p01: I suggest you take a review at the Ray’s talk. GWT performs CLIENT SIDE user agent sniffing.

Comment by andytesti — August 25, 2008

mmh … I might have overlooked something then. I was fiddling with other things. I’ll try to watch the talk again as I don’t remember any mention about the sniffing being done on client side, nor of a feature detection mechanism.

Thanks for the heads up.

Comment by p01 — August 25, 2008


I haven’t looked at the latest jQuery, but as of 1.2.3, I think it checked jQuery.browser.msie over twenty times, and that flag is set based on what navigator.userAgent says. It’s possible 1.2.6 has changed that.

I’ve not looked at the sizzle source code yet to see what’s going on there, but then again, I don’t see the point of looking until it supports IE.

Comment by Nosredna — August 25, 2008

As mentioned, it’s client side sniffing. I personally think that the negativity surrounding browser sniffing has been taken too far, too religiously. There are cases where feature detection falls flat, and the “fix”, which is to run a battery of unit tests to prove a particular feature adheres to its specification I think is too wasteful of client and network resources. I don’t like getting too religious over design choices, I like what works, and what works efficiently, for my needs.

In any case, GWT can do either browser sniffing or feature detection, it’s up to you. For example, gwtquery contains some sample code which does “getElementsByClassName” feature detection, with the option of compiling different code paths that include it.

I think what might be confusing you is the notion of compile-time (happens not on client) vs client-side sniffing. GWT compiles multiple versions of your application up front, and the based on a small bootstrap script which performs the sniffing, it loads up the correctly compiled version.

Thus, I can create two implementions of a find() function. One that uses querySelectorAll, and one that used XPath. GWT will compile the application twice, once with the first function linked on, the second with the second function linked in. It then autogenerates a small selection script which gets document.querySelectorAll or document.evaluate and loads the appropriately compiled app. All of this is done on the client side. It produces very compact code with very fast startup time, and it doesn’t require futzing around with complex concat scripts, packers, and minifiers, to figure out what to include and what to leave out.

Comment by cromwellian — August 25, 2008

I’d love to see the Sizzle code updated with more comments. I know that for the people that are “up” on making these sort of things some of this might make perfect sense, but I’m getting lost trying to follow it. I do love getting to see code like this though!

Comment by Jon Hartmann — August 26, 2008

Sizzle – great name but lets see it……

Comment by Remedies — December 8, 2008

Leave a comment

You must be logged in to post a comment.