Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Dojo 1.3b3 Is Out

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?

by JP at

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.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.


by alex at

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



by alex at

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


by alex at
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.

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.
by ben hockey at
> the imminent release of Firefox 3.1,

Firefox 3.5 now.