unscriptable.com

Closures for Dummies (or why IIFE !== closure)

John Hann — Sun, 02 Oct 2011 21:31:47 +0000

There are lots of blog posts and online articles about javascript closures. Many of them are well written. Closures have also been discussed at length with Brendan Eich. I really shouldn’t have to write another blog post. Yet, here I am.

Why? Because I still see many people misusing the term, “closure”. Specifically, I see people confusing IIFEs with closures.

I was going to see if I could craft a twitter-friendly 140-char explanation of the differences between IIFEs and closures. A noble cause, for sure, especially since I suspect that the reason that there’s so much confusion is that many of the explanations are either tl;dr or too technical.

140 characters may have been too ambitious. Let’s see if I can do it in 140 words or less. Starting… now. Well, not including code snippets, mmkay? OK. Starting… now.

[update 2011-10-04] Turns out I am wrong! Who would have guessed that??!?! I’ll post an update shortly to explain that my definition of closures is slightly off. However, the message I want to convey is still the same: closures don’t matter except under specific circumstances.

Definitions

A closure is what happens when you’ve made a function’s private variables (and/or embedded functions) available to outside code. That’s it. There’s no specific pattern you need to use, it just happens. That said, there are lots of patterns that take advantage of closures.

IIFEs are simply a way to create a private set of variables and functions. You create an IIFE by constructing a function expression that contains some private variables and/or embedded functions — and then executing it. Immediately. Most meaningful IIFEs create a closure, but they don’t have to.

Stop. Not bad. Only four tweets-worth.

Examples

Let’s take a look at a few examples.

// safeSnapshot returns a function that filters out 
// embarrassing tweets. tweets are only filtered
// when needed, potentially saving cpu time if they 
// are never needed.
function safeSnapshot (tweets) {
    var snapshot = tweets.slice(0); // shallow copy
    return function () {
        var safelist = [];
        for (var i = 0, len = snapshot.length; i < len; i++) {
            if (snapshot[i].text.indexOf('#poopin') < 0) {
                safelist.push(snapshot[i]);
            }
        }
        return safelist;
    };
}
 
// ... later in the code, we give an object (tweetConsumer) 
// a handle to a function that it may use to get tweets 
// (via its tweetFetcher property).
// It may or may not ever call this function, but it has it in
// advance.  (Use your imagination to dream up a reason
// this could be useful.  There are many.)
// allTheTweets is just an array of tweets we got from 
// somewhere else. (Again, use your imagination. I know
// you have one.)
tweetConsumer.tweetFetcher = safeSnapshot(allTheTweets);

When safeSnaphot is invoked, it returns a function. The returned function creates a closure around safeSnapshot‘s local variables because the returned function uses the variables internally (actually it just uses snapshot). The values (or references) held by these variables will stay in memory as long as something is holding a reference to the returned function.

At the end of that example, we see that we’ve handed a reference to the returned function to tweetConsumer as its tweetFetcher property. As long as tweetConsumer exists and nothing has reassigned its tweetFetcher property, the snapshot array will continue to exist in memory, waiting forever, if necessary, or until Chrome crashes. (omg shaddap! IE-bashing is so 2010 ya know)

Code snippet #2:

var squashed = (function (doc) {
    var nodes, howMany = 0;
    // find all links that open another friggin tab
    nodes = doc.getElementsByTagName('a');
    for (var i = 0, len = nodes.length; i < len; i++) {
        if (nodes[i].target != '') {
            // heh. this'll fix em. oh yeah! dom0 is so hawt.
            nodes[i].onclick = function () { return false; };
            howMany++;
        }
    }
    return howMany;
}(document));

Here’s a useful IIFE. It’s definitely a function expression since we’re using it inside an expression. It’s also being invoked immediately (see last line).

This is not a closure though. Why? Simple: there’s nothing capturing local variables or embedded functions. The local variables, nodes and howMany, are only used internally and there are no functions being returned to outside code.

What about the variable, howMany? It’s being returned!

No. I’ts not. It’s value is. howMany‘s value is being returned and placed in the [outer] variable, squashed.

What about the onclick function?

The onclick function would create a closure if it referenced variables in its scope, but it doesn’t.

What’s it all mean?

IIFEs are a useful construct. They’re a great way to isolate variables (and can also be used to capture copies of transient variables, but that’s too tl;dr for this discussion). IIFEs can also create closures. In fact, any function can create a closure if it returns a function — directly or indirectly — and uses local variables.

Closures are also very useful, but you don’t create closures via an explicit pattern. Closures just happen under the right circumstances and are used in many different patterns.

Note to javascript zealots and trolls

Yes, I know I skirted around a ton of details. And, yes, the terminology I used does not accurately reflect the state of the machinery under the hood. I did it to try to simplify the concepts. I think I portrayed closures accurately despite the simpler terms.

I also skipped dozens and dozens of great use cases. If people want to see more use cases, they can google it.

That said, if you’ve got a useful resource (link) or some additional info you think could be useful to devs who are learning about closures, please leave a comment.

– John

[update 2011-10-03]

I guess I inadvertently hijacked somebody else’s blog title. Although, this person is misusing the term “closure”, too.

I also got some twitter-lashing from some very smart people in response to this blog post. Furthermore, it seems just about every article on the web claims that simply placing a function inside of another function creates a closure. However, they are all wrong. Read on:

Read my lips!

The closure doesn’t exist until the local scope is externalized.

Read that again. This is the essence of the problem. A closure happens at run time under certain circumstances. It’s not something you construct at design time.

Here’s yet another example to show what this means:

(function () {
    var practicePhrase, practiceCount;
    practicePhrase = "Park the car in Harvard yard.";
    practiceCount = 10;
 
    function repeat () {
        alert(practicePhrase);
        if (--practiceCount >= 0) setTimeout(repeat, 1000);
    }
 
    // this is the important part. pay attention. :)
    if (new Date().getDay() != 2) {
        setTimeout(repeat, 1000);
    }
 
}());

In this example, we’re using setTimeout to “externalize” the local variables, practicePhrase and practiceCount. setTimeout doesn’t externalize in the usual way. We’re not returning a function to other javascript somewhere. Instead, we’re returning a function to the browser’s event queue mechanism. It works the same way, though.

Well, if you fully grokked this example, you’ll notice that the setTimeout sequence (which executes 10 times) is only initiated if this isn’t Tuesday. This means that the example code does not create a closure on Tuesdays.

Why? Because on Tuesdays, the repeat function — the one that would create the closure — is never externalized.

Simply placing a function inside of another function does not create a closure. It’s just an instance of function scope, which just means that functions can access variables in enclosing functions.

Some tl;dr articles that got it right:

MDN – Closures (a bit of confusion by the author, but read carefully)
Closure (wikipedia)

And now, I fear, this article is tl;dr, too.

[updated again 2011-10-02] I added some clarification about the function referenced by the onclick handler in the second example. (thx @brianarn!)

AMD versus CJS. What’s the best format?

John Hann — Sat, 01 Oct 2011 04:46:23 +0000

JavaScript Harmony will introduce native modules into JavaScript. Finally. And when IE9 finally dies a slow death, we’ll be able to use native modules in the browser. Yay corporate support contracts. In the mean time, there are two competing standards for modules: AMD and CJS Modules 1.1.1. Which one is better? Which one should you be using?

I’ve got an opinion and it may surprise you.

What’s the difference?

If you’re not aware of either format, I suggest you start by reading about Asynchronous Module Definition and CommonJS Modules 1.1.

In a nutshell, AMD is designed for browser environments and CommonJS is targeted at server-side environments. This fundamental difference has deep repercussions on the formats. Here’s a brief (and probably incomplete) summary of the differences between these two environments:

Scoping
Distance
Asynchrony

Scoping

JavaScript that runs in the browser has no way to isolate code completely. Sure, you can put your code in a function so your var statements don’t leak variables into the global scope, but it’s easy to make mistakes. Who hasn’t done this?

var a = b = 0;

AMD can’t efficiently solve this problem, so it doesn’t. Instead, it encourages local scoping by bringing external resources into a local function scope.

CJS arose from server-side environments, such as node, that started with a clean slate. In these environments, there is no global scope.

Distance

In the browser, most resources are remote, on a server somewhere. If you’re lucky, your resources are cached. Regardless, it can take time to fetch a resource. If your code depends on a function in another file, you can’t know for sure if it’s already loaded or if it may take a few seconds to arrive. You can’t write “normal” code if you don’t know if the function is defined yet!

CJS gets around this problem by assuming that all resources are local and can be fetched in msec or, more likely, microseconds.

Asynchrony

A direct result of the distance issue is the need to run tasks asynchronously. Browsers run JavaScript in a single thread. If that thread were to wait for a remote resource to be fetched, nothing else could execute and the browser would appear to be unresponsive to the user.

We get around this by initiating the fetch and requesting a callback when the resource is ready. The callback is typically in the form of a function, and is typically called … wait for it .. a callback function. (JS devs are so freakin smart I tell you.)

Node encourages asynchrony by emphasizing an event-driven programming model. However, the node creators punted when designing the API to fetch modules and provided the same stale File I/O APIs for fetching other resources. Personally, I think it would have strengthened the event-driven philosophy if they extended the event-driven philosophy to modules and file-based resources.

In a nutshell, CJS fetches module resources synchronously. I guess they thought it makes sense to not introduce the complexity of asynchrony if resources are only microseconds away.

A Closer look at the formats

So how do the rival formats handle their diverse target environments? Let’s look at AMD:

// define() is a necessary wrapper.
define(
    // dependencies are specified in advance.
    ['pkgA/modA', 'pkgA/modB', 'pkgZ/modC'],
    // the module is declared within a definition function.
    // dependencies are mapped into function parameters.
    function (modA, modB, modC) {
        // inside here is the module's code.
        // the module is exported to the outside world via the 
        // the definition function's returned value.
        return modC ? modA : modB;
    }
);

Contrast this with CJS:

// there is no explicit wrapper, we just write the module's code.
// this is not global scope! the scope is limited to this file only.
// "free" variables (`require`, `module`, and `exports`) are 
// declared to help us define our module and fetch resources.
 
// dependencies are specified as needed
var modC = require('pkgZ/modC');
 
// the module is exported by decorating the `exports` free variable.
exports.foo = modC ? require('pkgA/modA') : require('pkgA/modB');

AMD handles the asynchrony by having us declare our module inside of the definition function. The definition function is essentially a callback function. It’s called when all of our dependencies have been resolved. Some of these may require fetching. The execution of our module’s code is delayed until all of our resources are available. (Note: you can execute code earlier if you simply place it outside of the define().)

CJS on the other hand prefers to execute the module code as soon as possible, but load/execute the module dependencies only when needed. In the sample code above, only one of ‘pkgA/modA’ or ‘pkgA/modB’ will be loaded and executed. There’s an added bonus here! Our code could be significantly more efficient if the environment doesn’t have to load and execute all of the modules.

This is a clear win for CJS! Or is it? In the browser, there’s no way to have it both ways with this syntax. We’d either have to fetch the dependency in advance or fetch it synchronously.

(Ha ha! AMD has an solution to this problem that works for many, but not all, use cases. It’s called has.js and it has a sister plugin, called “has!”. (The exclamation mark is part of the plugin name; I didn’t append my emotion to it. Well, it is my emotion, but that’s not what I meant to convey. What I mean to say is… nm. whatevs.))

How about code size? From the example above, CJS is the winner here, for sure. … Or is it? If you were to execute that code in a browser, you’d be declaring globals left and right while clobbering variables in every other module. Clearly, we would need to at least wrap the module in an IIFE to prevent the module from running in the global scope.

Also, in the example above, I showed the advantage of delayed execution which allowed me to declare less variables. If you were to map all of the require()-ed modules to variables (and wrap the module in an IIFE), you’d end up with nearly the same number of bytes.

And the winner is….

So, if you asked me which one is the winner, I’d have to say neither. To be honest, I plan to use both formats.

AMD has some clear benefits in the browser world. For a more complete list, check out Miller Medeiros’s recent blog article on why AMD is better. I couldn’t say it any better than he did.

On the other hand, CJS advocates will argue that it’s critical to author modules in a format that doesn’t cater to the transport (more on this later). I understand and almost agree with their argument, but this article would be way too tl;dr if I were to extrapolate on that argument.

I’m guessing that both formats will be around for a long, long time. So here’s what I plan to do:

write modules that could execute in a server environment in CJS format
write modules that could benefit from AMD’s browser-friendly features in AMD format

Duh.

One more thing…

Did I mention that AMD supports wrapped CJS modules? If you read the wikis I linked at the top of this article, I wouldn’t have to tell you that because you’d already know. Here’s what one looks like:

define(
    ['pkgA/modA', 'pkgA/modB', 'pkgZ/modC', 'require', 'exports', 'module'],
    function (modA, modB, modC, require, exports, module) {
 
var modC = require('pkgZ/modC');
 
exports.foo = modC ? require('pkgA/modA') : require('pkgA/modB');
});

In this hybrid module, we’re prefetching modules like AMD, but using require() like an R-Value as in CJS. Funky! The require and exports “free” variables are brought into the modules using reserved dependency names. In this hybrid model (using CommonJS-ish terminology) AMD is the transport format and CommonJS is the authoring format. (Thanks to @tobie for reminding me of this. Repeatedly. The SproutCore guys have also given me a tongue lashing or two.)

RequireJS‘s companion script, r.js, will generate these wrappers for your CJS modules.

I’ve been experimenting with a slight variation on this. It compacts better and executes a bit faster, but munges the transport and authoring formats in the process:

define(
    ['pkgA/modA', 'pkgA/modB', 'pkgZ/modC', 'require', 'exports', 'module'],
    function (modA, modB, modC, require, exports, module) {
 
// ok. this looks funny, but it's much easier and more efficient
// to simply replace require() with a variable name than to figure out
// which variable declarations can be removed and how to do that safely.
// I may experiment some more. : )
var modC = modC;
 
exports.foo = modC ? modA : modB;
});

winning.

[Update 2011-10-01]

I’m trying not to wreck a nice ending on this blog post, but I just realized a big mistake on my part. I often get confused between CJS and the latest flavor of node. CJS is missing a very important feature, imho.

With CJS, you cannot have a module that returns a single function or constructor. If we are writing modules as focused and fine-grained as possible, then we should be able to do this!

Node allows us to assign our module to the `module.exports` property. A module that only exports a constructor could then look like this:

function MyConstructor () {}
module.exports = MyConstructor;

CJS needs to add this for ms to be 100% on board. Hm. I guess I’m not really authoring CJS modules now. They’re node modules.

AMD Module Patterns: Singleton

John Hann — Fri, 23 Sep 2011 03:03:09 +0000

This is the first in a series of posts illustrating how common design patterns can be achieved using AMD-style JavaScript modules. We’ll also look at some new patterns that are somewhat unique to AMD, including one that should be called nothing less than the “Alley oop slam dunk”!

No, no, we’re not going to talk about the “Alley oop slam dunk” first! Let’s start at the basics with the simplest of all design patterns: the Singleton.

Singleton

The singleton pattern is a design pattern used to [...] restrict the instantiation of a class to one object.

— Wikipedia

Yah, well that’s the formal definition. In classical OO languages maybe you need a pattern for that. In javascript we have object literals. There’s no need to restrict anything. It’s as simple as this:

(If you’re new to AMD, stop here and review this intro now.)

// simple module with no dependencies and no supporting code
define({
    format: function (dicomDate) {
        return (dicomDate || '').replace(/(?:d{4})d{2}/, '$1/');
    };
});

This is just shorthand for the slightly more verbose version:

// simple module with no dependencies and no supporting code
define(function () {
    return {
        format: function (dicomDate) {
            return (dicomDate || '').replace(/(?:d{4})d{2}/, '$1/');
        }
    };
});

In fact, most AMD loaders probably insert a definition function automatically.

Since AMD only executes the definition function once, we’ve essentially created a singleton. In the classical sense, a singleton is a class with instance data and state, but we’re stretching the definition a bit. Why? Because this ain’t Java!

Here’s an example that’s more like the classical singleton pattern or all the Java wannabees:

define(function () {
    var instance; // look ma! no globals!
    function Singleton () {
        this.defaultDate = '';
    }
    Singleton.prototype = {
        format: function (dicomDate) {
            return (dicomDate || this.defaultDate).replace(/(?:d{4})d{2}/, '$1/');
        },
        setDefault: function (dateString) {
            this.defaultDate = dateString;
        }
    };
 
    return function getSingleton () {
        return (instance = (instance || new Singleton()));
    };
});

Return something!

The most important thing to remember when creating AMD modules is to RETURN SOMETHING! RETURN ANYTHING!

Whatever you return from the definition function is what other modules will receive when they request your module.

If you return an object, other modules will receive an object.

If you return a function, other modules will receive a function.

If you return a constructor, other modules will receive a constructor.

If you return a string… can you guess what’s gonna happen? Well, you probably guessed wrong. Unfortunately, some AMD loaders and compilers/optimizers don’t handle this case as you’d expect. They assume that a string in the first parameter position is a module id and will either return undefined or throw an exception.

// not all builders support a string singleton because
// a string looks like a module id.
define("WTF, AMD build tool. I am not a module id!");

This is ok, thought, right? Who is going to have a module that consists of a single string?

Hmmm…. what if your module is an HTML template? The bottom line is that you should be able to return anything. curl.js and cram don’t restrict the return type of the module since they inspect the parameters from back to front. The last parameter is always the module definition!

However, there’s another solution for loading large text strings: the “text!” plugin. You should consider using the text! plugin rather than wrapping the string in a define().

But guess what, the text! plugin uses XHR, and XHR doesn’t work cross-domain in legacy browsers. For cross-domain text resources, you can use JSONP instead. JSONP is pretty darn easy to implement using AMD:

// a module to convert some jsonp-based resources to AMD:
define(['require', 'mylib/Deferred'], function (req, Deferred) {
    var promise = new Deferred();
    req(['cdnlib/template?jsonp=define', 'cdnlib/data?jsonp=define'],
        function (template, data) {
            promise.resolve({ template: template, data: data });
        }
    );
    return promise; // could also use a callback function
});

By telling the JSONP service that our callback is named “define” (?jsonp=define), we can simply use the built-in AMD async require mechanism to fetch the resources from the cross-domain server. I used a promise in this example just because I like promises, but you could devise a different implementation using a callback function, of course.

Here’s what those resources would look like when they’re returned:

// cdnlib/template will return something like:
define('...
');

// cdnlib/data will return something like:
define({ test: 'bostonian', question: 'wicked?', answer: 'pissah!' });

Magic!

Next, we’ll look at the Decorator pattern.

Comments welcome!

– John

The first annual dojoconf!

John Hann — Thu, 22 Sep 2011 11:46:06 +0000

I just got back from the first ever dojoconf in Washington DC. I asked Dylan and Chris if they were planning to do it annually and I got something equivalent to “F**K YEAH!”

Good. cuz it was awesome.

I was honored to present about AMD Module Patterns at dojoconf. My slides are here. A half hour is not nearly enough time to present on even a couple of patterns. It didn’t help that I was high on cold medication, so I think I missed half of the points I wanted to make and missed half my slides at the same time.

To rectify the situation, I will write a blog post on each pattern. My goal is to write about one pattern a day until they’re all done. Wish me luck.

– John

P.S. This was my first time representing a corporation at a conference. I have been a full-time employee at lifeIMAGE in Newton, MA since August 2010. lifeIMAGE sponsored the Hacker Lounge at dojoconf and paid for the awesome dojo minis! (Btw, we’re always hiring javascript engineers!)

What is the fastest way to load AMD modules?

John Hann — Thu, 22 Sep 2011 03:13:44 +0000

The AMD format for JavaScript modules was created to allow devs to write elegant, modular code rather than the silly global, name-spaced hackfest we’ve been writing. However, AMD has a hidden benefit: it allows modules to be downloaded in parallel, rather than sequentially. This is a potentially huge performance win.

However, does this really matter for production code?

Blocking before Loading

Virtually all of the examples of AMD code out on the web look something like this:

In this example, we’re loading moduleA and moduleB in parallel. This is the fast way to do it, right? Yes, but also note that we’re loading some-amd-loader.js in a blocking fashion. The second script element (and the rest of the document) has to wait for some-amd-loader.js to finish loading and executing before proceeding.

This isn’t ideal, of course. So how do we fix this?

Answer: by only including one script element in the page and ensuring that that single script allows the page to continue parsing and rendering.

Native async loading

Here’s what we really want:

Newer browsers support the async attribute. async="true" instructs the browser that it can proceed to parse and evaluate any future script elements without waiting. You’d think a browser would notice that there’s only one script element, right? Just in case, we’re going to tell it how we want it to behave.

Older browsers don’t support the async attribute. However, they do support the defer attribute. This attribute tells the browser that it may defer execution of the script until a convenient time — even after the body is rendered. Unfortunately, browsers don’t all act the same with this attribute. Most browsers, though, do a fairly good job when there’s only one script element in the document.

Since the browser isn’t waiting for the script’s javascript to load or execute, the script element can be in the head where it belongs. There is no need to put it at the ned of the body element.

So, what’s myapp-bootstrap.js look like in this scenario? The sky’s the limit, but you can imagine a minimal set of requirements:

1. it contains an AMD loader
2. it contains one of the following:
a. instructions to load the rest of the app
b. the actual code for the rest of the app

If you’re compiling/optimizing your AMD modules into a single js file already, it’s not too much harder to concatenate the actual AMD loader onto the front of the file (using requirements 1 and 2b above). Some compilers/optimizers have support for this built in, RequireJS, for example. RequireJS also has a companion loader, almond, that is tiny and can handle the simpler environment inside a compiled file.

So, essentially, all that AMD provided for us in this single-script scenario is a way to ensure ordering of our modules into a single file, it seems. Does this mean that the whole async loading behavior we’ve been touting about AMD is just a bunch of “snake oil“? Not at all. Keep reading:

We ain’t oiling no snakes

Let’s say our web app has several pages. Each of these pages has a core set of modules it requires to function and a set of modules that are unique to it. This is not an unlikely scenario, and is quite likely the most common case.

In this scenario, it could be ideal to allow the common core modules to be fetched from cache and the unique, page-specific modules to be loaded separately. Each subsequent page load would be fast because it’s not loading as much code. For this scenario, requirements 1 and 2a are the best choice. The code inside the single file would look a lot like the original code snippet above:

// loader source code goes here
 
// initialize our app in two parts!
someAmdLoader(["moduleA", "moduleB", "domReady!"], function (A, B) {
    var app = new A(), boot = new B(app);
    boot.init();
});

How finely grained you break up your app is totally unique to your app and your target browsers. If you are targeting older IE’s, then your app is burdened by limited HTTP requests. A small number of fetches per page is best.

More sophisticated apps or ones that can ignore older browsers may be able to take advantage of multiple parallel downloads. However, you must remember that each image, css file, and xhr consumes an HTTP request!

Most of the apps I write have a very sparse body because the UI is built by templates embedded in the javascript. The css is embedded, too (via curl.js‘s css! plugin and the cram optimization tool). This means we can break the app up into several files. Some of these files are loaded when the page loads. Others are loaded when needed (“lazily”).

Do some experimentation to figure out what your ideal situation is. If you already have, please share it with the rest of us in the comments section! There are other ways we could load modules since AMD is very flexible. Do you have an entirely different approach?

Thanks!

– John

[update 2011-09-22 12:35 PM EDT] @getify says that he doesn’t recommend the “defer” attribute due to jQuery/FF3.x issues. see twitter convo here. Also: “defer” isn’t always what you want. Use wisely.

Modules > Frameworks

John Hann — Mon, 02 May 2011 19:16:37 +0000

My slides from JSCONF 2011 in Portland, May 1: http://unscriptable.com/code/Modules-Frameworks/

Feedback appreciated!

Using AMD loaders to write and manage modular javascript

John Hann — Thu, 28 Apr 2011 01:24:24 +0000

Recently, I gave a short presentation about AMD (Asynchronous Module Definition) at the Boston JavaScript Meetup Group. Here are the slides:

http://unscriptable.com/code/Using-AMD-loaders/

There wasn’t enough time to talk about all of the AMD loaders in existence, and certainly not enough time to dig into the many use cases and nuances of AMD-formatted modules. However, I hope I was able to help improve awareness of AMD and javascript modules in general.

Enjoy!

[Update 2011-04-27] If you’re wondering what happened to the “manage” part of the title’s “write and manage”… it’s coming in a future presentation.

curl.js – yet another AMD loader [updated]

John Hann — Thu, 31 Mar 2011 01:24:33 +0000

Over the past several weeks, I’ve been writing an AMD-compatible javascript loader called curl.js. AMD stands for Asynchronous Module Definition and is a CommonJS proposed standard for writing javascript modules. The module format closely follows the proposed migration path set out by ECMA’s proposed ES-Harmony javascript modules.

curl stands for Cujo Resource Loader since it’s an integral part of the re-engineering of cujo.js.

An AMD-compatible javascript loader is (surprise, surprise) an asynchronous javascript loader that is savvy about AMD-formatted javascript modules.

[update]
Version 0.3.2 is out! fork it!

What is an asynchronous loader?

Web apps, especially large ones, require many modules and resources. Most of these modules and resources need to be loaded at page load, but some may be loaded later, either in the background or “just in time”. They also need to be loaded as quickly as possible.

The traditional way to load javascript modules is via a