Based my blog post yesterday "More on why AMD is Not the Answer", you might guess I'm an AMD-hater. I strive to not be negative, but sometimes I fail. Mea culpa.
I do have a number of issues with AMD. But I think it's also fair to point out "the good parts".
my background
I've only really played with a few AMD
libraries/runtimes. I've been more fiddling around with ways of
taking node/CommonJS-style modules, and making them
consumable by AMD runtimes. The AMD runtimes I've played with
the most are
almond
and (my own)
modjewel.
My focus has been on just the raw require() and define()
functions.
But I follow a lot of the AMD chatter around the web, and have done at least reading and perusing through other AMD implementations. To find implementations of AMD, look at this list and search for "async". The ones I hear the most about are require.js, Dojo, PINF, and curl.
And now, "the good parts".
the code
Browsing the source repositories and web sites, you'll note that folks have spent a lot of time on the libraries - the code itself, documentation, test suites, support, etc. Great jobs, all. I know a lot of these libraries have been battle-tested by folks in positions to do pretty good battle-testing with them.
the evangelism
Special mention here to James Burke (not this one), who has done a spectacular job leading and evangelizing the AMD cause, both within the "JavaScript Module" community, and outside. In particular, he's been trying to get AMD support into popular libraries like jQuery, backbone, underscore and node.js. Sometimes with success, sometimes not. James has been cool and collected when dealing with jerks like me, pestering him with complaints, questions, requests and bug reports. Some open source communities can be cold and bitter places, but the AMD community is not one of those, and I'm sure that's in part due to James.
Thanks for all your hard work James!
the async support
AMD is an acronym for Asynchronous Module Definition. That first word, Asynchronous, is key. For the most part, if you're using JavaScript, you're living in a world of single-threaded processing, where long-running functions are implemented as asynchronous calls that take callback functions as arguments. It makes sense, at least in some cases, to extend this to the function of loading JavaScript code.
If you need to load JavaScript in an async fashion, AMD is designed for you, and uses existing async function patterns that JavaScript programmers should already be familiar with.
support for CommonJS
This is a touchy subject, because when you ask 10 people what "CommonJS" is,
you'll get 15 different answers. For the purposes here, and really whenever
I use the phrase "CommonJS", I'm technically referring to
one of the Modules/1.x specifications,
and more specifically, the general definitions of the require() function
and the exports and module variables used in the body of a module.
These general definitions are also applicable, with some differences, in
node.js.
When I use the phrase "CommonJS", I am NEVER referring to the other specifications in the CommonJS specs stable (linked to above).
AMD supports this general definition of "CommonJS", in my book. Super double plus one good!
Aside: I'm looking for another 'name' to call my simplistic notion
of CommonJS. So far, things like simple require()y support,
seem to capture my intent. But you know how
bad I am with naming.
the design for quick edit-debug cycles
One of the goals of AMD is to facilitate a quick
edit-debug cycle while you are working on your JavaScript. To
do this, AMD specifies that you wrap the body of your module in
a specific type of function wrapper when you author it.
Because of the way it's designed, these JavaScript files can
be loaded directly with a <script src=> element in your HTML
file, or via <script src=> elements injected into your live web page
dynamically, by a library. This means that as soon as you save the JavaScript you're
editing in your text editor/IDE, you can refresh the page in
your browser without an intervening "build step" or special
server processing - the same files you are editing are loaded
directly in the browser.
the resources
Beyond just loading JavaScript code, AMD supports the notion of loading other things. The things you can load are determined by what Loader Plugins you have available. Examples include:
Coming from the Java world, this is familiar territory; see: Class.getResource*() methods. For the most part, I consider this to be amongst the core bits of functionality that a programming library should provide. It's a common pattern to ship data with your code, and you need some way to access it. And, of course, this resource loading is available in an async manner with AMD.
Aside: I'm not sure what the analog of this is in the node.js world. You can certainly do it by hand, making use of the __dirname global, and then performing i/o yourself. I'm just not sure if someone has wrapped this up nicely in a library yet.
the build
At the end of the day, hopefully, your web application is going to be available to some audience, who will be using it for realz. It's unlikely that you will want to continue to load your JavaScript code (and resources) as individual pieces as you do in development; instead, you'll want to concatenate and minimize your wads of goo to keep load time to a minimum for your customers.
And it seems like most AMD implementations provide a mechanism to do this.
