As Chief R&D Monkey here at SitePen, my work primarily revolves around ensuring that Dojo rocks for our customers and that we take what we learn from building apps and ensure that the toolkit evolves to encompass those lessons. Early this year it became clear that for folks building Dojo apps, the question of “what is Dojo?” was becoming increasingly hard to answer. Each individual user might be working with a different subset and therefore they don’t share a common definition, which makes sharing what you know about the system harder than it needs to be.
In response, we’re in the middle of a huge undertaking: rethink the entire API surface area of Dojo from the ground up and split it up into 3 different top-level projects. With R&D dollars and time coming from all corners of the Dojo universe, 0.9 is shaping up to be smaller, faster, more coherent, and easier to understand. I’ll be doing a regular “where are we now?” set of posts here on the SitePen blog for folks who don’t have time to follow all our mailing lists and forums or watch the commit flow.
So, where are we now?
Core
The Dojo Core project is providing a new “dojo.js” for everyone else to build on and some modules to extend that tightly focused set of APIs for very common cases. This new “dojo.js” is referred to inside the project as “Base” and it includes things like dojo.query(), dojo.connect(), the package system, style and DOM manipulation functions, ajax, and a small-but-flexible animation system. This work is mostly stable now, and thanks to Owen Williams, Scott and Steve of TurobAjax, James Burke (AOL), Eugene Lazutkin (Sun), Adam Peller (IBM), Bryan Forbes (SitePen), Jared Jurkiewicz (IBM) and a slew of others the new system is small, lean, and very very fast. Our goal for dojo.js (aka, “Dojo Base”) is to have all of the above come un at under 50K after ShrinkSafe processing and today we’re somewhere closer to 60. As we get closer to 0.9 release, we’ll start to really crank on the size. Something about Dojo Base confuses Dean’s excellent Packer so there’s hope that once we resolve that, we might squeak in under 50 even before we start to really turn the screws. Regardless, we’re still under 20K gzipped and it’s likely that Packer won’t actually improve that number much.
A big change for experienced Dojo devs is going to be that unlike in previous incarnations, “dojo.js” will always mean the same thing. Whenever you pull in dojo.js to your apps, either from source or from a build, it’ll always include all of the Base APIs. You don’t have to dojo.require() them. You get an amazing amount of functionality for that 20K and builds will now ensure that you don’t have to “cache churn” those fundamental APIs every time something in your build changes. This is being made possible by James Burke’s excellent new work on “layered builds”. These builds (also working on 0.4.x!) let you declare a set of dependencies that need to be filled for each “layer”
One of the really great things about the Core effort has been the research that folks are putting into the modules. Dojo is a community that has never been afraid to question its own assumptions and admit when we haven’t been right, and that’s shining through very brightly in the new Core. It’s small, focused, challenges many of the assumptions about what we “need” to provide, and is backed by exhaustive testing. For instance, Scott Miles has does a tremendous amount of research into keystroke handling to ensure that the new dojo.connect() method and provide accurate cross-browser events. In 0.4.x, the keystroke handling code normalized some of the event names, but despite using much less code to do it, Scott’s new keystroke code not only normalizes the originating key name, it also ensures that things get fired in the right order and that virtual keyboards and modifier keys are correctly disambiguated.
Dijit
As I’ve mentioned in other places, we’re breaking out the widget system from Core into its own namespace under the able direction of Bill Keese. The Dijit team is working on a set of consistent, themed, localized, and accessible widgets that not only improve on the usability of the existing widget set, but will also provide huge performance improvements in declaring and constructing widgets in a page. A lot of that speed improvement hinges on the newly slimmed and trimmed APIs in Core, and so it was huge news this week when development on Dijit moved from using the 0.4.x versions of those lower-level APIs to running on Core. In some off-the-cuff comparisons during our project-wide IRC meeting this week, we noted that Dijit on Core can in some cases be 50% smaller than the same functionality on 0.4, and widget instantiation is significantly faster due to a new parser infrastructure that leverages dojo.query() instead of the old (needlessly flexible) 2-pass parser.
In the next couple of weeks, I’ll follow up and talk about how things are progressing as we near Milestone 2 release, do project-level gut checks at the upcoming DDD in NYC, and talk about some of the excellent work happening in testing tools, build system changes, and the exciting DojoX namespace.