Infrequently Noted

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

Chrome 2.0 Beta

While you're waiting for the Dojo 1.3 release candidate to shake out the last few bugs, might I recommend some instant gratification by way of the new Chrome 2.0 Beta?.


So if you're using Windows and reading this blog, I can easily assume you're using (or at least have installed) a Chrome Dev Channel build. Drive that bad boy over here and behold the beauty of @font-face.

Awww yeah.

Thanks, as always, go to Chrome's good friends over at Apple and WebKit who are doing amazing work to help deliver a more beautiful web.

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! in SF, tomorrow!

As noted on the main project blog, there's a get-together tomorrow night (March 5th) at Le Trappe, one of the very best bars for beer in the bay area. We're expecting a great cross-section of the Dojo community, so if you like Dojo and you like beer, RSVP online so we can avoid totally overwhelming the bar staff.

Some OSCON Proposal Tips

For the last several years I've been lucky to serve on the OSCON program committee. What that means, basically, is that for a couple of weekends a year I sit down with all the talks that have come in through the "call for participation" process for my track (web stuff) and try to sort out good from bad. Once that's done, we try to identify any holes in the program and fill them to ensure that OSCON really does benefit attendees and that speakers and talks represent the diversity in views and interests of the Open Source world. My personal perspective is that it's the Program Committee's job to zealously guard the quality of the talks since the PC doesn't represent that business side of OSCON, but rather the attendees. I've always been impressed with how hands-off ORA is about this part of the process, ensuring that everyone gets a fair shake (as far as the PC is concerned). Part of that responsibility is to make sure that when you go you're not marketed to outside of the clearly labeled exhibitor booths. Content is content. Marketing is marketing. They both have a place, but that place is clearly marked and that's one of the ways that we try to keep OSCON good.

As it happens, this weekend is one of those sift-through-hundreds-of-talks weekends for me. The advice I'm about to give is therefore top of mind. Other PC members do things differently and have a different perspective, but generally the list of "do's" and "don'ts" that are listed on the talk submission page are a good guide. I do regret not having done this after last year's grading, but better late than never. I'll try to link back to this post next year (if I'm still lucky enough to serve on the PC) to give fair warning. Lastly, before I get into it, be assured that these guidelines don't talk about any single proposal. They're from persistent patterns I've seen over the years. Here goes:

In some sense, I hope that the truly bogus corporate-drone-submitted proposals don't get much better. They're easy to spot now, and their horrible quality makes them simple to filter out. Instead, I hope that folks who might otherwise be on the line find this list useful as a way to push them over the threshold.

My personal thanks go out to everyone who reads this blog and submitted talks this year. The quality in the web track is great, and many important topics are represented in the submissions that reflect how important the web is to Open Source (and vice versa).