Because you picked up this book, I’m guessing that you probably already know a little about Dojo. You probably know that it is a tool for working with JavaScript. So before we delve into the specific history of Dojo, we should say just a little about JavaScript.

JavaScript is the programming language built into a browser. It has been available in almost all browsers since 1995. By utilizing JavaScript in a web page you can make your pages come alive by interacting much more directly with the user. For example, JavaScript can be used to validate user input, display interesting visual effects, perform calculations, and respond to user events. In an effort to describe these wonderful features a new term was even coined—dynamic HTML (DHTML). JavaScript can turn HTML from a dry, dead, static markup language into a dynamic interactive visual environment for the user.

If you’re having trouble remembering all the wonderful interactive web sites available in the 90s, it’s because the nirvana promised by DHTML never quite materialized. It turned out that DHTML had a number of problems. Different versions of the browsers supported different versions of JavaScript. The object used to represent the web page internally (what we would now call the DOM) also differed from browser to browser, making it difficult to write JavaScript that could work in any browser. So some developers avoided using JavaScript at all. Other developers used it but in isolated ways, never taking full advantage of the language. After the browser wars of the 90s subsided, when Microsoft and Netscape stopped constantly releasing new versions of their browsers to introduce some new feature, a Pax Microsoft settled over the land. The early 2000s were characterized by relative calm in the browser market place, the good news being that the browser feature set became more settled and consistent, the bad news being that the pace of new feature introduction slowed enormously.

By the beginning of 2005 some standard patterns for using DHTML had evolved. Developers would use it to ensure certain kinds of client-side validation. For example, JavaScript was often used to ensure that the user had entered a required field before a form was submitted to the server. It was also used to develop stand-alone GUI widgets such as calendar widgets to be used for selecting dates rather then entering them as plain text.

Page designers often knew very little about how the DHTML JavaScript worked. They would often add DHTML to their pages by cutting and pasting from other sites when they found a feature they liked or by downloading DHTML snippets from a number of web sites dedicated to providing useful DHTML code. Pages might contain multiple widgets obtained from different sources that provided some stand-alone feature but weren’t integrated with each other. Developers didn’t think of JavaScript as a cohesive full-blown programming model but as more of a primitive scripting language that could be used to add some neat features here and there in the page.

That all changed in early 2005. Google released a couple of extremely interesting applications, Google Mail and Google Maps. Both applications behaved much more like traditional desktop applications with rich user interfaces than like the clunky HTML applications common at the time. Google Maps especially caused a paradigm shift in how developers thought about the limitations of user interface by implementing a sophisticated drag-and-drop capability in the maps. Up until that time, the most popular mapping sites, Yahoo and MapQuest, allowed a user to move around a map by clicking a direction icon, which would request an entire new page from the server so that the user moved from right-to-left or up-and-down in a herky-jerky fashion. Google Map users could smoothly scroll in any direction, using their mouse without a page being refreshed.

The new paradigm couldn’t be complete until it was given a name. And that is exactly what Jesse James Garrett, a San Francisco-based user interface designer, did when he published a paper on the new techniques and christened them as “AJAX.” He described a set of technologies that could be used to request data from the server while a page was displaying the browser without refreshing the page. The data from the server would then be used to update the display using DHTML. Google had demonstrated what wondrous pages could now be created, and Jesse had given it a name. The web development community was shaken out of its collective slumber and began work on Web 2.0. AJAX became Ajax—what once was a description for some specific technology components (Asynchronous JavaScript And XML) became a more general description of web pages that adopted user interface techniques that had only been seen before in non-browser applications.

Note that the actual techniques used to implement Ajax had been around for a number of years and had even been used in a number of web sites. The coinage of the term “Ajax” helped to popularize the techniques.

The use of JavaScript within web pages exploded, which resulted in a few painful repercussions. Developers realized that JavaScript was a full-blown programming language, not just a toy for script kiddies. It was a mature object-oriented language that required the developer to understand object-oriented programming techniques. Unfortunately, developers also realized that many of the tools and libraries that had been developed in other programming environments had not yet been developed for JavaScript. In addition, there were still a number of inconsistencies between popular browser versions in how JavaScript, the Event Model, and the DOM worked. And that set the stage for the emergence of the Dojo DHTML toolkit.

The increasing importance of JavaScript did not go unnoticed. More and more developers were spending time working with JavaScript and dealing with its many complexities, idiosyncrasies, and outright bugs. Some of the lead developers in the community were strategizing on how to address these problems. One particular group of developers decided the solution might lie in creating their own DHTML library. And in September 2004 the first version of Dojo was released. Although the product was a community effort, Alex Russell and Dylan Schiemann were among the lead developers. In early 2005, the Dojo foundation was established by Alex and Dylan to manage the ownership of the product.

Dojo has attracted a large community of both users and developers. As of early 2007, Dojo had gone through four releases and had been downloaded hundreds of thousands of times.

You can find more detailed information on the history of Dojo at the web site: http://www.dojotoolkit.org.

The primary purpose in developing Dojo was to address the inadequacies inherent in JavaScript programming, in other words, to make JavaScript programming easier.

Following are some of the specific goals that the developers wanted to achieve:

Although some of these goals are at cross purposes (for example, it is hard both to have a small footprint and still be robust) Dojo has achieved a harmonious balance.

To quote the web site, “Dojo is an open source, DHTML toolkit written in JavaScript.” Let’s break this down a bit to understand what it means. We’ll start with the last part of the statement first.

In the next chapter, we begin to drill down into the Dojo source code, but for now, let’s describe it at a high level. Dojo consists of a set of files that contain JavaScript code. By including one or more of the files in your web page, you can write JavaScript code that uses Dojo. This allows you to write much less code than you would normally have to. Most of the Dojo code contains either functions that your custom code can call or constructors that allow your custom code to create objects such as GUI widgets. Dojo functions and constructors don’t contain any magic. If you don’t believe me, you can check it out yourself—all the source code is there for you to see. It’s all just JavaScript that you could’ve written yourself, but because of all the hard work of the Dojo community, you don’t have to.

Dojo functions and constructors run within the browser. Dojo does not provide any components to run on the server. This makes the Dojo server agnostic. In other words, it doesn’t care what the server is as long as that server knows how to process HTTP requests. So web sites can be developed that use Dojo in the browser while the server may use Java J2EE, PHP, or Ruby on Rails, among others. Because of this, when creating an application using Dojo, you will also usually need to develop components on the server side, which respond to Ajax requests from the browser. More on this later, but for now, just remember that Dojo provides components only for the browser.

As we’ve said, Dojo was developed to address some of the problems with JavaScript development. But what, specifically, were those problems? Following is a list of the major issues that Dojo was created to solve:

The last point is especially interesting and can be further explained by an example. The Java programming language (that’s “Java,” not to be confused with “JavaScript”) contains a little less than 50 different object types in its core package. However, there are an additional 5,000 object types defined in the class libraries that come with the standard Java development kit. JavaScript also contains somewhat less than 50 standard objects and object types, but it lacks any standard class libraries to augment that number. We’re not saying that JavaScript needs another 5,000 data types, but surely it needs more than 50, and Dojo supplies many of those. Later we talk specifically about what those missing classes are.

Dojo can be used by anyone who develops Web pages. But there are three groups for whom Dojo is an almost perfect fit. The first group is developers who are already writing complex JavaScript. They are already encountering all the problems that Dojo was meant to solve. By adopting Dojo, they can increase their productivity and reduce their level of frustration. And the good news for this group is that they can adopt Dojo as quickly or as slowly as they wish. Dojo won’t step on any of their existing code because of its use of a separate namespace. So they can began adding Dojo to existing pages for new features and to slowly convert their old code as they have time. This is a really important advantage for Dojo, and makes it easy to get started. You can bite off as much or as little as you want.

The second group of developers who should be using Dojo are page designers. The stereotypical page designer has skills in graphic design, page layout, and the use of the HTML tag language. The skill that they don’t usually possess and often aren’t interested in acquiring is the ability to write programs. They don’t want to write JavaScript. However, they would still love to get access to some of the beautiful widgets available on the Dojo toolkit. Luckily for them, Dojo widgets can be added to a webpage simply through HTML markup with little or no coding.

The third group of developers who should be using Dojo are server-side developers. These are the developers responsible for creating the backend part of the web site, the programs that run on the web server itself. Although we might not think of them as typically being involved in page design, there is a role for them. Server side developers usually receive HTML files provided by the page designer and add the extensions that allow the page to communicate with the backend functionality that the site requires. These developers might be PHP developers, Ruby on Rails developers, Java developers, or developers experienced in any of a host of backend technologies available today. They usually know enough HTML to get by but not much JavaScript. Now with the introduction of Ajax and the focus on creating more dynamic web pages, they’re being asked to become JavaScript programmers. Given their current responsibilities they can’t really be expected to become JavaScript experts overnight and to understand all the possible pitfalls of JavaScript programming that we’ve already discussed. This is where Dojo is the perfect fit for them. By using the Dojo functions and constructors, these developers can avoid having to learn all the ins and outs of JavaScript and benefit from the years of experience already built in to Dojo.

I’m not a lawyer, nor do I play one on TV. So I’m not really one who should be giving legal advice. But here goes anyway. Dojo is an open source project, and the common perception of open source projects is that they can be used in any way that you wish. Developers often think of open source projects as products that they don’t have to license like they do typical vendor software. However, that perception is wrong. Open source projects are made available under varying licenses that convey rights and responsibilities. By using Dojo, you’re accepting one of those licenses, and there are some restrictions.

Dojo is made available under two licenses. This is known as dual licensing. You’re not, however, constrained by both licenses, only the license you pick. So whichever one provides the terms that you are looking for can be used. And there’s no requirement for notifying Dojo which license you pick. You don’t have to pay any money, sign any contracts, or deal with any paperwork of any kind.

The first license, known as the Academic Free License, allows you to use the code in both non-profit and commercial applications. Changes that you make to Dojo do not have to be submitted back to the Dojo community. And there is no requirement that you make your source code that uses Dojo available to anyone. The intent of the license is to encourage the adoption of Dojo without adding any unreasonable restraints.

The second license is the modified BSD license. It contains many of the same covenants as the first license. It allows you to use Dojo, modify it, or package it within your commercial application without having to submit your changes to Dojo or make your source code public.

In many ways the purpose of Dojo licensing is not to restrict you as a developer but simply to protect Dojo. You can’t sue Dojo for bugs that it may have or that you introduce. And you can’t claim that you now own Dojo and start suing anybody else who uses it.

Disclaimer and fine print: As I’ve already said, I am not a lawyer. This licensing discussion is merely my opinion and represents my understanding. You or your organization will have to determine which license is appropriate and what restrictions really apply to you.

Internet applications with sophisticated graphical widgets are also know as Rich Internet Applications (RIAs). Dojo is an important toolkit for creating RIAs but is not the only solution. Let’s briefly talk about some of the products that address the same needs as Dojo.

First is a product that is most like Dojo—an open source DHTML toolkit that provides no server-side components:

Next is a product that allows users to develop RIAs but is based on a client-side plugin:

Finally, let’s review a product that can also be used to develop RIAs but takes a completely different technical approach:

This is a very small and unscientific sampling of the alternatives to Dojo. There are many more—at last count over 100. You can read about them at the excellent site maintained by Michael Mahemoff at http://ajaxpatterns.org.

While Dojo has existed in some form since 2004, it went through a major change at the end of 2007 when the 1.0 version of Dojo was released. This was the first version of the product that the Dojo team felt reached the level of quality necessary to be designated as the 1.0 version. It is of a consistent high quality, very lightweight, and provides the important functionality required of a DHTML toolkit.

Dojo has already had a large impact on the web development community, both as a toolkit used for many applications and as a thought leader that has pushed the frontier of web development. But what about its future? As Yogi Berra said, “I never make predictions, especially about the future.” We should also be careful in making forward-looking statements. But I think it is safe to say that with the 1.0 release, the rate of adoption of Dojo should increase. Because of the robustness and completeness of the Dojo feature set, we should see further inroads for Dojo into large enterprise shops. And because of Dojo’s ease of use and small footprint, small to mid-size organizations will also continue to be drawn to it. And because of the large and sophisticated developer community, I think we can expect Dojo to evolve and push the boundaries of web development for the foreseeable future.

More information is available at the Dojo web site at http://www.DojoToolkit.org. The next chapter continues to introduce the Dojo Toolkit, but we change focus from a general discussion to a more technical discussion. And we start to look at the code. Like many developers, I don’t really start to understand a new programming environment until I see the code. So on to the code!