AMD (No, not the chip maker) stands for Asynchronous Module Definition – a cool new way of loading scripts. AMD attempts to solve some of the limitations associated with the orthodox approach of loading scripts. The usual approach is to load script files based on their dependencies (e.g. files depending on jQuery have to be specified after the jQuery source file is included).
Browsers, however, load script files synchronously (see image below) and a project having a large number of scripts will take more time to load; clearly, this approach will not scale with project size. Furthermore, subtle dependencies in pre-ordered scripts might cause weird bugs and writing unit tests will be difficult. To add salt to injury, manually adding script tags to files is simultaneously boring and error-prone.
The other obvious alternative would be to have a single script file containing all the source code for the project. While this might be a good idea for production, you’ll agree with me that having a single 200kline file in development bodes no good.
AMD to the Rescue!
Most languages have embedded code organization constructs – such as Java’s famous import and package.
AMD allows developers to define modules and their dependencies so that everything can be asynchronously loaded and resolved. The benefits of this approach include improved performance and load times, decoupling of concerns, easier testing and the restoration of sanity to huge web projects.
AMD allows the bypassing of global variable usage too; since module dependencies are passed as parameters to the factory function. By wrapping the main AMD definition in an IIFE (Immediately Invoked Function Expressions, pronounced iffy), it is possible to avoid polluting global scope. Refactoring has never been easier, all that needs to be changed is the offending file.
How It works?
The AMD style requires you to define each module discretely (quite similar to the Java style of standalone class files). While this might be overkill for small projects, some form of code organization is a MUST for medium-to-large projects to avoid getting stuck in a tarpit of code.
I am currently using a MVC framework for front end development coupled with requireJS (a popular AMD loader). This means that each controller, template, view and route is defined in a separate file; the benefits of this are obvious – navigating through code is easier and ripple effects are minimized.
However, there is performance tradeoff: loading 20+ files instead of one file is terribly inefficient; in my case, it takes about 1-3s for everything to load (which is almost a sacrilege in web dev). The good news is that there are optimizers that compress and obfuscate the code, they give you that single file.
What is the future of AMD?
AMD might be overkill for small projects but as web applications continue to evolve, it should become a mainstay – the upcoming ECMAScript 6 (i.e. Harmony) will support modules. I believe it is pretty cool and it is worth learning if you are a web developer.
No processors were hurt in the production of this piece (well, mine was subjected to some work though). :D