Dojo Toolkit

Dojo Toolkit (stylized as dōjō toolkit) is an open-source modular JavaScript library (or more specifically JavaScript toolkit) designed to ease the rapid development of cross-platform, JavaScript/Ajax-based applications and web sites. It was started by Alex Russell, Dylan Schiemann, David Schontzler, and others in 2004 and is dual-licensed under the modified BSD license or the Academic Free License (≥ 2.1).

The Dojo Foundation was a non-profit organization created with the goal to promote the adoption of the toolkit. In 2016, the foundation merged with jQuery Foundation to become JS Foundation.

Overview
Dojo is a JavaScript framework targeting the many needs of large-scale client-side web development. For example, Dojo abstracts the differences among diverse browsers to provide APIs that will work on all of them (it can even run on the server under Node.js); it establishes a framework for defining modules of code and managing their interdependencies; it provides build tools for optimizing JavaScript and CSS, generating documentation, and unit testing; it supports internationalization, localization, and accessibility; and it provides a rich suite of commonly needed utility classes and user-interface widgets.

Dojo is completely open source. The toolkit includes about three thousand JavaScript modules, in addition to images and other resources.

The Dojo Toolkit is organized in several parts:
 * dojo contains the core and most non-visual modules.
 * dijit is a library of user-interface modules for widgets and layout.
 * dojox holds assorted modules not yet considered stable enough to include in dojo or dijit.
 * util includes build tools such as optimization, documentation, style-checking, and testing.

Widgets
Dojo widgets are components — comprising JavaScript code, HTML markup, and CSS style declarations — that provide multi-browser (not to be confused with cross-browser), interactive features:


 * Menus, tabs, and tooltips
 * Sortable tables
 * Dynamic charts
 * 2D vector drawings
 * Animated effects&mdash;fades, wipes and slides&mdash;facilities for custom animation effects

Asynchronous communication
One important feature of Ajax applications is asynchronous communication of the browser with the server: information is exchanged and the page's presentation is updated without a need for reloading the whole page. Traditionally, this is done with the JavaScript object XMLHttpRequest. Dojo provides an abstracted wrapper around various web browsers' implementations of XMLHttpRequest, and   also supports other transports (such as hidden IFrames) and a variety of data formats. Using this approach, it is easy to have the data a user enters into a form sent to the server "behind the scenes"; the server can then reply with some JavaScript code that updates the presentation of the page.

Packaging system
Dojo provides a packaging system to facilitate modular development of functionality in individual packages and sub-packages; the base Dojo "bootstrap" script initializes a set of hierarchical package namespaces — "io", "event", etc. — under a root "dojo" namespace. After initialization of the root namespace, any Dojo package can be loaded (via XMLHttpRequest or other similar transport) by using utility functions supplied in the bootstrap. It is also possible to initialize additional namespaces within or parallel to the "dojo" namespace, allowing extensions of Dojo or the development of private Dojo-managed namespaces for third-party libraries and applications.

Dojo packages can consist of multiple files and can specify which files constitute the entire package. Any package or file can also specify a dependency on other packages or files; when the package is loaded, any dependencies it specifies will also be loaded.

Workarounds for cross-domain loading of most Dojo packages are provided (though this requires a specialized build of Dojo).

Dojo also provides a mechanism for building "profiles"; the build system takes as input a list of packages, and uses Rhino to create a single compressed JavaScript file containing those packages and all their dependencies. This allows all necessary code to be loaded and initialized at once, and permits caching of the code (most web browsers do not cache files loaded via XMLHttpRequest). Pre-built profiles for some common use cases are available for download from the same location as the full toolkit.

Client-side data storage
In addition to providing support functions for reading and writing cookies, Dojo formerly supported a local, client-side storage abstraction named Dojo Storage. Dojo Storage allows web applications to store data on the client-side, persistently and securely and with a user's permission. It works across existing web browsers, including Internet Explorer, Firefox, and Safari. When included in a web page, Dojo Storage determines the best method for persistently storing information. Firefox 2 uses native browser persistence; on other browsers, it uses a hidden Flash applet. With Flash 6+ being installed on about 95% of computers connected to the web, this makes the storage mechanism accessible for much of the web's installed base. For a web application loaded from the file system, i.e., from a file:// URL, Dojo Storage will transparently use XPCOM on Firefox and ActiveX on Internet Explorer to persist information. The programmer using Dojo Storage is abstracted from the storage mechanism used and is presented with a simple hash table abstraction, with methods such as put and get. Dojo Storage is not supported in versions later than the 1.3 release.

Server-side data storage
As of January 2007, Dojo includes the following example server-side datastore implementations in the dojo.data namespace:


 * CsvStore: a read-only store that reads tabular data from comma-separated values files
 * OpmlStore: a read-only store that reads hierarchical data from OPML format files
 * YahooStore: a read-only store that fetches search results from the Yahoo! Search web service
 * DeliciousStore: a read-only store that fetches bookmarks from the del.icio.us web service
 * RdfStore: a read-write store that uses SPARQL to talk to RDF data servers including, for example, the Rhizome RDF application server.

Support for Adobe Integrated Runtime (AIR)
Dojo can be used in JavaScript-based Adobe AIR applications. It has been modified to meet AIR's security requirements.

SitePen, a Dojo consulting company, has made an Adobe AIR application called "Dojo Toolbox" using Dojo. It includes an API viewer and a GUI to Dojo's build system. Normally, the build system is run from within Rhino, but in this AIR application the build system can be run from AIR, without the use of Java.

Loading
Earlier versions of Dojo had a reputation for being bulky and slow to load. It also required extra work to load Dojo across domains, e.g., from a CDN. Addressing these problems was the major goal of Dojo 1.7, which introduced asynchronous module definition (AMD) and a "nano" loader.

Documentation
Dojo has long been criticized for its incomplete, scattered, and outdated documentation. Recognizing this, the developers made huge improvements in the documentation for the 1.8 release, including new tutorials, an API browser, filling in the missing pieces, and updating most examples to AMD style.

A number of books have been written about Dojo, but all based upon Dojo 1.3 or earlier, now several years out of date. Since these predate AMD support and its accompanying reorganization, examples in these books almost invariably rely on things that are now deprecated and no longer best practice. Most authors are waiting for Dojo 2.0 before publishing anything new.

Learning curve
Many have commented that Dojo seems difficult to learn and get started with, especially in comparison with the more popular jQuery.

Dojo co-creator Dylan Schiemann acknowledges this as a consequence of their different scopes: "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."

API stability
Early users faced a difficult transition to the 1.0 release after the toolkit was totally rewritten. The move to AMD in recent versions has been similarly problematic. Dojo has taken great pains to maintain backward compatibility despite its rapid evolution, with a large portion of the current API deprecated but still maintained, but users have often found that upgrades did not go as smoothly as hoped.

Dojo 2.0 release removed much of the deprecated API and switched from JavaScript to TypeScript.