Debunking Dojo Toolkit Myths

The Dojo Toolkit has been around for over four years, and has undergone significant changes, both big and small, in becoming a great JavaScript toolkit. This article debunks myth and outdated assumptions (both fair and false) applied to Dojo over its four plus years of development.

Dojo is Undocumented

Far from it! Early on, Dojo’s only documentation was the source code. Today, we have a tremendous amount of information available, and we’re working to better organize and refine it.

To start, take a look at the Dojo QuickStart Guide, Dojo API Viewer, and Dojo Campus Documentation Project (the forthcoming replacement for the venerable Dojo Book).

Want offline docs? Check out the Dojo Toolbox for now, and soon the Dojo Campus Documentation Project.

Need a book? There are now four great dead tree Dojo books to choose from.

Need a great how-to or walthrough? Try one of these in depth Dojo tutorials.

Want to see demos? Look at the Dojo Campus Feature Explorer or the Dojo Spotlight.

Need hands-on Training? Contact SitePen for assistance.

Will Dojo continue to simplify and improve its documentation? Absolutely, and we welcome your help and feedback.

Dojo is Slow

Any JavaScript library can be slow if used incorrectly. In the days of Dojo 0.4, it was too easy to create apps that were slow by having the parser on by default, and include extraneous files and source code.

Today, the parser is a problem unique to Dijit. Dojo != Dijit, and today you only accept the performance hit of a parser (one that is much less than the days of 0.4) when you need a full-featured widget system.

For the past 18 months, Dojo has made it easy to create things with Dojo that are lean and fast, and any functionality that was in Dojo 0.4 is at least 100% faster in Dojo today, and some things are 1000% faster or more. In measuring performance with querying, dojo.query is as fast if not faster than other major leading toolkits with the SlickSpeed test suite.

And Dojo offers a plethora of performance optimization techniques and suggestions to squeeze every last KB and millisecond out of your source code. Reliable, cross-browser performance is a data-driven art that requires leaving many assumptions at the door, listening to data, and making compromises as necessary.

Dojo is Bloated, Larger and More Complex than Prototype, jQuery, MooTools, YUI, etc.

Dojo is designed to give you the necessary tools to solve complex engineering problems, while keeping the simple things simple. This myth exists simply because we use a package system, and we expect developers to leverage a build tool in production code to optimize performance. If you download the full Dojo source, you will see many files. Out of all of those files, you only need to include a single one with a script tag in your markup.

We make it easy to get started by just including dojo.js from AOL or Google’s CDN services. We call dojo.js “Dojo Base”. It is 26KB (gzipped) in size, and comparable in size, features, performance, and functionality to other major toolkits.

Dojo Base provides an extremely rich and lean set of functionality useful to any web developer. I think you’ll be hard-pressed to find more functionality and performance in less KB.

If 26KB is too much, you can even get a stripped down version of Dojo in just 5.5KB, which represents the module loading framework for Dojo, and then add back just the exact features you need. You can also take the entire source Dojo SDK and reduce it down to what you need.

In the browser, every feature adds a slight performance hit, so Dojo values the flexibility necessary to include just what you need, and no more, while offering a wide amount of features in a coherent, organized manner. If you want to use more of Dojo’s functionality, it’s completely optional, and you just dojo.require the extra features you need. The class structure in most cases just follows the logical path structure of your project. For example, would be expected in /dijit/foo/Bar.js.

The simple provide and require namespace system system makes it easy to use Dojo code and your code alike. This makes it possible to easily create advanced, powerful applications as well as simple features such as the Dojo Flickr Badge.

The Dojo Package system, while adding a bit of complexity that takes two minutes for new developers to learn, makes it much more readable and organized, and provides you with the ability manage your code when script includes and dependencies otherwise become unwieldy. Dojo is a library, and behaves as such. Like Java and many other languages, we automatically include only the bare minimum amount of code, with plenty of other packages that you have to include manually.

There are frameworks within the various libraries inside Dojo, the most widely-known one being Dijit. The Dijit widgets have dependencies on the framework code. These sort of long dependency chains are rare within Dojo, but exist when needed to provide more involved functionality.

Dojo Requires Java

No, not at all—even though the full Dojo SDK does include a few jar files.

In addition to browser-based capabilities, Dojo provides completely optional Rhino-based tools to optimize your code in a build step to improve performance. Rhino is the Mozilla Foundation’s JavaScript engine implemented in the Java programming language.

Why would you ever want to “build” JavaScript? To reduce the size of your source code, to optimize caching, and reduce the calls to the server. For example, you can merge CSS rules together, and take HTML resources used by widgets and turn them into JavaScript strings to reduce the number of HTTP requests, overall file size, and more.

Dojo is Verbose and is “Java for JavaScript”

The only thing in Dojo that resembles Java is our desire to include things in namespaces. Our library structure still encourages brevity, with Dojo Base features living in the dojo.* namespace. Dojo prefers dojo.byId and dojo.query over $, though it is easy to roll your own Dojo bling function if you prefer!

Dojo prefers putting everything in namespaces to reduce our footprint in the global namespace, to allow Dojo code to coexist with other libraries and user code without naming conflicts. Also, Dojo minimizes function overloading, so using full APIs helps with code maintenance.

For brevity, anything that is widely used typically makes its way into the top level namespace in a short and easy to remember manner, e.g. dojo.connect and dojo.attr. The terseness of our API and namespace structure tends to surprise people who haven’t used Dojo since 0.4 or earlier.

Each component is a distinct “thing” and our only options are to address this in the global namespace which would create conflicts, or to hang it off of Dojo. Admittedly, some projects and toolkits don’t have namespaces simply because they don’t provide enough code to need namespaces.

Java developers do like Dojo (or DWR or even GWT or Ext), most likely because of the breadth, depth, and organization of the Dojo Toolkit APIs.

Much of the inspiration for Dojo is derived from Python, AOP, PHP, Java, and a variety of functional programming language constructs like hitch, mixins, delegation, and more. However, we explicitly avoid using any patterns from other languages, and we make great efforts to make our JavaScript leverage the patterns unique to JavaScript.

Toolkit constructs such as dojo.declare() may be considered Java-like, though most libraries have some sort of constructor and inheritance model. Dojo takes advantage of the flexibility of JavaScript rather than trying to provide a domain specific language on top of JavaScript.

Dojo is only Useful for Enterprise Apps and not for Small Sites or Blogs

This myth exists because Dojo was not as small and simple in the Dojo 0.4 days as it is now.

Dojo Base at 26KB gzipped or Dojo Mini down to 5.5KB, both with the same easy to use API, make it possible to do simple progressive enhancement or unobtrusive JavaScript, handle events, Ajax, animations, DOM, querying, and more.

Dojo is Not for Single-Page Apps

The developers from Cappuccino, Objective-J, and Sprout Core argue that they created their efforts because other toolkits are not optimal for true applications in the browser. In our opinion this is rubbish.

Dojo is used widely in feature-rich applications by a variety of companies, such as Sun Convergence, Cisco’s WebEx Connect and IBM’s Project Zero. Dojo is also very widely used for creating applications that live inside the firewall in what I call Ajax Dark Matter.

Dojo is not for Multi-Page Apps and Web Sites

While it’s unlikely that anyone believes both this myth and the previous one, this viewpoint is based on perspective. Given the perceived bloat and toolkit size, some people have suggested that Dojo not be used for multi-page sites, but Dojo’s extensive optimization options make this usage scenario a snap. The Eye-Fi Manager and even the Dojo Foundation web site itself show how snappy these apps and sites are.

Dojo is Just About Widgets

Dojo has a highly flexible, and extremely fast widget system called Dijit. This is a completely optional package for people needing to use and create their own widgets. It is designed to handle a variety of use cases in a modular manner, including accessibility, internationalization, layout, containment, templating, and much more. The underlying concept is that each widget is simply an HTML template, a CSS template, and a JavaScript file for logic.

Many of our users never even touch Dijit.

There are other ways to get lightweight reusable behavior on the fly, including Dojo’s implementation of the Django Templating Language (DTL).

Interest in Dojo is Waning

Why do people think this? Perhaps it is from badly argued stats. People do things like compare Google stats for searches like “jQuery JavaScript” “Prototype JavaScript” “Dojo JavaScript”, etc. because the words on their own conflict with general search terms. Lies, damn lies, and statistics, right?

While interest in other great toolkits has also grown significantly, the usage of Dojo continues to grow aggressively, based on the number of deployed applications, downloads, site traffic, books sold, and a variety of other usage statistics. By all appreciable measures, interest in Dojo is growing faster than ever.

Ajax has become increasingly more popular, and JavaScript is now considered a real language. Dojo has always treated JavaScript as a first-class language, and has a stricter focus on utility than on one particular aspect of the workflow, such as the DOM.

Dojo Doesn’t Validate

A long standing complaint is that Dojo doesn’t validate. DTD != valid HTML. Custom attributes have always been valid HTML, they just don’t validate when tested against a DTD.

If DTD validation is truly important to your project, it is simple to use Dojo with graceful degradation as well; the use of custom attributes is an implementation pattern only, not a hard requirement for using Dojo. Or you can always create a DTD.

In addition to performance benefits and efficiencies of custom attributes, they are a lot friendlier and human-friendly than other options. For example, some toolkits use the rel attribute, and stuff it with data. jQuery’s popular meta plugin looks like this: “<div class=”hilight { background: ‘red’, foreground: ‘white’ }”>”. Why is this better than this non-real, but Dojo style markup: “<div jQueryType=”hilight” background=”red” foreground=”white”>”?

The HTML specification states that any attribute not recognized is to be ignored by the HTML rendering engine in user agents, and Dojo optionally takes advantage of this to improve ease of development.

Dojo is Ugly

Creating beautiful web applications is about having a great sense of style, and interaction/user experience design capabilities. Dojo provides 3 professionally designed themes: Tundra, Soria and Nihilo. If you would like to make them look better, or create a new theme, then get involved!

Dojo’s themes are deliberately understated to make it easier to drop components in alongside existing designs and brands. But at SitePen, in our work with clients we’ve applied our CSS and design skills to Dojo-based applications to create excellent designs and amazing experiences.

Sun Convergence

Eye-Fi Manager


Many other companies are also succeeding with theming their Dojo-based applications.

ESRI Site Selection and Trade Analysis Area

Dojo Doesn’t Offer Certain Features Provided by a Particular Library

This may be the case, or it might be called something different or available through a different API style. But Dojo offers extreme flexibility. For example, check out Peter Higgins work to add the missing jQuery API footprint he likes to Dojo in less than 1 KB.

Dojo Doesn’t Work with a Particular Toolkit, Environment or Server

We go out of our way to make sure Dojo works with everything, even when a toolkit or server doesn’t behave the way we’d like. If something is not working for you, just ask on the Dojo Forums or through SitePen Support, and if there’s a bug, file a ticket and it will get fixed ASAP. We’ve gone to great lengths to make sure Dojo works well with popular toolkits, as well as in a variety of environments including: XUL, command-line, Jaxer, AIR, etc., support for initiatives by the OpenAjax Alliance, as well as integration with DWR, Persevere, Zend Framework, IBM Websphere, Django, Ruby On Rails, and much, much more.

Dojo was initially started to stop reinventing the DHTML toolkit wheel, with the original Dojo source code based significantly on the work of earlier toolkits such as netWindows, BurstLib, and f(m).

The People at Dojo Don’t Like a Particular Project

In general, on an interpersonal level, we’re friends with the people creating jQuery, Prototype, YUI, MooTools and more. While Dojo developers of course have differences of opinion in the best approach to development (great developers should disagree, as long as they keep the debate focused on merit rather than the form of the message), we find that fans of Dojo and other toolkits attempt to make things a bigger rivalry than toolkit authors do. After all, we are talking about open-source toolkits that are liberally licensed (BSD, AFL, MIT, Apache, etc.), so it’s hard for us to not get along. Alex Russell, Peter Higgins and I are also on record as inviting other toolkits to collaborate and cooperate to again stop reinventing the wheel.

Ajax Experience Panel with People from Prototype, YUI, jQuery, and Dojo

In many cases, this is a matter of perspective. I know that many of us get bugged because so much of the mud flinging happens not because someone’s done something wrong, but because features of a particular toolkit are criticized because the person doing the criticizing doesn’t understand why those features even exist in a particular toolkit.

It is difficult to contribute to Dojo or Get Involved

Unlike most other toolkits, Dojo requires a CLA which protects your IP rights, and also requires that when you contribute code, you have the right to contribute it. The Dojo Foundation does this to ensure that we are able to redistribute every piece of code in the Toolkit completely free and with liberal licensing. It’s a simple process that should take at most fifteen minutes, and it is well worth the effort. For more information about getting involved, contributing, donating, visit the Dojo Foundation and Dojo Toolkit web sites, or visit the Dojo IRC channel on in #dojo.

Dojo lacks Commercial Support

A number of companies including SitePen offer Dojo development, support and training services. The Dojo community offers great free support, but when an issue goes beyond what is reasonable to ask of a volunteer, or needs to occur immediately and/or under an NDA, companies like SitePen are available to help you get productive, from fixing a bug in Dojo to building and designing your entire application.


As you can see, Dojo has come a long way since its initial creation 4+ years ago. Over the next several months, Dojo developers will continue to improve the toolkit source code, documentation and marketing to make Dojo easy to use regardless of the type of application or web site you are developing.

I hope you will make the decision to use, or not use, Dojo based on merit, rather than on myths or information that is no longer or was never accurate.

Learn more about how SitePen can be your partner

SitePen is a strategic consultancy committed to achieving technical objectives, solving critical business problems and helping our customers build web applications the right way, the first time.
Share This