Dojo 1.3b3 Is Out

New Dojo hotness is about to land, and you can get your very own sneak-peek by grabbing one of the beta builds, or if you’re a DOM-and-progressive-enhancement-only kinda person, you can grab only dojo.js.

So why should you be switching to Dojo or upgrading to 1.3? You can dig through the nearly 500 fixed bugs or the tentative release notes yourself, but broadly speaking, we’ve hit all of our major stated targets for 1.3: IE 8 compatibility, major performance improvements throughout the whole system, and enhancements that make the APIs you already know that much more powerful and useful. I don’t want to get into specifics since Pete’s release announcement will include much more detail, but I’ll outline some of the changes to just the CSS query engine since that’s the system I worked on most for this release (continued after the jump).

As you may know, Dojo’s CSS query engine has always been wicked fast. Indeed, our original design target for doing CSS queries was that we wouldn’t do an engine until we could be sure that it would be so fast that using it wouldn’t slow down applications. Release after release, the query engine in Dojo has continued to improve, consistently beating all the other major toolkits, particularly on queries that get a lot of heavy use by Dojo developers. The world is changing, though, and over the Christmas break, I spent some time upgrading dojo.query to take advantage of the changes in browser landscape. For 1.3, my goal was to remove the XPath branch from the system and re-enable QSA in a robust way. The motivators were:

  1. Firefox 3.0’s days are numbered. Since the DOM branch has been used on WebKit-based browsers for some time (it has been shown to be faster than XPath over the HTML DOM in tests), and since querySelectorAll is becoming available on IE 8, FF 3.1 3.5, and is now usable on WebKit browsers, the only customer for the XPath branch was FIrefox 3.0. With the imminent release of Firefox 3.1 3.5, it stops making sense to cart around a second selector engine target for the query compiler. The win is that we get to keep the speed for selectors that can be run through QSA, and since we drop the XPath branch, the core is both smaller and we have more room in our “byte budget” to optimize the DOM branch further.
  2. querySelectorAll is nearly usable. As has been noted elsewhere, querySelectorAll is good but fatally mis-designed for the rooted-query case. As a result of this and many, many, many QSA bugs on various browsers (yes you, IE 8) and gaps in CSS3 selector support, determining when to run a query via QSA and when to defer to the DOM branch isn’t actually straightforward. Engines like Sizzle try to detect query failure and re-run on DOM, but that leads to serious performance deficiencies on browsers with half-hearted QSA implementations. It’s also not accurate since silent errors are, well, silent. Enabling QSA, then, requires both a lot of work to handle rooted queries as well as feature and bug detection code to work around query engine differences.
  3. Portability. The new selector engine is affectionately named “Acme” (aka, “query.js”) to indicate how generic it is. The engine is 100% stand-alone and can be integrated into other toolkits without much work at all. This is made possible thanks to some build-system magic in Dojo which keeps us from duplicating any functionality and by careful and judicious use of Dojo Core features. query.js can be used stand-alone without any extra work.
  4. Better infix operator handling could make things faster. Instead of using regular expressions to parse CSS selectors, Dojo’s query engine generates an AST-like structure that represents a query. This system has always allowed us to have great visibility into what parts to optimize and how, but with 1.3 the AST generator now changes the way that infix operators (“>”, “~”, and “+”) are tokenized, making it possible to avoid inefficient queries which are then mostly thrown away and to skip error prone look-ahead code. This class of changes lead to huge speed wins.

I won’t cite specific performance numbers here since, as I’ve noted in the past, query engines are a commodity. That’s part of the reason we called the new engine “Acme”. Fast enough is fast enough, and the bottlenecks are elsewhere in toolkits today. I’m proud that the new engine sets a high water mark for performance, and I encourage other query engine maintainers to look through query.js and adopt the approaches we’ve taken to achieve eye-popping aggregate performance across different browsers and types of queries. The code is clean and commented to the hilt with notes about overall design and specific implementation decisions. I’m also happy to answer questions that other engine authors have.

Acme is just one – and not nearly the biggest – reason that Dojo 1.3 is an outstanding release. I’ll post more about some of the things I’m most excited about when 1.3 final is announced, but until then, I again encourage you to start working with the beta. While you’re at it, you might also want to check out plugd, drails, Dojango, and Persevere. They’re making it easier and faster to build great apps with Dojo and might save you tons of time.

Pete, Bill, Dustin, Becky, Adam, Kris, James, Bryan, Sam, Nikolai, Wolfram, Neil, Dylan, Tom, Chris (and you too, Chris), Tobias, Shane, Cougar, Jared, Doug, Josh, Bob, Roberto, and the rest of the Dojo community have a lot to be proud of with 1.3. Nice work, everyone!


  1. ben hockey
    Posted March 7, 2009 at 10:33 pm | Permalink

    alex, the 1.3 (draft) release notes have a section about dijit.layout.ContentPane extending _Container. That should probably be removed since it didn’t happen that way… even though i wish it would have. widget.placeAt(contentPane) would have been (was) really convenient – had to go back and change some code that was anticipating it going that way :( maybe ContentPane could get an addChild and then placeAt could work.

  2. RichB
    Posted March 8, 2009 at 12:58 am | Permalink

    > the imminent release of Firefox 3.1,

    Firefox 3.5 now.

  3. Posted March 8, 2009 at 1:27 am | Permalink


    If it slips further, should we just start increasing it by a 0.1 for every month?



  4. Posted March 8, 2009 at 1:29 am | Permalink


    Wait…ContentPane doesn’t have an addChild? That’s totally whack. I’ll ping Bill about it.


  5. Posted March 8, 2009 at 12:03 pm | Permalink

    I included Dojo 1.3b3 into my CSS Selector Benchmark, and have so far turned up interesting results. This benchmark compares it to many other frameworks (including Dojo 1.2.3) on many different browsers.

    There are significant speed improvements from 1.2.3 on most browsers, with the exception of Firefox 3 (not 3.1) and Opera 9.

    Also it seems the “p:only-child” bug was fixed in 1.3; though there are still issues with the :contians() selector (See “Known Issues”)

    Currently 1.3b3 does hold the top spot on my “Top Frameworks” graph, but that’s because I haven’t included a large enough browser sample with the new framework. Though it should give jQuery a run for it’s money in speed.

  6. Posted March 8, 2009 at 2:18 pm | Permalink


    The FF3.0 performance backslide is the result of not having a faster-than-DOM branch on FF 3.0 any more. This was a tough call, since the XPath engine was pretty clean and easy to maintain, but we just couldn’t afford to include it given the byte budget constratins. Our calculation here is that w/ the imminent release of 3.1…er, 3.5, FF will (on average) be running on the QSA branch more of the time than on the DOM branch. While it does regress compared to 1.2.3, I suspect that 1.3b3 is probably still faster than most other engines on FF 3.0.


  7. Posted March 9, 2009 at 11:10 am | Permalink

    Another great release, we’re having a hard time keeping up with Dojo with traditional product release schedules, you guys are moving so fast. :-)

    One question, you link to this page…

    As a demo of “stand alone” query.js, but that page errors out in FF3 and Safari. Is there something else in that page that I’m missing?

5 Trackbacks

  1. By Ajaxian » Dojo 1.3 is coming on March 9, 2009 at 4:40 am

    […] Russell has posted on Dojo 1.3b3 which we have actually been using on Bespin. So why should you be switching to Dojo or upgrading […]

  2. By Dojo Toolkit 1.3 Beta is Out | on March 9, 2009 at 7:31 am

    […] Russel just (well a couple of days ago) anounced that the beta of the newest version of Dojo Toolkit is available. I’m looking forward to the […]

  3. […] CSS selector engine which provides a big boost in speed for many operations in the fast-path. I blogged before about the work we did to make Acme fast, and rest assured it is (in aggregate, across all use […]

  4. […] engine performance really matters. Dojo continues to do very well in TaskSpeed in part because the Acme selector engine is so darned […]

  5. […] version of Dojo. The APIs feel familiar, the class hierarchies seem natural, and Closure even uses Acme, the Dojo CSS selector engine. It’s impressive work and congrats are in order for Arv, Dan, […]