Dojo Explained

Dojo Explained

August 2006

Abstract  While people talk about Dojo a lot, some don't really understand what Dojo is about. This article explains the two key ideas that are the foundation of the Dojo Toolkit. The first idea is the Dojo Markup Language and page DOM rewrite. The second idea is the JavaScript packaging mechanism in order to elevate JavaScript for large-scale development.

Dojo is almost a technical wonder that people are that bold to exploit the potentials of DOM and JavaScript. But this is a highly risky trend if the whole industry adopt ideas like this, because Dojo's basic premises, DOM and JavaScript, are extremely fragile. This article examines some of the key concerns and advises that using DHTML to develop large-scale RIAs demands discretion.

 

The Dojo Toolkit is a profound DHTML framework. It is one of the DHTML technologies that qualify for building full-fledged Rich Internet Applications (RIAs). Although still in early stage of development, it has already stirred up the industry. While people frequently refer to it, many don't really understand what it is about. People tend to think that Dojo is an AJAX framework; this is not true. Dojo is way beyond AJAX. In this article, we are going to examine the key ideas of the Dojo technology and experience it first hand.


The Big Ideas of Dojo

The Dojo Toolkit provides incredible functionalities in terms of DHTML applications; its foundation rests on two key ideas:

  1. The Dojo Markup Language and DOM-rewrite, and
  2. Extending JavaScript 1.x the language itself.

The Dojo Markup Language

Dojo's first key idea is the Dojo Markup Language. At first thought (not first glance!), Dojo programs should be like any HTML pages with included JavaScript code. No, that's not true. In a Dojo program, you will see non-HTML tags and/or HTML tags with "strange" attributes such as dojoType. The following is an example.

<html>
<head>
  <script type="text/javascript">
    var djConfig = { isDebug: true }
  </script>
  <script type="text/javascript" src="dojo/dojo.js"></script>
  <script type="text/javascript">
    dojo.require("dojo.widget.Button");
    dojo.hostenv.writeIncludes();
  </script>
</head>
<body>
  <button dojoType="Button" onclick='dojo.debug("Clicked.")'>
    <img src="images/plus.gif"> Create
  </button>
</body>
</html>

The <button> is clearly not a HTML tag. When this page is loaded into browser, the page first shows up in one way, then changes into its final look; depending on the complexity of the page, this transition may be barely visible or may last up to a few seconds. This is exactly how Dojo works. Dojo registeres an onload event handler for <body>; as soon as the page code is loaded by the browser, Dojo takes over the DOM tree, parses for special tags that Dojo understands (the Dojo markups), and re-renders the whole page. Yes, Dojo renders the page after it is first rendered by the browser; that's why you see the change when the page is first loaded. The Dojo Markups not only include its own tags, but any standard HTML tags with a dojoType. Effectively, Dojo defines its own markup language.


Dojo's Extension to The JavaScript Language

JavaScript is a dynamic language. For large-scale software development, it is very weak and hard to develop and maintain.

Dojo introduces a packaging mechanism to the JavaScript programming. Everything in JavaScript is dynamic and constructive; the Dojo packaging mechanism is no exception. Dojo defines an API to dynamically create and use packages. Conceptually, Dojo packages are not like those in Java or ActionScript, but rather, grouping. Nonetheless, Dojo package enables two important features for large-scale development in JavaScript: namespace conflict avoidance and selective deployment.

By using Dojo package, application code as well as Dojo system itself can readily avoid namespace collisions. This is quite obvious.

Dojo package enables selective deployment. The dilemma of JavaScript libraries is that, application code need to download the JavaScript libraries in the pages. Dojo, a comprehensive framework, is growing really big; downloading all the .js files in DHTML pages, big and small, is ridiculous. With Dojo package mechanism and the Dojo deployment tools, you can programmatically specify the used packages, then Dojo will include code of those packages only, not the whole library. After you are done with development, use the Dojo deployment tool looks for the package inclusion statements in the source code and bundles only the necessary JavaScript code into a single .js file to speed up its download over HTTP. The tool also "compresses" by stripping unnecessary whitespaces and comments.

To create a package for your own code, the dojo namespace has two methods: provide() and kwCompundRequire(). Dojo defines a pattern for you to declare and create packages for your code, where you need to store your JavaScript source files in designated directories, and call those two methods in files with predefined names.

To use code in a Dojo package or group, call the dojo.require() like you saw in the above example.


Dojo Widget Collection and Other Resources

Dojo is accumulating a growing set of widgets and other library code from a number of sources. This is a major attraction for using Dojo.


The Name of the Game is Big Applications

For small projects or scattered embelishments of DHTML pages, any AJAX code works. Dojo is a profound toolkit or framework; it is destined for large application development. The name of the game is big applications.


Concerns About Developing With Dojo

Developing big applications with Dojo (and DHTML in general) presents concerns.

The Dojo Markups are a great technical feat; they also hide the details of widget implementations from users. On the other hand, these markups are mixed with regular HTML tags such as <table>, <div> and Dojo's layout widgets. How the eventual pages look like is not obvious or possible to visualize during editing. This can be frustrating.

The Dojo Markups are eventually rewritten, at runtime, into legitimate HTML tags in the DOM tree, which usually involves many styles and resources. When problems arise, or you need to do anything beyond what Dojo provides, heavy detective work is expected.

Development tool is a big issue. GUI development is a very tedious process. Today, there are JavaScript debuggers for different browsers. The JavaScript language is totally dynamic, which means that an object (or its prototype) may or may not have a specific method. For instance, in Dojo, certain classes can be augmented in different packages (so that unused groups of methods can be left out by the Dojo packaging tool). What this means is that, when you type in the code to call a method of an object, you need to make sure that method exists; no editing tools or compilers can help you on this; you need to trace your code to find out. The surest way to do this is perhaps to inspect at runtime using a debugger. Now, again, compounded with Dojo Markup rewrite, either the debugger can be confused or you have to figure out the relationship between the point in JavaScript code (that you stop at) and the GUI elements and events. And that was based on the premise that you know where to set the break point in the first place.

And, on top of all those, you need to debug your programs twice: once for Internet Explorer, once for Mozilla, unless you limit your users to using one designated browser. This is the notorious nightmare of DHTML development. The DOMs in IE and Mozilla are well-known for their incompatibilities, including event handling and GUI behaviors. Compounded with the Dojo Markup rewrite, one may be totally lost as to, say, modify a simple GUI behavior like resizing the components with their parent containers or browser windows.

These concerns present a grim outlook for developing large RIAs using Dojo. Even though Dojo and other DHTML frameworks seem to gain popularity, prudent discretion is highly recommended for your decision on your next RIA strategy.

Consider yourself warned.

Related Articles: