I do have a number of issues with AMD. But I think it's also fair to point out "the good parts".
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
and (my own)
My focus has been on just the raw
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".
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.
Thanks for all your hard work James!
the async support
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
module variables used in the body of a module.
These general definitions are also applicable, with some differences, in
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
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
do this, AMD specifies that you wrap the body of your module in
a specific type of function wrapper when you author it.
be loaded directly with a
<script src=> element in your HTML
file, or via
<script src=> elements injected into your live web page
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.
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.
And it seems like most AMD implementations provide a mechanism to do this.