Apple's Webkit Open Source project (webkit.org) has reached another first by adding support for querySelector and querySelectorAll methods in their JavaScript engine. These are methods that allow you to find nodes using common CSS selectors defined in CSS 1-3. This means you can search for nodes with something like:
var oddRows = document.querySelectorAll("#dataGridTable:nth-child(odd)");
or:
var specificChildNodes = document.querySelectorAll(".content div:last-child:nth-child(3)");
From the above, it should be apparent that using advanced CSS selectors to access document nodes is very powerful. You can read about how these methods are supposed to work at: http://www.w3.org/TR/selectors-api/
At present, only the nightly builds of Webkit support this, but it is only a matter of time before this gets rolled into the shipping version of Apple's Safari browser. Webkit also supports a related method: getElementsByClassName. This is really just a subset of what querySelector and querySelectorAll do. Since this is a specification from the W3C, it is only a matter of time before Firefox and Opera also support these methods. You might be wondering if there is any reason to want them. To show the speed gains by using these native methods as compared to not having them, the Webkit team took a JavaScript selector test from the Mootools team and modified it to also run the same test against their methods. The result is a shootout between three JavaScript libraries that handle complex CSS selector queries elegantly and Webkit's native methods. The three JavaScript libraries used are Prototype, jQuery and ext. The test used is available at:
http://webkit.org/perf/slickspeed/
I ran the test on the nightly build from 02/11/08. Then I thought I'd try running the same test using IE7 and Firefox 2 to see if there was any difference in how the three libraries performed on those browsers. Of course the test for native support for querySelector and querySelectorAll would fail, but this was more about seeing how the browsers' underlying JavaScript engines impacted the performance of these JavaScript libraries when doing computationally intense CSS selector queries. The results were very shocking. I've included
Results of slickspeed test using Prototype, jQuery, ext and native browser support for the JavaScript method "querySelector" are show below as screenshots of the results. All tests were run in browsers on Vista Ultimate.
Internet Explorer 7
Despite being a relatively new version, IE7's JavaScript engine is excruciatingly slow, especially for Prototype:
Prototype: 268,932, jQuery: 119,116, ext: 42,664
Winner: ext
Firefox 2.0
In Firefox, Prototype fared better and jQuery lagged:
Prototype: 34,415, jQuery: 190,642 , ext: 55,826
Winner: Prototype
Safari 3.04
Prototype: 15,463, jQuery: 34,402, ext: 17,206
Winner: Prototype
Webkit-r30154
Prototype: 11,425, jQuery: 18,936, ext: 9,451, Webkit Native querySelectorAll: 500
Winner: Webkit querySelector
