An Interview with Dojo Toolkit Creator Dylan Schiemann

One of the most prominent figures in the JavaScript and open-source world is Dylan Schiemann, and for good reason. Dylan appears at conferences all over the world, supports open source projects with the Dojo Foundation, and most importantly, leads the Dojo Toolkit project. I talked to Dylan about what he’s up to today, the release of Dojo 1.8, what we can see in Dojo 2.0, and what his plans are for the future.

Hello, Dylan. Over the past decade, you’ve had a variety of roles in the web development world: founder of the Dojo Toolkit and cometD, conference speaker, open source proponent, etc. What are you focusing on these days?

We’re ready to start working on 2.0, which will be a major effort.

Hi, David, my greatest passion is building things, whether it’s products, projects, teams, etc. I’m current the Dojo Toolkit project lead and president of the Dojo Foundation. In recent years, I wasn’t writing as much code, but this year I’ve become more active again in making contributions to and using Dojo. We’re very excited about the 1.8 release, with countless hours of effort into improving the code base and documentation. We’re ready to start working on 2.0, which will be a major effort.

I’m also the CEO at SitePen, a company that provides professional services (development, consulting, training, and support) to organizations building great JavaScript and HTML5-based web apps. SitePen has an incredibly strong team of Dojo and JavaScript experts, and I’m humbled every day by the work done by the SitePen and Dojo teams. We also recently announced dgrid, an incredible open-source lightweight, flexible grid component that’s built on Dojo and easy to use with other toolkits. SitePen is also working on its first industry-specific product that we’ll announce later this year.

Not many developers know this, but the Dojo Toolkit has featured many of the more advanced utilities that other frameworks have used today, including Deferreds. What other advanced functionality has Dojo boasted before other frameworks?

We’ve had Deferreds and promises for several years.

Dojo has a reputation for being ahead of the curve in trying new things. As you mentioned, we’ve had Deferreds and promises for several years. Our support for native vector graphics dates back to 2005. Aspect-oriented programming concepts, client-side pubsub, real-time, offline and local storage, browser history, data store bindings for widgets, and more all date back to versions of Dojo from 2005 or 2006. More recently, our mobile-specific efforts have emphasized really pushing richer capabilities to mobile devices, such as grids, real-time chat, charts, gauges, 3-D interfaces, and more.

The Dojo Toolkit seems to be the most powerful of the JavaScript libraries; why isn’t it more popular among the front-end development masses? Is Dojo’s “large” learning curve a myth?

Dojo has been focused since its inception on pushing the limits of the open web, by providing a complete, yet modular toolkit for being productive with JavaScript. We’ve had growing pains at times over the year. For example, there was a time when the default Dojo configuration was very slow to load, without clear steps to make it faster.

At this point in time, we’re in our best position ever with regards to performance, solid documentation, and ease of getting started.

It’s certainly easier to learn something that’s smaller than something that does more, but our avid users are quick to point out that a bit more learning up front saves them countless hours for things that Dojo makes easy. When we started Dojo, we imagined a JavaScript community where developers could work together and not constantly reinvent the wheel. It was never about a toolkit war, it was about creating the best toolkit possible, and working in a very open ecosystem that businesses could also trust.

Over the past few releases of the Dojo Toolkit, numerous features have been added or enhanced: the new AMD loader, dojo/aspect and dojo/on to separate function and native event listening, dojo/touch for mobile event listening, etc. What new features are available in Dojo 1.8?

1.8 has a new Ajax API, dojo/request, which simplifies and provides extensions for pretty much everything I can imagine doing with an HTTP request from a browser, or from within a Node.js application. We have also introduced dojo/Router, to simplifying routing between views. For 1.8, it works with changes in the browser hash for compatibility with currently supported browsers, and, for 2.0, it will work with the HTML5 history API.

dojox/mobile has received extensive API refinements and 26 new widgets. There’s an impressive new full Calendar widget, and of course there’s dgrid. Our parser and promises implementations have also received extensive improvements. This release has hundreds of refinements and bug fixes that make this a very solid and stable release, as well as support for non-browser platforms, like Node.js. And of course the documentation, in particular the API Viewer and Reference Guide, are impressive.

Performance is always an important factor when maintaining a JavaScript toolkit. What has the Dojo team done in the area of performance for the 1.8 release?

We’ve worked hard to refine modules that were not as fast as they should be, and wherever possible, we’ve reduced the dependencies of modules so they only require code they need. We’ve also worked to improve our build tools and documentation so it’s easy to create your own optimized applications.

With the creation of dojo/node, what role do you see Dojo having on the server side?

Having Dojo work on the server-side makes many things possible…

The Dojo Foundation already has a pretty impressive server-side JavaScript framework, called Persevere, that, to many, is like Dojo for the server-side, with support for object stores, RESTful services, real-time, and more. But having Dojo work on the server-side makes many things possible, such as testing, or pre-rendering widgets into an initialized state on the server-side before rendering to the client, which is a recent GitHub project.

Dojo has accumulated quite a bit of code over the 1.x lifetime. How does the Dojo team manage to maintain even legacy modules?

Thousands of hours of valued contributions from the community, and an open and inviting process for getting involved and contributing. Also, companies like SitePen and IBM will make fixes based on urgent requests from their customers. We’ve been better this release with setting goals, and getting more people involved, which has been really refreshing. We have many long-time contributors, but also a lot of new people that have made 1.8 amazing.

At this point, it’s safe to assume Dojo has started the transition toward 2.0. Modules have been written in AMD format, a new async loader has been built, and some of the legacy IO methods (io/iframe, xhr, etc.) have been consolidated. Can you hint at what we’ll see in Dojo 2.0?

We’ll start by cleaning up our APIs further, removing support for things that have been deprecated for several releases, and just get to a simplified starting point. We’ll also take a hard look at which browsers and platforms we should support… it’s much easier now with has.js feature detection built-in, and it’s really easy to exclude features from your optimized builds, but we still want to simplify the maintenance of the toolkit as well.

Basically, the great features of Dojo will still be there, but we expect many new advancements to support modern and mobile browsers, as well as a massive refactoring of old or stale APIs.

Dojo’s usually on the bleeding edge of client side advancements, Deferreds and Promises being examples. What do you see coming down the pipeline, and how does Dojo plan to work with those technologies?

Much of DojoX will be split into separate projects with their own release cycles.

I think much of what we’ve done recently has been around developer productivity and maintainability of your code base. For example, AMD solves many problems teams have with managing their code bases, or making disparate modules work together. I believe we’ll see a pretty massive transformation of the way widgets get created, to make things work more like dgrid works. Much of DojoX will be split into separate projects with their own release cycles. From there, it becomes easier to squeeze more into the browser, and get more from our apps. So we’ll start to see support for features like the HTML5 JavaScript File API, or better ways to manage local storage. I expect that working with object stores and requests will seamlessly handle local, offline, and remote capabilities, and yet provide hooks to customize as needed. Dojo has always been about providing great features, with as many extension points as possible to easily make it work the way you need it.

I also think we’re still running into many performance limitations of web browsers.

For example, native vector graphics or charts with very large data sets crawl in even the most modern browsers, so I expect we’ll see more fixes to work seamlessly with larger data sets.

Much like virtual paging has worked well with grid components, we need more solutions to other limitations on the platform.

Dojo’s official “plugin repository”, DojoX, hosts numerous enterprise-level subprojects, include dojox/mobile, dojox/gfx, and more. What is the long term plan for DojoX? Will it stay within the official Dojo repository, or will the Dojo team create its own plugin forge?

We currently have an early package management system, called cpm, with a listing of available packages at https://packages.dojofoundation.org/ . dgrid is the most popular Dojo package available today. DojoX will likely be split, with some features moving into Dojo or Dijit, and other features, like gfx and charting, becoming their own top level packages. They’ll still be available under the same licensing as Dojo, and major releases will have tools to easily combine popular packages into convenient builds, but they will have a much easier time releasing more frequently than Dojo.

SitePen has created an incredible grid widget for Dojo, called dgrid. What was the motivation for creating dgrid, and where is dgrid in its development lifcycle?

It’s really more stable than any of the Dojo grid widgets today

Several years ago, we brought the original DataGrid into Dojo by actually paying the developers of the most popular third-party widget to contribute it to the Dojo Foundation. SitePen, Mozilla, and a handful of others contributed cash to make this happen. After years of iterations, and the emergence of mobile browsers, it was time for a fresh, from the ground up rewrite that would work well on mobile and desktop, be incredibly modular, and work with all the latest APIs and features. This became dgrid. While we’re still calling it a beta, it’s really more stable than any of the Dojo grid widgets today, and we’re finding a wide variety of companies are already using it in production. We also support jQuery’s ThemeRoller styling conventions, so it’s pretty easy to use dgrid inside a jQuery app without any other Dojo, if that’s your preference.

Lastly, open source projects are always looking for good developers to help. How can Nettuts+ readers get started using Dojo, and how can they start contributing to the project?

Start with our excellent tutorial series https://dojotoolkit.org/documentation/ which is being updated for 1.8 now. Sign-up for our mailing list and ask questions https://mail.dojotoolkit.org/mailman/listinfo/dojo-interest. Try things out, give us feedback (on each documentation page, there’s a link to provide feedback on that page. We’ve fixed nearly 1000 documentation issues reported this way alone this year), file bugs or tickets, sign a contributor license agreement online ( https://staging.dojofoundation.org/about/claForm ), and start contributing in areas that interest you the most.

We have a weekly IRC meeting on irc.freenode.net #dojo-meeting at 2pm Pacific time on Wednesdays, or you can find us on #dojo at other times.

And of course the SitePen blog, or our workshops or support services if you need help right away.

The verdict? Dylan, SitePen, and most importantly, the Dojo Toolkit, are doing big things in the open source community. Dojo Toolkit’s feature set and momentum are impossible to ignore, and developers looking to create super-powered web apps should look no further than the Dojo Toolkit.