Tuesday, July 3rd, 2007

Dojo 0.9: The next generation is here

Category: Announcements, Dojo

Dojo 0.9 has been released in beta. This is a brand new Dojo, and a very exciting time for the project:

SPEED: Stripped of all ‘excessive’, redundant, and backwards-compatible code, the new Dojo core is a speed-demon. It consists of a streamlined, compact Base (aka: dojo.js) which provides a plethora of reliable features for you and your application to expand upon. Our goal was to keep the new Base under 50K on disk and we’re happy to say that even with the many improvements to it since M2, Dojo Base still clocks in under the wire and gzipped it’s even smaller: 24K. The base of the new widget system (dijit.js) is even lighter, weighing in at 21K on disk and 11K on the wire.

Accessibility: one of the main goals of Dojo’s 1.0 release is accessibility. We want to put the power to build great web applications in everyone’s hands, and that means applications that are also great for everyone. Dijit (the dojo widget system) is striving to make all aspects of the Dojo Toolkit accessible via keyboard navigation, accommodate screen readers, and work in high-contrast mode for visually impared users, while still maintaining its elegant and customizable structure. Much of that work is already done as of Beta and it shows. Try tabbing around the examples on IE or FF and you’ll see how a focus on a11y makes the components we provide better. Again, our heartfelt thanks to Mozilla and IBM as well as David, Simon and Becka11y (the a11y team) for their continued efforts on everyone’s behalf.

Theming: Dijit is entirely customizable. Shipping with a default theme named ‘Tundra’, a structure has been established with which to create your own personalized sytle of Dojo, on a per-page or per-node or per-widget basis. All dijit look and feel is CSS-based, and easily extendable. Look at any of the Dijit examples and you’ll see that there’s no magic about how the CSS gets loaded or applied. Want to provide your own theme? Just create an allegory to tundra.css and you’re off to the races!

Documentation: a new version of our venerable web-based/html API tool is is in the works. Following a strict style guide, and documentation standards, we’re working hard to make Toolkit code nearly self-explanitory. Where it’s not, the new API system supports in-place updates of the documentation via the web interface and comments on any node so that you can share your experiences, common usage patterns, and frustrations about any API with yourself and your fellow Dojo developers. We expect this new tool to be integrated with the main Dojotoolkit.org

I am excited to see what comes out of this. Great jobs guys, and kudos for being ballsy enough to make this change.

Posted by Dion Almaer at 1:47 pm

3.9 rating from 63 votes


Comments feed TrackBack URI

A lot of new releases this week :)

Comment by Калоян К. Цветков — July 3, 2007

Nice to see that the focus in the dialogs actually loops! Not many toolkits take this into account for their ‘modals’.

Comment by Michael van Ouwerkerk — July 3, 2007

Just a quick flashback. 24K gzipped ? Remember the old times when ZX Spectrum had 48K to run Fairlight or Batman ? Keep pushing JS people! Ok, I know, i know that was assembly..
Size matters only on high load sites. Personnaly I don’t care about it, the best would be a local cache for helper libraries.. like, – forgive me Lord – install/uninstall ActiveX controls… things are heading that way.

Comment by mogyiman — July 3, 2007

Very good. Small file sizes like this will be important when our internet is tiered. -_-‘

Comment by mdm-adph — July 3, 2007

Woo Hoo. Just in time for July 4th. I get to spend all day tomorrow playing with this. Am so looking forward to widgets that don’t suck.

Comment by Vance Dubberly — July 3, 2007

If speed really is a goal, some numbers of response time and such would be more relevant instead of just saying the new size.
Also, is all the code in the Dojo base really so tightly integrated that everything relies on something else? Otherwise they could just trim it down to the skeleton and package other features into self-contained maybe optional add-ons.

Comment by Scriptor — July 3, 2007

mogyiman – Size matters only on high load sites. I curse you from the iPhone on which I write this :) Local cache is great, but it’s always nice to provide a solid experience for first time users.

scriptor – Load time numbers are nice, but there a lot of variables (location, connection speed, etc). Size, esp within the context of previous version weight, is a nice consistent metric that doesnt require much explanation.

As for the question about splitting up the base, you need to find a balance between throughput and latency, and Dojo does a very nice job of that. If you trim down base too much, you are making a number of round trips to the server to pull in subsequent libraries. Even with all the nice XHR work to make those fetches non-blocking, the latency of waiting for those libraries to load can kill your user experience.

Comment by Ryan Breen — July 3, 2007


We tried the losely-bound method before, but what happens is that instead of everything relying on just one thing, everything winds up relying on *everything else*. The resulting packages and builds are rambling and from a process perspective, no one feels responsibility for the size of the system as a whole. We’ve solved the social and technical issues at once by setting a hard size limit for Base and fitting as much functionality as we possibly can in that budget. The rest of Dojo code no longer has to feel slightly guilty for requiring other modules…almost everything other systems need is in Base. From JSON to Deferreds to Ajax to the parser to the event system to HTML and style utilities to pub/sub notification to the package system, nearly everything many of those modules were previously including manually is under one (highly curated) roof. If it’s not there, there’s a reason, and if it’s there, you probably need it in a non-trivial app.


Comment by Alex Russell — July 3, 2007

@Michael: There are those who really care about that (as do i). jQuery also got some updates for this:

Comment by Gilles — July 4, 2007

that’s good news. it’s nice to have options. the guys at mootools are total @#$holes. i’ll be looking at jquery and dojo

Comment by matthew — July 4, 2007

I think this is a great step forward for Dojo.

For performance it’s not just file size that counts but number of objects. Given that you can only open 2 sockets to any server at a time in a Browser, downloading 25 or 50 js files onLoad makes latency a real issue. I understand that .9 will fix some of this.

While screenreaders and other assistive technology may now be able to read widgets, they still won’t know when you’ve updated one of those widgets with a fancy DHTML effect. That technology is a couple years away and doesn’t have full support by Microsoft yet. This is a problem with DHTML, which everyone calls Ajax, and not just Dojo.

The api docs and manual for Dojo are unusable as is – any improvements here are welcome. Despite dojo being open source and written in javascript – using it is still a little like black-box programming. Who the heck knows what dojo is doing to your DOM – good luck debugging! Improvements in documentation would be very nice.

Comment by John Moore — July 5, 2007


As with 0.4.x, your build determines the number of files fetched. We provide the tools you need to tune your site however you wish.

As for a11y, we’re working with folks who are in nearly constant communication w/ the a11y tech vendors. We can indeed inform the browser when things update (see http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions), and our components are being actively hinted with not only keyboard and high-contrast mode defaults, but also WAI ARIA roles and states. Using a Dojo ContentPane to pull in content from a URL will flag to a reader that the contents have changed and when you tab to focus on it, you’ll know what you’re looking at.

As with everything else web-related these days, we’re done waiting for Microsoft to take a leadership position on these issues. Give the ARIA stuff a look, I think you’ll be pleasantly surprised at how far the Open Web can go in making accessible interfaces today.


Comment by Alex Russell — July 5, 2007

Can somebody point to a good article about main advantages of dojo as a development platform over popular competitors?

Comment by kangax — July 5, 2007

Alex some bug i submitted to the tracker are not fixed and more than half year passed, animatin still gets broken very easly , so things that depend on it are automaticly broken.


now doubleclick fast on the pane , it will get broken and not wipe out and in correctly then.

Guys i have spend over 3 months developing on dojo, and i think its a great promising platform , but please focus on fundamental things like animation package, what good is it when it gets easly broken, and all the plugins that depend on those function too.

How can i rely on a framework library that does not fix bugs like that in half a year ? I wish i could use it and depend on it in my work. But this simply is not possible right now, ive tried YUI later and never ever had a problem with it, im pretty confident you can do the same ;-) just do it :]

Good Luck


Comment by Ergo — July 6, 2007

kangax: Your comment spurred me to put something together in the Dojo Book: http://dojotoolkit.org/book/dojo-book-0-9/introduction/why-dojo

It’s by no means complete, and feedback is most welcome, but it should outline some of the major selling points of Dojo and where our focus differs from that of other libraries.

Comment by Alex Russell — July 6, 2007

Hello.. I was evaluating Dojo0.4 and tried some widgets, that worked fine for me. Dojo 0.4 version stated Dojo with Ajax…However Dojo 0.9 does not mentions Ajax.. i am going thru the samples. But before proceeding can some one just confirm if Dojo 0.9 supports AJAX? – Awaiting response… thanks…! Mann

Comment by Mann — July 6, 2007

@Mann: Dojo is one of premier Ajax toolkits out there; I suppose it depends on what you mean by “Ajax” but all of the original functionality is there:


It looks like the sections in the Dojo Book are not there yet for this, but also the book is focusing more on use case approaches than simply listing out the features Dojo provides. Note also that xhrGet and xhrPost are a part of the Dojo Base, while other transports are part of the Dojo Core (this means that when you use the built version of Dojo, you don’t need to do anything to use xhrGet/xhrPost, but you do need to dojo.require other transports).

Comment by Tom Trenka — July 6, 2007

Hey Ergo,

Getting animation toggles working correctly is one of the last things that slipped into 0.9 final from beta. It’ll be there. You can track the progress here: http://trac.dojotoolkit.org/ticket/3641


Comment by Alex Russell — July 6, 2007

Great Alex,

maybe ill take a look at dojo in future :]

Comment by Ergo — July 9, 2007

Leave a comment

You must be logged in to post a comment.