Blog

Jul 10

AMD for the Business-Side

By Dylan Schiemann on July 10, 2012 8:36 am

You may have seen our recent blog entitled “AMD: The Definitive Source” which exhaustively explained Asynchronous Module Definition. AMD is a topic with significant technical nuances but the purpose of THIS article is to explain the value of AMD for your business.

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!

Continue reading1 Comment
Jun 25

AMD: The Definitive Source

By Kris Zyp on June 25, 2012 2:29 pm

So what is AMD?

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.

Continue reading12 Comments
Sep 30

Run-Anywhere JavaScript Modules Boilerplate Code

By Kris Zyp on September 30, 2010 4:53 am
This entry is part 6 of 12 in the series Server-Side JavaScript, Pintura, and Persevere 2.0

For developers that are creating libraries and modules, it is generally preferable to make your code available to as broad of range of users as possible. There are several different module formats in JavaScript (a module is an encapsulation of code that draws on other modules). Picking one format is often mutually exclusive to the other formats. However, in this post I want to demonstrate how you can write JavaScript modules that can be used with multiple module loaders using some simple boilerplate. Of course not all the module loaders necessarily make sense for all modules. If you are writing a module that relies on the Node file system API, it only needs it to work with the NodeJS/CommonJS module format. Likewise, a DOM-based module wouldn’t need to run on Node.

Here we’ll deal with the actual module format, the mechanism of specifying dependencies and exporting or returning functions from the module that can be used by the users. This does not deal with the normalization of the actual APIs of the underlying system, although you might want to take a look at promised-io if you would like normalization of IO interaction across the browser, Node, and Rhino/Narwhal.

Continue reading6 Comments

Featured articles

Search the blog

Dojo Toolkit workshops