Introducing the dojo-amd-converter

We have created an alpha quality release of dojo-amd-converter, a tool for helping you make a one-time migration of your existing source code to a newer version of Dojo.

Be warned, the tool handles only 70-80% of the manual conversion process, and generally does better with more standard usage of Dojo. Normally we wait a bit longer before announcing our projects, but this should be useful in its early alpha state. We know this tool has quite a few open issues that need to be fixed and we invite you to help us improve it.

Our hope is that this conversion tool, which is today useful for converting pre-AMD code to AMD code, could also form the basis for a community effort to make it possible to migrate code bases more efficiently from Dojo 1.x (pre-AMD or AMD) to Dojo 2.x. That work has not yet started, since Dojo 2.0 is not yet an actual thing.

What does it do?

Based on a collection of rules, and leveraging Node.js, libxml.js, and esprima, the parser will take an existing Dojo source tree, and convert the following:

• non-AMD modules to AMD modules
• namespace references to module references
• legacy HTML custom attributes to HTML5 compliant data-dojo-*
• legacy i18n bundles to AMD bundles
• older Dojo APIs to their refined replacements

For example, if before conversion you had a file like this:

dojo.provide("my.namespace.i18n.Bundle");
dojo.requireLocalization("dijit", "common");
dojo.requireLocalization("foo.package", "Bundle");
dojo.requireLocalization("bar.package", "Bundle2");

var foo = dojo.i18n.getLocalization("foo.package", "Bundle"),
	bar = dojo.i18n.getLocalization("bar.package", "Bundle2", foo.bar),
	baz = {
		locale: "en-lol",
		i18n: dojo.i18n.getLocalization("bar.package", "Bundle2", this.locale)
	};

You would end up with this, after conversion:

define([
	"dojo",
	"dojo/i18n",
	"dojo/i18n!bar/package/nls/Bundle2",
	"dojo/i18n!dijit/nls/common",
	"dojo/i18n!foo/package/nls/Bundle"
], function (dojo, i18n, i18nBundle2, i18ncommon, i18nBundle) {

	var foo = i18nBundle,
		bar = i18n.getLocalization("bar.package", "Bundle2", foo.bar),
		baz = {
			locale: "en-lol",
			i18n: i18n.getLocalization("bar.package", "Bundle2", this.locale)
		};
});

Usage

To use the dojo-amd-converter, Mac and Linux users should follow these simple steps:

1. Clone the repo using Git:

   git clone --recursive https://github.com/SitePen/dojo-amd-converter.git

2. Modify the provided config.js file to specify some basic settings for your application, such as your source and destination directories.
3. From within the repo, run the provided shell script on your configuration file:

   ./parse.sh config.js

chmod +x parse.sh

config.js options

• excludePaths – An array of paths that will be excluded from processing. Each path should be a regular expression
• srcDir – Root directory of the files to process.
• distDir – Output directory of the processed files.
• printOutput – Print output instead of sending it to the output directory.
• makeDeclareAnonymous – Make declare calls anonymous instead of leaving the first argument as-is. This will avoid creating any global variables with declare.
• removeUnusedDependencies – Remove dependencies that are not referenced in a converted module.
• onlyProcessTemplates – Only process HTML files inside template directories.

The AMD converter does not currently work on Windows, due to the dependency on libxmljs.

Getting Involved

This project is in the early stages, and our hope is that it will also be used for work to convert to Dojo 2.0. We have many open issues for items we have already identified in our work using this tool. The dojo-amd-converter tool is licensed under the same terms and conditions as other Dojo Foundation projects.

To get involved, you will need to have a Dojo Foundation CLA on file for us to consider your code change. Please get involved if this tool is of interest to you now or in the future, as we think it is a much needed improvement for making it easier to upgrade between Dojo releases.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

In fact, there is so much information out there on learning Dojo, it might be overwhelming. In a way, Dojo 1.7′s migration to AMD amplifies the problem, in that many previously-published articles no longer reflect the most recent best practices. This post aims to start you off on the right foot by pointing to relevant up-to-date resources for getting started with — or catching up on — Dojo 1.8.

Why Dojo

10 Reasons your Projects Should use the Dojo Toolkit
Slides: Dojo 2.0: Modular, Mobile, and Reinventing Web App Development
Interview with Dojo Toolkit Co-creator Dylan Schiemann

Getting Started

Tutorial: Dojo Start – Answers many common questions asked by newcomers
Tutorial: Hello Dojo – Guides through the first steps in exploring Dojo

Transitioning from Dojo 1.6

Tutorial: Modern Dojo – Explains key differences between Dojo before and after 1.7
Slides: Moving to Dojo 1.7 and the path to 2.0 – Presents features new to Dojo 1.7 and up

AMD Resources

Tutorial: Defining Modules – Explains how to define and load modules, and configure the loader
AMD: The Definitive Source – Explains the reasoning and benefits of AMD
Slides: Modular JavaScript: AMD & CommonJS modules – Discusses the evolution of AMD
AMD API – Wiki containing AMD API specifications

Learning Dojo

Tutorial: Making Functions with hitch and partial – Explains execution context and how to control it
Tutorial: Classy JavaScript with dojo/_base/declare – Explains Dojo’s chief inheritance mechanism
Tutorial: Ajax with dojo/request – Introduces Dojo 1.8′s new Ajax API
Tutorial: Getting Started with Deferreds – Introduces Deferreds, crucial for asynchronous logic
Tutorial: Dojo Deferreds and Promises – Discusses Promises and their relation to Deferreds
Tutorial: Dojo Object Stores – Explains the dojo/store API, new since Dojo 1.6
Reference Guide: Dojo – Index of reference material for the Dojo package

Learning Dijit

Tutorial: Understanding _WidgetBase – Details the module forming the basis of all widgets
Tutorial: Layout with Dijit – Discusses Dijit’s layout widgets
Tutorial: Creating Template-based Widgets – Describes Dijit’s templating capabilities
Recipe: Creating a Custom Widget – Walks through implementing a widget
Reference Guide: Dijit – Index of reference material for the Dojo package

Developing Applications

Tutorial: Using dojo/hash and dojo/router – Discusses Dojo’s utilities for managing the browser hash
Recipe: Application Controller – enumerates an approach to writing a small app
Dojo Boilerplate – Provides a starting point for creating a Web application with Dojo
Tutorial: Getting Started with dojox/mobile – The first in a series of tutorials to build a mobile app

Build Tool Resources

Tutorial: Creating Builds – Thoroughly explains the various facets of a custom build
Working with Dojo and AMD in Production – Enumerates approaches to loading production builds
Reference Guide: The Dojo Build System – Definitive documentation on the new build system
Dojo Web Builder – An online tool for creating Dojo builds

Dojo Packages

Dojo Foundation Packages – Explains the role packages play in Dojo’s future
dgrid – Web site for dgrid, a Dojo Foundation package

Community

As always, the Dojo community is the best around.  If you get stumped or have an advanced question, you can get more answers by leveraging the following resources:

• Dojo Community, including a forum interface to the dojo-interest mailing list
• Mailing Lists
• Web client for the #dojo IRC channel on irc.freenode.net

If you find that a self-guided tour or community support is inadequate, SitePen also offers workshops taught by Dojo experts, as well as highly responsive support services.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

The technique we originally presented was a quick and simple approach:

<script type="text/javascript" src="../../dojo/dojo.js"
	data-dojo-config="async: true"></script>
<script type="text/javascript">
	require(['dgrid/dgrid'], function () {
	    require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", 
		"dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", 
		"dojo/domReady!"],
		function(List, Grid, Selection, Keyboard, declare, testPerfStore){
		//...

While this works, it’s not ideal because you will need to modify your source when switching between development and production environments which is suboptimal. While you could of course fix this with PHP or some other server-side approach for your initial require statement, there are many simple alternative techniques that you can make directly to your markup. Here we explore five other approaches.

Single-layer builds

Ideal for: A quick, simple, single-layer application

In the original blog post, we focused on building simple nano and baseless builds. In this scenario, you may want to just create a custom dojo.js to include all modules that you need. Then we just have the main require() statement with all the dgrid modules. We don’t need to require() calls to the layer in advance, since the dgrid modules would already be loaded from dojo.js in production. The require() call would just immediately callback since everything the application needs has already loaded.

Defining a different require module based on the URL

Ideal for: Quick and simple approach to loading based on the URL format

This approach evaluates the application’s dependencies as a function of the URL. For example, we could test for the word dev in the URL, and only define a dependency on the built dgrid layer when not in a development environment:

require(/dev/.test(location.search) ? [] : ['dgrid/dgrid'], function(){
	require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", 
		"dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", 
		"dojo/domReady!"],
		function(List, Grid, Selection, Keyboard, declare, testPerfStore){
		//...
	});
});

Configuring layers with deps and callback

Ideal for: Handling the differences between development and production based on URL or other settings within the dojoConfig object

Dojo’s configuration settings allow you to use dojoConfig.deps to load the layer and dojoConfig.callback to start an application:

<script type="text/javascript">
var dojoConfig = {
	async: 1,
	deps: ['dgrid/dgrid'],
	callback: function(){
		require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", 
			"dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", 
			"dojo/domReady!"],
			function(List, Grid, Selection, Keyboard, declare, testPerfStore){
			//...
		});
	}
};
</script>
</script type="text/javascript" src="../../dojo/dojo.js"></script>

When the defined dependencies have loaded, a callback function is executed, all of which is defined within the configuration object. We can now evaluate the application’s dependencies as a function of the URL, similar to the previous example, and then handle the check in the dojoConfig object rather than within a require statement :

<script>
var dojoConfig = {
	async: 1,
	deps: /dev/.test(location.search) ? [] : ['dgrid/dgrid'],
	callback: function(){
		require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", 
			"dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", 
			"dojo/domReady!"],
			function(List, Grid, Selection, Keyboard, declare, testPerfStore){
			//...
		});
	}
};
</script>
</script type="text/javascript" src="../../dojo/dojo.js"></script>

This allows us to vary dojoConfig.deps on a flexible switch. It could be the URL, or a single variable defined at the top of the application’s markup. We can also define dependencies as a function, with more elaborate criteria for defining the dependencies to load for the application.

The flexibility of this technique makes moving between development, test, and production environments simple and efficient.

Top level modules

Idea for: Larger applications with many dependencies

Another common approach for a smooth transition between development and production is to create a single top level module per layer that loads all the other modules each application uses. Then the Dojo build tool can be given a single module per layer to create a layer of the same name, so that development and production both load the entry module, as a single dependency in the HTML. This has the added benefit of keeping JavaScript out of your HTML, particularly your dependencies, so you can have a JavaScript-free HTML file.

For example, you might have a file, app/app.js:

define(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard",
    "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"],
    function(List, Grid, Selection, Keyboard, declare, testPerfStore){
        //...
});

And then, your HTML file would simply contain the following fragment:

<script>
var dojoConfig = {
	async: true,
	deps: ["app/app"]
};
</script>
<script src="dojo/dojo.js"></script>

Dojo Boilerplate

Ideal for: Mostly automated approach to following many Dojo best practices for building apps

The Dojo Boilerplate project will handle this scenario for you automatically. It identifies a few Dojo application architecture conventions to follow, and then contains a build script that assists when moving from development to production.

Conclusion

As you can see, there are many approaches to simplify your approach for working with Dojo layers in production when using AMD. Let us know in the comments if you have another technique you prefer, or if you have any questions.

References

• Dojo loader reference docs, including details about deps and callback
• API docs for dojoConfig
• Dojo Boilerplate

Help for your application

Contact us for more information on how we can help you migrate your application to fully leverage AMD. Or, check out our excellent Dojo and JavaScript support services, which can be utilized for working on any AMD-based development project.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Our top goal for this release was to significantly improve the quality of Dojo’s documentation. SitePen proudly contributed in the following areas:

• Helped make many of the more than 500 fixes to our documentation based on community feedback (thank you!)
• Helped improve the content found in the reference guide
• Developed a brand new, extensible JavaScript-based documentation parser, which we use to generate output for the API viewer
• Updated 70% of the existing Dojo tutorials to be accurate for Dojo 1.8. The remainder will be updated in the next few weeks.
• Started working on 10 new tutorials, including an updated Ajax tutorial covering the new dojo/request API for Ajax requests.

Thanks for your ongoing suggestions and support. We look forward to your feedback on this release.

From workshops to support to full-scale development, SitePen is the leading industry expert in all things Dojo. Contact us today to discover the best way SitePen can help you upgrade to Dojo 1.8.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Getting right to the point, (The Official Point!), we are pleased to announce the expansion of SitePen Support to officially include more than fifteen popular open-source JavaScript toolkits!

Now supporting the following JavaScript toolkits:

In addition to toolkits, we will continue to support your custom JavaScript source code, as well as key underlying technologies and formats, including JSON, HTML5, WebSockets, SVG/Canvas, Mobile Web, Server-Side JavaScript, AMD, Node.js and many more.

Our expertise with Dojo and advanced JavaScript is relevant for a wide-range of desktop and mobile web application projects and our approach to SitePen Support has always been flexible with the priority being to improve our customers’ web apps. We strive to support our customers in every way possible and we continue to be Dojo experts. In addition, we’re now committed to providing your organization with the front-end development expertise that will optimize your application regardless of which toolkits and technologies your company is comfortable using. You have our word!

Learn More About SitePen Support or Contact Us to get started today!

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

AMD is an emerging defacto standard for efficiently developing modular JavaScript applications and libraries. There’s a tremendous amount of business benefit to be achieved from making the switch to AMD for any JavaScript application. If you’re using Dojo 1.7+, you’ve already made the switch and are reaping the rewards as we speak!

Utilizing AMD in your web application dramatically affects code maintainability, application performance and interoperability and these will assuredly result in the following benefits for your business:

1. Efficient engineering
2. Improved user experience
3. Empowered technical leadership

Let us tell you how!

Code Maintainability

AMD resolves a significant number of issues that occur in JavaScript and HTML5 development projects through its employment of many best practices. JavaScript’s low initial barrier of entry to development often leads to the use of global variables, either intentionally or accidentally. Older versions of Dojo used namespaces, but these are verbose, have an impact on performance and require uniqueness. By following the AMD approach, your team will run into fewer issues and errors when developing.
Benefit = Efficient engineering

In larger projects and within larger organizations, it is common for different teams to build different portions of an application or library. AMD makes it much easier to share source code between projects and teams, create modules that are more easily reused by different initiatives, and merge work together, saving time and reducing redundant efforts.
Benefit = Efficient engineering

The AMD module format also encourages development of source code within an architecture that reduces overall development time. By providing developers with a solid model for writing clean, modular source code, fewer errors occur during development, improving time to market while increasing team efficiency.
Benefit = Efficient engineering

Using an AMD approach through feature detection, it is easier to create versions of your application that are optimized for mobile platforms and to remove legacy browser support for users of modern browsers. Additionally, the logic for such support is stored in an efficient manner making it easier to maintain, and eventually remove when support for legacy browsers is no longer required.
Benefit = Efficient engineering AND improved user experience.

Application Performance

AMD and its associated application optimization tools will lead to smaller source code for your applications, directly improving the performance of your applications. (Read more about the business benefits of improving performance) The result is a reduction in cost for bandwidth, faster page load times and an increase in both satisfied and engaged users. The asynchronous nature of AMD also makes it possible to load modules in parallel, further improving application performance.
Benefit = Efficient engineering AND improved user experience.

Because of improvements with AMD, a typical Dojo application is now 25-90% smaller in its code base, and load times of 5-10 times faster are not uncommon.

Interoperability

When I helped start the Dojo Toolkit, the vision was to create a collection of tools and libraries that would make developers more productive in creating web applications. It was never intended to be a battle between toolkit brands, or an attempt to force users to just use one toolkit and never find inspiration or useful modules from other sources. We’re big believers of having the freedom to choose options that are best for your project.

AMD helps prevent toolkit lock-in by making it far easier to mix and match modules between toolkits and makes it possible to use the dgrid module within a jQuery application or use some MooTools features within a Dojo application. It is still recommended to exercise caution when loading additional, full toolkits, as this creates some performance overhead. However, by making all of Dojo more modular, you will gain the benefits of microtoolkits while also receiving the benefits of having modules and tools that are tested together, in a manner that meets your expectations and the needs of your applications.
Benefit = Empowered Technical Leadership.

AMD has already been adopted by many large organizations including IBM, BBC, and Twitter, to name a few. We expect the list of major sites using AMD to grow exponentially this year.

Summary

Code maintainability, application performance, and interoperability provide the flexibility to create more dynamic applications. The cost benefits of AMD are driven through these technical and business benefits.

Most companies have one goal in common: Keep customers coming back and do it as efficiently as possible without sacrificing quality. AMD is aligned with this, and we’re excited to see this progress.

When you’re ready to explore your options for leveraging AMD in your web application architecture or if you just have questions about AMD, contact us. We’d be delighted to chat with you to see how SitePen can help your organization achieve the results that AMD provides.

Further Reading

• AMD: The Definitive Source
• Beyond Dojo: The Rise of AMD
• BBC adopting AMD as part of their responsive design efforts
• Twitter article on improving performance, including using AMD

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

As web applications continue to grow more advanced and more heavily rely on JavaScript, there has been a growing movement towards using modules to organize code and dependencies. Modules give us a way to make clearly distinguished components and interfaces that can easily be loaded and connected to dependencies. The AMD module system gives us the perfect path for using JavaScript modules to build web applications, with a simple format, asynchronous loading, and broad adoption.

The Asynchronous Module Definition (AMD) format is an API for defining reusable modules that can be used across different frameworks. AMD was developed to provide a way to define modules such that they could be loaded asynchronously using the native browser script element-based mechanism. The AMD API grew out of discussions in 2009 in the Dojo community which then moved to discussions with CommonJS on how to better adapt the CommonJS module format (used by NodeJS) for the browser. It has since grown into its own standard with its own community. AMD has taken off in popularity, with numerous module loaders and widespread usage. At SitePen we have worked extensively with AMD in Dojo, adding support and now actively building applications with this format.

Why AMD Modules?

The basic premise of a module system is to:

• allow the creation of encapsulated segments of code, called modules
• define dependencies on other modules
• define exported functionality that can in turn be used by other modules
• discreetly access the functionality provided by these modules

AMD satisfies this need, and uses a callback function with dependencies as arguments so that dependencies can be asynchronously loaded before the module code is executed. AMD also provides a plugin system for loading non-AMD resources.

While alternate methods can be used to load JavaScript (XHR + eval), using script elements to load JavaScript has an edge in performance, eases debugging (particularly on older browsers), and has cross-domain support. Thus AMD aims to provide an optimal development experience in the browser.

The AMD format provides several key benefits. First, it provides a compact declaration of dependencies. Dependencies are defined in a simple array of strings, making it easy to list numerous dependencies with little overhead.

AMD helps eliminate the need for globals. Each module defines dependencies and exports by referencing them with local variables or return objects. Consequently, modules can define functionality and interact with other modules without having to introduce any global variables. AMD is also “anonymous”, meaning that the module does not have to hard-code any references to its own path, the module name relies solely on its file name and directory path, greatly easing any refactoring efforts.

By coupling dependencies with local variables, AMD encourages high-performance coding practices. Without an AMD module loader, JavaScript code has traditionally relied on the nested objects to “namespace” functionality of a given script or module. With this approach, functions are typically accessed through a set of properties, resulting in a global variable lookup and numerous property lookups, adding extra overhead and slowing down the application. With dependencies matched to local variables, functions are typically accessed from a single local variable, which is extremely fast and can be highly optimized by JavaScript engines.

Using AMD

The foundational AMD API is the define() method which allows us to define a module and its dependencies. The API for writing modules consists of:

define(dependencyIds, function(dependency1, dependency2,...){
   // module code
});

The dependencyIds argument is an array of strings that indicates the dependencies to be loaded. These dependencies will be loaded and executed. Once they have all been executed, their export will be provided as the arguments to the callback function (the second argument to define()).

To demonstrate basic usage of AMD, here we could define a module that utilizes the dojo/query (CSS selector query) and dojo/on (event handling) modules:

define(["dojo/query", "dojo/on"],
        function(query, on){
    return {
        flashHeaderOnClick: function(button){
            on(button, "click", function(){
                query(".header").style("color", "red");
            });
        }
    };
});

Once dojo/query and dojo/on are loaded (which doesn’t happen until their dependencies are loaded, and so on), the callback function is called, with the query argument given the export of dojo/query (a function that does CSS selector querying), and the on argument given the export of dojo/on (a function that adds an event listener). The callback function (also known as the module factory function), is guaranteed to be called only once.

Each of the module ids listed in the set of dependencies is an abstract module path. It is abstract because it is translated to a real URL by the module loader. As you can see the module path does not need to include the “.js” suffix, this is automatically appended. When the module id starts with a name, this name is considered to be an absolute module id. In contrast, we can specify relative ids by starting with a “./” or a “../” to indicate a sibling path or parent path, respectively. These are resolved to their absolute module ids by standard path resolution rules. You can then define a module path rule to determine how these module paths are converted to URLs. By default, the module root path is defined relative to the parent of the module loader package. For example, if we loaded Dojo like (note that we set async to true to enable true async loading of AMD):

Then the root path to modules would be assumed to be “/path/to/”. If we specified a dependency of “my/module”, this would be resolve to “/path/to/my/module.js”.

Initial Module Loading

We have described how to create a simple module. However, we need an entry point to trigger the chain of dependencies. We can do this by using the require() API. The signature of this function is basically the same as define(), but is used to load dependencies without defining a module (when a module is defined, it is not executed until it is required by something else). We could load our application code like:

Dojo provides a shortcut for loading an initial module. The initial module can be loaded by specifying the module in the deps configuration option:

This is an excellent way of loading your application because JavaScript code can be completely eliminated in HTML, and only a single script tag is needed to bootstrap the rest of the application. This also makes it very easy to create aggressive builds that combine your application code and dojo.js code in a single file without having to alter the HTML script tags after the build. RequireJS and other module loaders have similar options for loading the top level modules.

The progression of dependency loading from the require() call to the modules is illustrated in the diagram above. The require() call kicks off the loading of the first module, and dependencies are loaded as needed. Modules that are not needed (“module-d” in the diagram) are never loaded or executed.

The require() function can also be used to configure the module path look-ups, and other options, but these are generally specific to the module loader, and more information on configuration details are available in each loader’s documentation.

Plugins and Dojo Optimizations

AMD also supports plugins for loading alternate resources. This is extremely valuable for loading non-AMD dependencies like HTML snippets and templates, CSS, and internationalized locale-specific resources. Plugins allow us to reference these non-AMD resources in the dependency list. The syntax for this is:

"plugin!resource-name"

A commonly used plugin is the dojo/text plugin which allows you to directly load a file as text. With this plugin, we list the target file as the resource name. This is frequently used by widgets to load their HTML template. For example, with Dojo we can create our own widget like this:

define(["dojo/_base/declare", "dijit/_WidgetBase", "dijit/_TemplatedMixin", "dojo/text!./templates/foo.html"],
        function(declare, _WidgetBase, _TemplatedMixin, template){
    return declare([_WidgetBase, _TemplatedMixin], {
        templateString: template
    });
});

This example is instructive on multiple levels for creating Dojo widgets. First, this represents the basic boilerplate for creating a widget using the Dijit infrastructure. You might also note how we created a widget class and returned it. The declare() (class constructor) was used without any namespace or class name. As AMD eliminates the need for namespaces, we no longer need to create global class names with declare(). This aligns with a general strategy in AMD modules of writing anonymous modules. Again, an anonymous module is one that does not have any hardcoded references to its own path or name within the module itself and we could easily rename this module or move it to a different path without having to alter any code inside the module. Using this approach is generally recommended, however if you will be using this widget with declarative markup, you will still need to include namespace/class names in order to create a namespaced global for Dojo’s parser to reference in Dojo 1.7. Improvements coming in Dojo 1.8 allow you to use module ids.

There are several other plugins that are included with Dojo that are useful. The dojo/i18n plugin is used to load internationalized locale-specific bundles (often used for translated text or regional formatting information). Another important plugin is dojo/domReady, which is recommended to be used as a replacement for dojo.ready. This plugin makes it very simple to write a module that also waits for the DOM to be ready, in addition to all other dependent modules, without having to include an extra callback level. We use dojo/domReady as a plugin, but no resource name is needed:

define(["dojo/query", "dojo/domReady!"],
        function(query){
   // DOM is ready, so we can query away
   query(".some-class").forEach(function(node){
       // do something with these nodes
   });
});

Another valuable plugin is dojo/has. This module is used to assist with feature detection, allowing you to choose different code paths based on the presence of certain browser features. While this module is often used as a standard module, providing a has() function to the module, it can also be used as a plugin. Using it as a plugin allows us to conditionally load dependencies based on a feature presence. The syntax for the dojo/has plugin is to use a ternary operator with conditions as feature names and module ids as values. For example, we could load a separate touch UI module if the browser supports touch (events) like:

define(["dojo/has!touch?ui/touch:ui/desktop"],
  function(ui){
    // ui will be ui/touch if touch is enabled,
    //and ui/desktop otherwise
    ui.start();
});

The ternary operators can be nested, and empty strings can be used to indicate no module should be loaded.

The benefit of using dojo/has is more than just a run-time API for feature detection. By using dojo/has, both in has() form in your code, as well as a dependency plugin, the build system can detect these feature branches. This means that we can easily create device or browser specific builds that are highly optimized for specific feature sets, simply by defining the expected features with the staticHasFeatures option in the build, and the code branches will automatically be handled correctly.

Data Modules

For modules that do not have any dependencies, and are simply defined as an object (like just data), one can use a single argument define() call, where the argument is the object. This is very simple and straightforward:

define({
    foo: "bar"
});

This is actually similar to JSONP, enabling script-based transmission of JSON data. But, AMD actually has an advantage over JSONP in that it does not require any URL parameters; the target can be a static file without any need for active code on the server to prefix the data with a parameterized callback function. However, this technique must be used with caution as well. Module loaders always cache the modules, so subsequent require()‘s for the same module id will yield the same cached data. This may or may not be an issue for your data retrieval needs.

Builds

AMD is designed to be easily parsed by build tools to create concatenated or combined sets of modules in a single file. Module systems provide a tremendous advantage in this area because build tools can automatically generate a single file based on the dependencies listed in the modules, without requiring manually written and updated lists of script files to be built. Builds dramatically reduce load time by reducing requests, and this is an easy step with AMD because the dependencies are specifically listed in the code.

Without build

With build

Performance

As noted before, using script element injection is faster than alternate methods because it relies more closely on native browser script loading mechanisms. We setup some tests on dojo.js in different modes, and script element loading was about 60-90% faster than using XHR with eval. In Chrome, with numerous small modules, each module was loaded in about 5-6ms, whereas XHR + eval was closer to 9-10ms per module. In Firefox, synchronous XHR was faster than asynchronous, and in IE asynchronous XHR was faster than synchronous, but script element loading is definitely the fastest. It is also surprising that IE9 was the fastest, but this is probably at least partly due to Firefox and Chrome’s debugger/inspector adding more overhead.

Module Loaders

The AMD API is open, and there are multiple AMD module loader and builder implementations that exist. Here are some key AMD loaders that are available:

• Dojo – This is a full AMD loader with plugins and a builder, and this is what we typically use since we utilize the rest of the Dojo toolkit.
• RequireJS – This is the original AMD loader and is the quintessential AMD loader. The author, James Burke, was the main author and advocate of AMD. This is full-featured and includes a builder.
• curl.js – This is a fast AMD loader with excellent plugin support (and its own library of plugins) and its own builder.
• lsjs – An AMD module loader specifically designed to cache modules in local storage. The author has also built an independent optimizer.
• NeedJS – A light AMD module loader.
• brequire – Another light AMD module loader.
• inject – This was created and is used by LinkedIn. This is a fast and light loader without plugin support.
• Almond – This is a lightweight version of RequireJS.

Getting AMD Modules

There is an increasing number of packages and modules that are available in AMD format. The Dojo Foundation packages site provides a central place to see a list of some of the packages that are available. The CPM installer can be used to install any of the packages (along with automatically installing the dependencies) that have been registered through the Dojo Foundation packages site.

Alternately, James Burke, the author of RequireJS has created Volo, a package installer that can be used to easily install packages directly from github. Naturally, you can also simply download modules directly from their project site (on github or otherwise) and organize your directory structure yourself.

With AMD, we can easily build applications with any package, not just Dojo modules. It is also generally fairly simple to convert plain scripts to AMD. You simply add a define() with an empty array, and enclose the script in the callback function. You can also add dependencies, if the script must be executed after other scripts. For example:

my-script.js:
// add this to top of the script
defined([], function(){
// existing script
...
// add this to the end of script
});

And we could build application components that pull modules from various sources:

require(["dgrid/Grid", "dojo/query", "my-script"], function(Grid, query){
    new Grid(config, query("#grid")[0]);
});

One caveat to be aware of when converting scripts to modules is that if the script has top level functions or variables, these would ordinarily result in globals, but inside of a define() callback they would be local to the callback function, and no globals will be created. You can either alter the code to explicitly create a global (remove the var or function prefix (you would probably want to do this if you need the script to continue working with other scripts that rely on the globals that it produces), or alter the module to return the functions or values as exports and arrange the dependent modules to use those exports (rather than the globals, this allows you to pursue the global-free paradigm of AMD).

Directly Loading Non-AMD Scripts

Most module loaders also support direct loading of non-AMD scripts. We can include a plain script in our dependencies, and denote that they are not AMD by suffixing them with “.js” or providing an absolute URL or a URL that starts with a slash. The loaded script will not be able to provide any direct AMD exports, but must provide its functionality through the standard means of creating global variables or functions. For example, we could load Dojo and jQuery:

require(["dojo", "jquery.js"], function(dojo){ // jquery will be loaded as plain script
    dojo.query(...); // the dojo exports will be available in the "dojo" local variable
    $(...);   // the other script will need to create globals
});

Keep It Small

AMD makes it easy to coordinate and combine multiple libraries. However, while it may be convenient to do this, you should exercise some caution. Combining libraries like Dojo and jQuery may function properly, but it adds a lot of extra superfluous bytes to download since Dojo and jQuery have mostly overlapping functionality. In fact, a key part of Dojo’s new module strategy is to avoid any downloading of unnecessary code. Along with converting to AMD, the Dojo base functionality has been split into various modules that can be individually used, making it possible to use the minimal subset of Dojo that is needed for a given application. In fact, modern Dojo application and component development (like dgrid) often can lead to an entire application that is smaller than earlier versions of Dojo base by itself.

AMD Objections

There have been a few objections raised to AMD. One objection is that using the original CommonJS format, from which AMD is somewhat derived, is simpler, more concise, and less error prone. The CommonJS format does indeed have less ceremony. However, there are some challenges with this format. We can choose to leave the source files unaltered and directly delivered to the browser. This requires the module loader to wrap the code with a header that injects the necessary CommonJS variables, and thus relies on XHR and eval. The disadvantages of this approach have already been discussed, and include slower performance, difficult with debugging on older browsers, and cross-domain restrictions. Alternately, one can have a real-time build process, or on-request wrapping mechanism on the server, that essentially wraps the CommonJS module with the necessary wrapper, which actually can conform to AMD. These approaches are not necessarily showstoppers in many situations, and can be very legitimate development approaches. But to satisfy the broadest range of users, where users may be working on a very simple web server, or dealing with cross-browser, or older browsers, AMD decreases the chance of any of these issues becoming an obstacle for the widest range of users, a key goal of Dojo.

The dependency listing mechanism in AMD specifically has been criticized as being error prone because there are two separate lists (the list of dependencies and the callback arguments that define the variables assigned the dependencies) that must be maintained and kept in sync. If these lists become out of sync the module references are completely wrong. In practice, we haven’t experienced much difficulty with this issue, but there is an alternate way of using AMD that addresses this issue. AMD supports calling define() with a single callback argument where the factory function contains require() calls rather than a dependency list. This actually can not only help mitigate dependency list synchronization issues, but also can make it extremely easy to add CommonJS wrappers, since the factory function’s body essentially conforms to the CommonJS module format. Here is an example of how to define a module with this approach:

define(function(require){
    var query = require("dojo/query");
    var on = require("dojo/on");
    ...
});

When a single argument is provided, require, exports and module are automatically provided to the factory. The AMD module loader will scan the factory function for require calls, and automatically load them prior to running the factory function. Because the require calls are directly inline with the variable assignment, I could easily delete one of the dependency declarations without any further need to synchronize lists.

A quick note about the require() API: When require() is called with a single string it is executed synchronously, but when called with an array it is executed asynchronously. The dependent modules in this example are still loaded asynchronously, prior to executing the callback function, at which time dependencies are in memory, and the single string require calls in the code can be executed synchronously without issue or blocking.

Limitations

AMD gives us an important level of interoperability of module loading. However, AMD is just a module definition, it does not make any prescriptions on the API’s that the module create. For example, one can’t simply ask the module loader for a query engine and expect to return the functionality from interchangeable query modules with a single universal API. There may be benefit to defining such APIs for better module interchange, but that is beyond the scope of AMD. And most module loaders do support mapping module ids to different paths, so it would be very feasible to map a generic module id to different target paths if you had interchangeable modules.

Progressive Loading

The biggest issue that we have seen with AMD is not so much a problem with the API, but in practice there seems to be an overwhelming tendency to declare all dependencies up front (and that is all we have described so far in this post, so we are just as guilty!). However, many modules can operate correctly while deferring the loading of certain dependencies until they are actually needed. Using a deferred loading strategy can be very valuable for providing a progressively loaded page. With a progressive loading page, components can be displayed as each one is downloaded, rather than forcing the download of every byte of JavaScript before the page is rendered and usable. We can code our modules in a way to defer loading of certain modules by using the asynchronous require([]) API in the code. In this example, we only load the necessary code for this function to create children container nodes for immediate visual interaction, but then defer the loading of the widgets that go inside the containers:

// declare modules that we need up front
define(["dojo/dom-create", "require"],
        function(domCreate, require){
    return function(node){
       // create container elements for our widget right away,
       // these could be styled for the right width and height,
       // and even contain a spinner to indicate the widgets are loading
       var slider = domCreate("div", {className:"slider"}, node);
       var progress = domCreate("div", {className:"progress"}, node);
       // now load the widgets, we load them independently
       // so each one can be rendered as it downloads
       require(["dijit/form/HorizontalSlider"], function(Slider){
          new Slider({}, slider);
       });
       require(["dijit/Progress"], function(Progress){
          new Progress({}, progress);
       });
    }
});

This provides an excellent user experience because they interact with components as they become available, rather than having to wait for the entire application to load. Users are also more likely to feel like an application is fast and responsive if they can see the page progressively rendering.

require, exports

In the example above, we use a special dependency “require”, which give us a reference to a module-local require() function, allowing us to use a module reference relative to the current module (if you use the global “require”, relative module ids won’t be relative to the current module).

Another special dependency is “exports”. With exports, rather than returning the exported functionality, the export object is provided in the arguments, and the module can add properties to the exports object. This is particularly useful with modules that have circular references because the module factory function can start running, and add exports, and another function utilize the factory’s export before it is finished. A simple example of using “exports” in a circular reference:

main.js:
define(["component", "exports"],
        function(component, exports){
    // we define our exported values on the exports
    // which may be used before this factory is called
    exports.config = {
       title: "test"
    };
    exports.start = function(){
        new component.Widget();
    };
});
component.js:
define(["main", "exports", "dojo/_base/declare"],
        function(main, exports, declare){
    // again, we define our exported values on the exports
    // which may be used before this factory is called
    exports.Widget = declare({
        showTitle: function(){
            alert(main.config.title);
        }
    });
});

This example would not function properly if we simply relied on the return value, because one factory function in the circular loop needs to execute first, and wouldn’t be able to access the return value from the other module.

As shown in one of the earlier examples, if the dependency list is omitted, the dependencies are assumed to be “require” and “exports”, and the require() calls will be scanned, so this example could be written:

define(function(require, exports){
    var query = require("dojo/query");
    exports.myFunction = function(){
       ....
    };
});

Looking Forward

The EcmaScript committee has been working on adding native module support in JavaScript. The proposed addition is based on new syntax in the JavaScript language for defining and referencing modules. The new syntax includes a module keyword for defining modules in scripts, an export keyword defining exports, and an import keyword for defining the module properties to be imported. These operators have fairly straightforward mappings to AMD, making it likely that conversion will be relatively simple. Here is an example of how this might look based upon the current proposed examples in EcmaScript Harmony, if we were to adapt the first example in this post to Harmony’s module system.

import {query} from "dojo/query.js";
import {on} from "dojo/on.js";
export function flashHeaderOnClick(button){
    on(button, "click", function(){
       query(".header").style("color", "red");
    });
}

The proposed new module system includes support for custom module loaders that can interact with the new module system, which may also still be used to retain certain existing AMD features like plugins for non-JavaScript resources.

Conclusion

AMD provides a powerful module system for browser-based web applications, leveraging native browser loading for fast asynchronous loading, supporting plugins for flexible usage of heterogeneous resources, and utilizing a simple, straightforward format. With great AMD projects like Dojo, RequireJS, and others, the world of AMD is an exciting and growing opportunity for fast, interoperable JavaScript modules.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

dojo/request

We’re very excited about this release for many reasons. For the new features, I’m most excited about the work led by Bryan Forbes with dojo/request. This is the third major iteration of how Dojo works with Ajax. The first ever Dojo release, dojo.io.bind, was completed at SXSW in 2005, prior to even our 0.1 release. The second major release, dojo.xhr, was an excellent and performant rethink around Ajax. A lot has changed over the past few years, with the introduction of XHR 2, with our support for Dojo inside Node.js, and a strong desire to create a solid, simple, clean, and highly flexible API for the feature that brought JavaScript into the forefront of web application development in 2004. In 1.8, you can still use dojo.xhr (or dojo/_base/xhr with AMD), as it wraps dojo/request. We’ll have an in-depth post about dojo/request next week.

Without further ado, here are 18 things to look forward to in Dojo 1.8:

New Features:

1.  dojo/request, making Ajax far more flexible and powerful, and works inside Node.js
2.  dojo/router, a new component for routing to different client-side “pages”
3.  dojox/Calendar, a feature rich calendar widget
4.  dojox/dgauges, a framework to easily create your own gauges
5.  dojox/treemap, a data visualization widget
6.  dojox/mobile, 28 new mobile widgets including audio, video, grid layout, tree view, and more

Significant Improvements:

7.  Automatic and declarative require, making it easier to work with AMD for features defined in markup
8.  dojo/promise was rewritten, making promises and deferreds easier to use and track
9.  dojox/mvc was rewritten, along with a new ToDo demo application
10.  The API documentation and viewer, and Dojo reference guide are vastly improved for 1.8. For many users, this will be the most welcome change with Dojo 1.8.
11.  DnD on mobile platforms
12.  Canvas and SVG specific enhancements to GFX, adding significant capabilities

Noteworthy Enhancements:

13.  General AMD refinements to improve performance and optimize modules throughout the toolkit
14.  Dijit Select and Tree now connect directly with Dojo Object Store API
15.  Claro’s gradients are easier to customize through CSS rather than images for non-IE browsers
16.  CometD and Lightstreamer integrations are updated to AMD, and should be downloaded from their projects
17.  General performance improvements to many widgets and to Dojo Charts
18.  A mobile migration assistant from 1.6 or 1.7 to 1.8, to make it easy to migrate through the many mobile improvements

More Information

Keep following SitePen on your favorite social network for more Dojo 1.8 updates! We’ll be blogging regularly between now and the release of Dojo 1.8 to tell you more.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

What does dgrid mean to Dojo?

dgrid has come to represent and demonstrate the future and power of third-party packages for Dojo. The dgrid package helps to jump-start the repository-centric approach, with parts of DojoX expected to eventually follow suit. It also demonstrates extensive use of the new features and architecture in 1.7 — including granular dependencies, and the new event mechanism in dojo/on — showing how components can use Dojo 1.7 to create amazingly compact and fast user interfaces.

dgrid has also pointed forward to lighter-weight approaches to widget design, more CSS-centric techniques for styling, better separation of structural and skinning styles, and other innovative techniques that have sparked interest into new ways of working with and on Dojo.

Because dgrid builds upon Dojo under the same licensing, you get all of this innovation while preserving Dojo’s clean intellectual property, simple integration with other features, high performance, and professional engineering, taking advantage of the many things that make Dojo excellent.

Why another grid? What about the DojoX Grid and its subclasses (EnhancedGrid, TreeGrid, etc.)?

While the DojoX Grid was cutting edge for its time (initially released as the TurboAjax Grid for Dojo 0.4 in 2006, then converted for and released with Dojo 1.0 in late 2007), browsers have evolved rapidly since then. In fact, Chrome didn’t exist until a year after the DojoX Grid was released. Developers were required to support browsers that greatly limited what could be accomplished on the web.

At the time, innerHTML was often far and away the fastest way to generate a DOM structure; IE6′s DOM methods were (and still are) quite slow. Because of this and the fact that a de facto asynchronous data model for Dojo had not been conceived when the original TurboAjax Grid was written, the DojoX Grid uses a synchronous data rendering model. Although DataGrid does use dojo.data stores, it was implemented as an afterthought, requiring rows to be rendered at least twice for each page of data. In addition, any updates to rows such as row selection, mouseover effects, and data updates caused a row to be completely re-rendered using innerHTML. Using innerHTML also meant that if a developer wanted to change how a row rendered beyond adding CSS classes or inline styles, he or she would need to rewrite significant portions of the string generation methods internal to the DojoX Grid rather than simply modify a DOM node or child nodes.

This reliance on string generation made the DojoX Grid extremely monolithic: because it was so hard to extend, it came with a large number of features built in. Some of the features could be turned off (such as selection and column reordering) or simply not used (sets of columns and sub rows), but the code adding those features to the Grid could not be removed for a lighter build. The developer had access to all of the features of the Grid all of the time, whether he or she wanted them or not.

Because of the nature of rendering using innerHTML using strings and the monolithic approach of the DojoX Grid, extending it meant rewriting large portions of the rendering code to accomplish what you wanted. TreeGrid and EnhancedGrid came along to add trees and other features such as a plugin system, also as afterthoughts. While these new classes added features to the Grid, they were forced to do so via the limited and brittle extension points the Grid already exposed, which meant the new features were brittle as well. At the same time, these new features were only adding to the already large code-base and heavy rendering routines of the Grid.

What was done to avoid those pain points in dgrid?

From the start, dgrid was designed to take advantage of the new asynchronous loader in Dojo 1.7 with granular dependencies; this means it only loads the parts of Dojo that it needs. The “only use what you need” philosophy was very prevalent from the start and led to a very modular (rather than monolithic) design. For instance, if you only need a list of items with no notion of columns at all, the List module alone will give you that.

require(["dgrid/List", "dojo/dom"], function(List, dom){
    var list = new List({
        ...
    }, dom.byId("list"));
});

If your list has hundreds of items in it, you may want to use OnDemandList to fetch and render items from a store as the user scrolls.

require(["dgrid/OnDemandList", "dojo/dom"], function(List, dom){
    var list = new List({
        ...
    }, dom.byId("list"));
});

Adding row selection, cell selection, or keyboard navigation is as simple as mixing in an object that you explicitly require, meaning you only pay for the features you truly need.

require([
    "dojo/_base/declare",
    "dgrid/OnDemandList",
    "dgrid/Selection",
    "dgrid/Keyboard",
    "dojo/dom"
], function(declare, List, Selection, Keyboard, dom){
    var MyList = declare([List, Selection, Keyboard]);
    var list = new MyList({
        ...
    }, dom.byId("list"));
});

With regards to rendering, dgrid was designed to fully rely on DOM-based element creation and manipulation. This gives dgrid the advantage of simple and familiar DOM manipulation when adding or extending features, rather than needing to entirely rewrite portions of the UI using innerHTML.

Events are another area where dgrid greatly improves upon the DojoX Grid components, and furthers the “only pay for what you need” mantra. The dojo/on module, new to Dojo 1.7, can be exercised to its full potential to delegate handlers for only the events that are actually of interest in a particular situation.

dgrid components access data in one of two ways: by passing an array of items to render to the renderArray method, or by providing a store conforming to the Dojo Store API (introduced in Dojo 1.6). Asynchronous data handling was one of the primary concerns of dgrid from the beginning; as a result, it has been designed to natively handle both synchronous and asynchronous data sources.

require([
    "dgrid/OnDemandList",
    "dojo/store/Memory",
    "dojo/dom"
], function(OnDemandList, Memory, dom){
    var dataList = new OnDemandList({
        ...
    });
    dataList.renderArray([ { name: "foo" } ]);

    var storeList = new OnDemandList({
        store: new Memory({
            data: [ { name: "foo" } ]
        })
    });
});

Other key advantages of dgrid include:

• focus on more maintainable stylesheet-based styling rather than inline styles
• support for mobile devices
• accessibility (a11y)
• robust set of features provided via mixins and plugins (tree, editor, drag and drop, pagination, and more)

It is important to note that dgrid is built to leverage the latest and greatest developments in Dojo, and thus requires Dojo version 1.7.

Similarities to DojoX grids

With the release of the dgrid Beta, now seems an apt time to compare dgrid to the DojoX grids to see what a developer might gain by switching to dgrid.

Firstly, while dgrid and the DojoX grids take different approaches to some things, they do share many similar features in common. The following features are supported by both dgrid and DojoX grids:

• display, sort, select, and edit in-place thousands of rows of data
• instantiate and configure via markup
• directly or indirectly select rows or cells
• reorder displayed columns using drag and drop
• virtual paging (progressive loading during scrolling)
• accessibility
• internationalization

Differences from DojoX grids

Even with all of these similar features, there are some key areas where dgrid outshines and outperforms the DojoX grids.

Data Handling

DojoX grids all support the Dojo Data API. While this API gives a unified data access pattern, it requires that all property access go through the store which adds extra function calls to an application. In addition, all data fetching was handled through callbacks (including synchronous fetches).

dgrid supports the Dojo Store API. Although it is yet another unified data API, it has some advantages over Dojo Data. First, property access is done as a simple property access on items; this means expensive function calls are not needed to access properties of an item. Second, data fetching routines can return either an immediate object or a promise (or Deferred), depending on whether the operation is synchronous or asynchronous; both of these cases can be handled identically by Dojo’s when function. Third, several store implementations are provided out of the box in Dojo, and moreover, custom implementations are easy to create.

Additionally, dgrid instances have a renderArray method which takes an array of objects and renders them. This can be a very quick way to render a small amount of data without the overhead of instantiating a store.

Drag and Drop

Before the EnhancedGrid, setting up drag and drop for rows in the DojoX grids was an arduous task. Even still, using EnhancedGrid simply for row drag and drop will add a large amount of code on top of DataGrid that may not be needed for a simple list.

dgrid takes a simpler approach: If row drag and drop is needed, simply mix dgrid/extensions/DnD into your dgrid instance constructor and a dojo/dnd/Source will be set up for each instance of the grid. From there, a developer can use the dojo/dnd API to set up drag and drop interaction. This works for both dgrid/List and dgrid/Grid equally: no large subclass of a dgrid class or plugin architecture is needed to use row drag and drop.

Hierarchical Data

One of the most demanded features of the DojoX grid has been hierarchical data display. Out of the box, the base grid provided in DojoX does not support displaying data in a tree; in fact, up until Dojo 1.4, the only way to display a tree-like structure was to use a grid within a grid. Once TreeGrid was introduced, a developer had to switch his or her code to use that constructor while also setting up a hierarchical grid layout. Additionally, a TreeStoreModel was required alongside the store. Since TreeGrid itself extends DataGrid, this means even more code needed to be pulled in for the application, and usage of TreeGrid could prove awkward, especially once any customization was necessary.

Out of the box, dgrid comes with the dgrid/tree column decorator. This means any dgrid instance can display hierarchical data; a developer simply needs to implement the getChildren and mayHaveChildren methods on the store, rather than use a TreeStoreModel.

Pagination

While all of the DojoX grids support virtual paging (progressive rendering of rows as the user scrolls), only EnhancedGrid supports traditional paging (navigating pages of data using buttons). However, all dgrid instances can mix in dgrid/extensions/Pagination to give the user a traditional paging model.

Mobile

None of the DojoX grids have mobile support. In contrast, dgrid was built from the ground up as a mobile-ready widget and supports mobile platforms out of the box.

Conclusion

As you can see, dgrid offers better support out of the box for a variety of features while still keeping your application light. Most features are opt-in and thus only add weight to your application if you specifically include them. By contrast, almost all features of the DojoX grid require a specialized subclass of _Grid which can add features which you may not need in your application.

Be sure to check out our dgrid tutorials to get started with dgrid. If you’d like to migrate your application from the DojoX grids to dgrid, be sure to have a look at the API comparison and usage comparison migration documents.

And as always, SitePen can help you with your migration through either our support services or our development services.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

You are not alone, brave developer. We feel your pain – the type that results from banging your head on a keyboard until the room spins – and that is why we have an amazing gift for you! Read on…

Dojo users and SitePen customers alike have needed a grid since the Dojo Toolkit project began. At first, we and several other companies banded together to purchase a non-open source grid. Enter Dojo DataGrid. We contributed our shiny new code to the Dojo Toolkit for the benefit of everyone and we’ve spent years maintaining and incrementally improving it in Dojo. But the web evolved, faster and faster, demanding more functionality, more performance, and more data! Others tried to keep up as well, enter EnhancedGrid and LazyTreeGrid. Kudos to everyone for building and contributing to Dojo!

Finally, last year, we took a long, hard look at how our customers were using DataGrid and EnhancedGrid. We agonized over the time and effort spent developing and maintaining such crucial functionality. We knew something needed to change. Enough was enough! Our choice was to attempt a DataGrid refactor or start over. The SitePen Team spoke: We started over.

To date, we’ve invested thousands of hours in developing the new dgrid, a grid that goes beyond any other, enabling developers to make awesome things faster than ever.

So, without further ado, we’re delighted to announce that dgrid, a new JavaScript component for creating advanced, high performance data grids, is now in Beta!

Alpha, Beta, and beyond

The Alpha release of dgrid represented a baseline which gave a fair indication of its design direction, as well as the types of features it intended to support. While some modules were in an unfinished or rough state, it was possible to demonstrate and harness their abilities, and we were thrilled to hear from several early adopters who shared some early success stories and feedback.

This Beta release represents the culmination of months of work by the SitePen team to fix bugs and work toward a stable API release. While many companies and individuals have already successfully used alpha versions of dgrid in their production applications, dgrid beta represents the first release of dgrid we know to be feature-complete and API-stable for regular use.

Beyond Beta, we’re on the path to greatness, most notably finishing work on keyboard accessibility and improving mobile compatibility. Mobile compatibility, in particular, will be a continued focus for development as the mobile landscape continues to evolve.

Usability, Portability, Compatibility

We’ve designed dgrid with your needs in mind. First of all, because dgrid is a completely portable AMD package, any application written with AMD can use dgrid—even if the rest of the application isn’t using Dojo!

As for compatibility, we’re currently targeting the following desktop browsers:

• Firefox ESR and latest release (currently 10 and 11, respectively)
• Chrome stable (currently 17)
• Internet Explorer 6-9
• Safari 5.1
• Opera 11.61

And the following mobile platforms…

• iOS 4.3 and 5
• Android 2.3 and 4.0

dgrid’s Modular Features

dgrid’s extremely modular design helps to ensure that core functionality can be easily modified and that extremely small, lightweight grids can be created with minimal effort. Whereas grid modules like DojoX DataGrid are at least 55KB in compressed size, dgrid starts at just 12KB! Additionally, dgrid includes a huge number of modular features out-of-the-box, rivaling or exceeding nearly every other grid component currently available:

• Keyboard navigation & ARIA role support for accessibility
• i18n support
• Asynchronous data retrieval & row rendering
• Row & column drag’n'drop
• jQuery ThemeRoller theme support
• Native dojo/store API support
• Automatic updates with Observable stores
• Inline cell editors, including support for Dijit form widgets as editors
• Unlimited-depth tree support
• Support for multiple independent column sets
• Support for records rendered to multiple rows
• Support for custom formatting functions for cell contents
• A complete row selection engine, including multi-row and indirect (checkbox-based) selection
• Licensed using the same CLA & open-source licensing as the Dojo Toolkit
• ColumnHider: Shows and hides columns via a simple menu (Beta Feature!)
• ColumnReorder: Reorders columns in simple layouts using drag’n'drop (Beta Feature!)
• DijitRegistry: Enables integration with the Dijit registry and other Dijit layout widgets (Beta Feature!)
• Virtual & traditional paging options
• Pagination: A UI component that changes the behavior of the grid to with discrete pages rather than virtual scrolling (Beta Feature!)

dgrid, Where have you been all my life?

We really wanted to make sure you didn’t miss out on this extraordinary opportunity to simplify and improve your ongoing development efforts and application performance. We knew we need to illustrate how dgrid can be used to create amazing experiences with a minimum amount of effort and convince you that this was the way to go! So, here’s what we did:

First, we documented the heck out of our code and put in on Github. THEN, we wrote some tests and demos and THEN we created some handy tutorials AND THEN, we gathered everything up, organized it to the nines and put it right here:
http://dgrid.io/

Development & Support – We’ve got your back

Wow! Thanks for reading this far! You must be seriously over your current grid fiasco!

We’re working hard with our customers to replace their massive grid implementations with dgrid and we can do the same for your application! Call us today to get on the schedule to receive a full grid migration effort or sign up for one of our valuable SitePen Support plans to keep your developers productive and informed!

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!