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.

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.

Thanks for the heads up.

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

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?

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.

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.