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:
- The Dojo Markup Language and DOM-rewrite, and
- 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: