What’s coming in Dojo 1.8

Hi everyone,

I’m Colin, one of the release managers for Dojo 1.8. Today I wanted to talk publicly about the planned roadmap and our focus for the next major release of Dojo.

Near the end of January, a group of team members held a meeting to discuss our direction for 1.8. The discussion was a little larger than simply the 1.8 release and cut across a few different areas, but we did establish a reasonable release roadmap full of new features and enhancements. For the most part, Dojo 1.8 will have a much more tightly controlled scope than 1.7, and we’ll be keeping release blocking issues reserved for Dojo and Dijit packages (instead of DojoX packages) in order to ensure a more reasonable/sprightly release cycle than the previous two.

Briefly, the list of planned improvements for 1.8 are:

  • New standalone Router component
  • New I/O component (to replace the existing XHR module)
  • New calendar UI component
  • New documentation parser
  • Touch & HTML5 support for Dojo DnD
  • Unified Touch API for Dijit, Dojo Mobile, and graphical modules
  • More mobile widgets and general mobile support improvements, including the start of convergence between Dojo Mobile and Wink Toolkit
  • Better SVG and Canvas support in dojox.gfx
  • Improvements to dojox.app lifecycle management
  • Improvements to data binding in dojox.mvc
  • More application demos
  • More has-bracketing for feature detection and smaller builds
  • Bug fixes for CLDR generation, AMD conversions, and more

In addition to code improvements, some very important additional changes are being made during the 1.8 release cycle:

1. Documentation

Everyone agrees: where to find correct and accurate documentation remains confusing to end-users and we need to work on improving this. From a tooling perspective, it was decided that the best route forward here is going to be to focus on getting a new JS-based documentation parser up and running as soon as possible, both so it can be used to generate the correct documentation for the API browser, and also so that it can be used to provide reports about what areas of code are missing documentation. Rawld Gill and Colin Snover will be the primary people working on this piece, but as they are both busy, anyone interested in the fun and exciting world of parsing should volunteer to help (even if it is simply running code against it until it breaks and lodging bug reports in the issue tracker on GitHub). Longer-term, the plan is to try to combine API & ref guide as much as possible to provide a *single* point of authoritative documentation for any given component.

In addition to tooling, we are working on improving user feedback during this cycle in order to try to learn where we need to focus our documentation improvements the most. Links have already been added to the bottoms of the API browser, tutorials, and reference guide pages so users can submit feedback about pages that are not giving them the information they need. We encourage everyone to use these links to provide documentation feedback.

Finally, Dylan Schiemann will be helping to set up some targeted documentation sprints to improve the quality and availability of documentation. More on this at a later date.

2. Browser compatibility

There are some new components slated for development during the 1.8 cycle that are dropping support for old browser versions (IE6 and Firefox 3.6). These components are likely to be the first to be referenced from external repositories as part of the move toward independent repositories for DojoX projects. Since we are still committed to continuing support for a wide range of browsers and browser versions within officially supported code, we will be implementing browser support grading in 1.8 (a la YUI and others) to make it clearer to end-users what kind of support they can expect for a given platform (and to enable us to more gradually phase out support for these legacy browsers).

We also understand that users don’t want to be stuck on a toolkit upgrade treadmill, but still need their products to be able to support new browsers as they are released. As such, we are currently evaluating a proposal to perform quarterly backports of browser support fixes from trunk to Dojo 1.5 and newer to assure end-users that their products will be able to support newer browser releases for a reasonable period of time. The release of Dojo 1.5.2 was a trial step in this direction.

3. Bug tracker

Our bug tracker has not been meeting our needs effectively when it comes to managing releases and issues. As such, new plugins have been introduced to improve this tool. We are also planning on going through and aggressively reducing the number of open tickets in order to provide a more realistic and manageable look at what work needs to be done for 1.8 and beyond.


As mentioned in the roadmap, our planned feature freeze date is April 16, with final release hopefully occurring sometime in early June. Keep your eyes here for updates and some sneak peeks at what’s coming up in the new release!

5 thoughts on “What’s coming in Dojo 1.8

  1. Sounds awesome! I’m especially a fan of dojo(x).gfx, which is why I started using Dojo in the first place. Portable vector graphics is, to me, the coolest thing about Dojo so it’ll be great for it to receive the love it deserves!

  2. Can’t wait! In your packaging for dojo 1.8; can you make sure to somehow package the current dojo mobile gallery into a usable package? I’m trying to pull that into a project myself from SVN and it’s like pulling teeth. There’re missing dependencies, etc.

  3. Can’t wait to see more mobile features in gesturing and widgets. Hope scrollableview will work better in 1.8 for both Droid & ios.

Leave a Reply to theone Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.