Together with the release of Dojo 1.3 information was disclosed about Taskspeed, a new JavaScript library benchmark test. Taskspeed is created and maintained by Dojo's project lead Peter Higgins and is based on the well-known Slickspeed benchmark for CSS selector engines. Taskspeed now compares DOM manipulation performance of various JavaScript frameworks. The first published results see Dojo as a clear winner, leaving MooTools, jQuery and Prototype behind. It's interesting to note that the respective framework developers/authors supplied the tests for their own library, so the code should reflect the best practice and coding style for each library.

Taskspeed Firefox 3 results

Taskspeed Firefox 3 results

Taskspeed IE7 results

Taskspeed IE7 results

Of course, we wanted to know how qooxdoo compares in this "framework-neutral" test suite. qooxdoo's own DOM layer is not too old, it was released in August 2008 with qooxdoo 0.8 by splitting out all cross-browser code from the widget system. The last missing pieces were a CSS selector engine and a nice way to work with collections of elements. Both features were added to the qooxdoo 0.8.2 release that shipped only four weeks ago. While we were quite confident, we did not really know what to expect. But after complementing Taskspeed with the qooxdoo tests and looking at the results we were stunned. The results indicate that qooxdoo is on par with the fastest framework (Dojo 1.3) on most browsers except IE. On IE qooxdoo is by far the fastest framework.

Across browsers and frameworks, qooxdoo gained the highest ranks on all versions of IE (i.e. 6, 7 and 8), and made its lowest mark coming out third on Firefox 3.0. This exceptional IE performance also leads to the best overall score. The IE results are a big surprise and we'll try to investigate, what we do different (better) than all the other JavaScript libraries.

As always performance tests should be taken with a grain of salt. It's hard to judge whether all implementations are really equivalent. For example in the jQuery tests John Resig implemented all tests in a pure jQuery way. There are obvious optimizations he consciously omited, but it apparently reflects the genuine jQuery coding style. There is no official qooxdoo way to work with the DOM yet, so we modeled our tests closely after the Dojo and jQuery tests. Please note that the current tests don't run on a vanilla qooxdoo 0.8.2, but on the latest trunk. That's because the tests exposed two bugs in the framework, which had to be fixed. Most importantly however, no code was changed in the qooxdoo repository to make it perform better in the Taskspeed test suite.

Analysis

So why does qooxdoo perform so well compared to other frameworks?

  1. We build a GUI-toolkit on top: Our requirements for a DOM layer are different than those of pure DOM toolkits like jQuery, Prototype or MooTools. We build a whole GUI toolkit on top of the DOM layer and DOM performance is the weakest link in the chain. If DOM operations are slow, the whole widget stack is slow. For this reason we try to keep our DOM layer as thin as fast as possible. We do just enough to cover all cross-browser issues, but not much more. In qooxdoo 0.8 we use it mostly as an internal API to build our widgets. We had no incentive to add any syntactic sugar or convenience API which could have slowed things down.
  2. Sizzle: For the GUI toolkit we have no use for a CSS selector engine. For this reason we were probably the last JavaScript framework to add this feature to its feature list. We always intended to adopt an existing engine and John Resig's excellent Sizzle engine was a perfect match. Since Taskspeed requires the use of CSS selectors in a couple of tests, our good performance is in part due to Sizzle's good performance. Since the latest jQuery 1.3.2 has an identical Sizzle implementation but is rather slow in Taskspeed, there's obviously much more than pure selector speed.
  3. Collection API: This is the final link, which connects Sizzle with qooxdoo's procedural DOM API. The idea behind the Collection API is to convert the result of a Sizzle query into a collection instance, which provides all the chaining goodness of jQuery. The methods offered by the collection API match most of the jQuery API and map directly to our existing DOM layer. One trick used there is to subclass the native JavaScript array. This way we can conveniently access the elements matched using array accessors, and we can leverage native Array methods like filter, indexOf or map if available.

We plan to position qooxdoo's DOM level API as a standalone part of the qooxdoo framework. These results show that we have a good base and encourage us to move forward in this direction.

Please help the Taskspeed team to collect more data by running the tests yourself and submitting the results when asked for in a confirmation box.