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
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.
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:
- 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.
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.
- 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.
- 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!
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.
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:
- If you don't have - or aren't talking about - source code that I can download, please don't bother. There are obvious exceptions (talks about community practices, usability, etc.), but if you're trying to dress up a corporate agenda about "open standards" or are trying to market a closed system that just might happen to work with some bit of Open Source technology, you're likely to get dinged. There's no policy about this, of course, but the PC is comprised of people who actually do think that access to source code under good terms is important.
- Don't post the same talk to a zillion different tracks. Think hard about which track is best for your proposal, and mail someone on the PC if you're not sure. If you can't identify who on the Committee would be most likely to know, ask one of the Program Chairs.
- What you submit will get printed in the program bulletin if you're accepted. In years past there hasn't been much of a way to amend or change this, so be sure that when you submit, it's what you'll want people to see when they're stumbling out of one talk bleary-eyed and choosing between tens of other talks on the fly.
- Context is important. If your presentation is about something truly ground-breaking, earth-shattering, and new, it will be helpful to the reviewers if you describe it in terms of things that attendees might already know of.
- The longer the talk you're proposing, the more detail you should provide.
- Warmed-over talks from some conference circuit are less likely to be appealing. OSCON has a limited number of slots (believe it or not), and if attendees can see the same talk somewhere else, why should they come see you at OSCON? If you give a lot of talks, be sure to note why this talk is different.
- Don't assume that your company's name buys you cred. If you're talking about something important that you have specific knowledge of because of what your company does, that tends to show up in the thoughtfulness of the talk description (or at least I tend to hope it will). It's really embarassing when good people from respected firms don't make the effort they should because they think that somehow we'll assume that what they have to say is by-default important. OSCON, like OSS, is very much a personal meritocracy.
- Present something relevant. If you're presenting a new way to do something that others have been doing for a decade or more, you need an angle on it that's fresh or an explanation for why it's important now. The hot things are hot, the cold things are cold, but there are interesting problems in most bits of OSS. Your challenge as a presenter is to help us understand that you think they're interesting and that you understand that attendees might need an extra reason to pay attention to something that they might otherwise think of as "settled".
- If you take a scatter-shot approach to proposals, it's going to show. Folks who submit for one or two related topics generally tend to be talking about things they're clearly experts in, and it shows in the proposals. There's nothing more frustrating than seeing a half-dozen proposals from someone on a wide range of topics, none of which their proposals would lead you to believe they have specific or unique knowledge of. It's painful because the proposals themselves are often of low quality, and frustrating because the topics tend to be important. Be focused, have something important to say on a worthwhile topic, and sell the topic (not just yourself). If you can do all of those things well for 6 or 7 proposals....well, you're a better person than I.
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).
You might want to watch this Frontline episode for background.