Monday, February 5th, 2007

dojo.query: A CSS Query Engine

Category: CSS, JavaScript, Performance

Through the push of jQuery, MochiKit, Prototype, and behavior.js and most recently DomQuery, we are seeing boundaries tested and built upon.

Alex Russell (Dojo and SitePen) has written a fascinating piece on the performance of CSS query engines as he introduces us all to dojo.query the latest in the pack, and one that looks to start well out of the gate.

Alex goes into great detail on the reasoning behind dojo.query, shows performance comparisons between browsers and toolkits (well done Opera and WebKit nightly) and shows us the API (simple):


  1. // include the system
  2.   dojo.require('dojo.query');
  4.   // run some queries
  5.   dojo.query('#id');
  6.   dojo.query('div:first-child');
  7.   dojo.query('code.example');
  8.   dojo.query('.example');

I would recommend taking a peek at this great work.

Posted by Dion Almaer at 12:08 am

3.5 rating from 36 votes


Comments feed TrackBack URI

The work is great, but it seems that each developer can prove his results are the best. I’ve just compared the following sites: (comparing jQold and jQuery as delivered by JResig – obviously new jQuery won, second column) (comparing jQuery and DomQuery as delivered by JResig – obviously jQuery won, first column) (comparing jQuery, DomQuery and Dojo as delivered by JSlocum – obviously DomQuery won, second column) (comparing jQuery, DomQuery and Dojo as delivered by ARussel – obviously Dojo won, third column)

1. It seems that JSlocum and ARussel uses somehow outdated version of jQuery for comparison (is it unfair?)
2. It seems that JResig has improved his timings in the meantime (is it surprise?)
3. From unknown reasons, ARussel has redefined meaning and succession of some tests (is it intentional?)
4. It seems that actual JResig results are in most cases best of all.
5. I’ve performed all tests on Windows XP with IE6.

Comment by Krzysztof — February 5, 2007


As I responded over on the Dojo blog, there’s some serious test selection bias going on here. All of the test suites save the Dojo variant work on impossibly small DOM’s and all of them (Dojo’s inclusive) measure multiple-run performance of a query, potentially at the expense of first-run performance numbers which may, in fact, dominate real-world application performance.

I made a good faith effort to get the very latest versions of both DomQuery and jQuery. The assumption that any of the toolkit authors would be working to do anything but an honest evaluation of their system against the others is insulting to all of us and way off the mark.

As for the meaning of the tests, there are some cases in which some libraries are not correct vs. the CSS spec. Where that’s the case, I modified the test DOMs in order to ensure that Dojo’s was in fact correct. No malice was intended.


Comment by Alex Russell — February 5, 2007

Hi Alex. We’re sure that no malice was intended and I also replied to you on your blog posting. I’m glad you’re onboard with John Resig’s suggestion of standardizing the tests to run under specific rules and guidelines. I think that will go a long way to helping to get good results and improve performance for all of the projects. Andrew Dupont of the Prototype project has also accepted our invitation. Once Dean Edwards (cssQuery) & Jack Slocum (DomQuery) jump in, I think we’re going to have a great set of tests which will really improve all of the projects across the board.

We look forward to working with you and the other projects.

Rey Bango
jQuery Project Team

Comment by Rey Bango — February 5, 2007

Just to clarify the difference in results that you’re seeing in between and

This is because the code at john.jquery is pointing at the very bleeding-edge of jQuery code. Obviously, there’s been some massive speed improvements since 1.1.1 (enough so that we’re now the fastest library under IE 6 & 7, and a close second in Firefox). We should have some final results available for everyone within the next couple days.

Comment by John Resig — February 5, 2007

I didn’t mean to insult anybody; my comments have been done from somebody’s “outside” point of view. I understand that it has just occured so, but I wanted to agitate to take approach to stop spread confusion about “which library is the fastest”.

Comment by Krzysztof — February 5, 2007

@Krzysztof: Thanks for your support bud. We really appreciate it. Now that the Dojo & Prototype projects are onboard with building standardized tests, the results will definitely help in determining the performance of DOM requests and certainly help make jQuery a better framework overall.

Comment by Rey Bango — February 5, 2007

Related but not mentioned, the mozilla guys recently landed getElementsByClassName on the trunk.

Comment by Karl G — February 5, 2007

I have to admit, posts like this leave me with mixed feelings.

When DomQuery came out, there were several unique node processing ideas that gave it a big edge across the board. As other libs incorporate those ideas, the edge that DomQuery once had will be erased of course.

Alex has added his own unique logic to the equation – selective XPath when available. When other libs incorporate his idea, the edge he has with some queries in FF will disappear too.

In the end, with open source – the most important thing is what is best for the community. I think the current trend towards pushing the performance envelope is great for everyone. However, I think it’s important that the original author of the ideas continue to get credit in the source. Otherwise, IMO, sharing ideas collectively will just result in heated blog posts which benefit no one.

Comment by Jack Slocum — February 5, 2007

FWIW Jack, you have a legion of supporters that recognize your innovations :)

Comment by Ivan — February 5, 2007

Jack, I agree. With our collective use of very liberal, open source licenses, I personally try to abide by a “Don’t be greedy” philosophy. I know we’re more than happy to provide attribution to you in our comments/docs.

Comment by Dylan Schiemann — February 6, 2007

Leave a comment

You must be logged in to post a comment.