Loading article…
Dojo (stylized as Dojo Toolkit or dōjō toolkit before 2.0) is an open-source modular JavaScript library or (or more specifically toolkit or UI framework) 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[4] and is dual-licensed under the modified BSD license or the Academic Free License (≥ 2.1).[6]
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 the jQuery Foundation to become the JS Foundation[7][8][9] which in 2019 subsequently merged with the Node.js Foundation to form the OpenJS Foundation[10]
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 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:
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 (dojo.xhr) around various web browsers' implementations of XMLHttpRequest, and dojo.io 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.[11]
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.
Dojo has support functions for reading and writing cookies. It also previously 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. When included in a web page, Dojo Storage determines the best method for persistently storing information. It works across existing web browsers, including Internet Explorer, Firefox, and Safari. Firefox 2 uses native browser persistence; on other browsers, it uses a hidden Flash applet. With Flash 6+ have previously been installed on about 95% of computers connected to the web,[12] this previously made 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.
As of January 2007, Dojo includes the following example server-side datastore implementations in the dojo.data namespace:[13]
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.[14]
Earlier versions of Dojo had a reputation for being bulky and slow to load.[15] 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.[16]
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.[17][18]
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.[19]
Many have commented that Dojo seems difficult to learn and get started with, especially in comparison with the more popular jQuery.[20][21]
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."[15]
Early users faced a difficult transition to the 2.0 release after the toolkit was totally rewritten.[18] The move to AMD in recent versions has been similarly problematic.[21] 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.
