An introduction to jQuery Deferreds

Futures (aka Deferreds aka Promises) are indeed cool. For a more general toolbox, check out https://github.com/coolaj86/futures

What the linked article doesn't show is how you would create your own future objects, which in my point of view is the more useful thing. (I can always specify the error function using the more general $.ajax() so knowing that $.get() finally allows specifying both success and error with futures isn't that useful...). Besides just plain futures, the join and chainify abstractions (and the sequence abstraction that you can of course get elsewhere) from the futures library I linked allow you to create really nice code. Sequences alone heavily reduced my initial frustrations when using Node.

And if you'd like to use the same API in a non-browser environment, Underscore.Deferred is a complete port of jQuery.Deferred and jQuery.when that has no jQuery dependencies: https://github.com/wookiehangover/underscore.Deferred

> Besides just plain futures, the join and chainify abstractions from the futures library I linked allow you to create really nice code.

jQuery's deferreds also provide these tools (or their utility would be far more limited). Join is available through `$.when` and noted in the article:

    $.when(fn1(), fn2()).then(op)

will only execute `op` when both `fn1()` and `fn2()`'s results resolve, and sequences are available through `$.Deferred.pipe`: `pipe` creates a new Deferred which by default is just a proxy for the one it was called on but

* If the executed handler[0] returns a value, this value replaces the value #pipe's source was resolved or rejected with, e.g.

    var d = $.Deferred(),
        r = d.pipe(function (val) { return val / 2; });
    d.resolve(42);

    d.then(function (val) { /* val will be 42 */ });
    r.then(function (val) { /* val will be 42 / 2 -> 21 */ });

* If the executed handler returns a Deferred, that deferred will replace the original one, which allows both chaining deferred (executing a second async operation following the first one) and inverting results (#pipe allows — conditionally or not — transforming a rejection into a resolution and a resolution into a rejection, this is useful when there are multiple ways to get a value so that the second one can be tried iif the first one fails)

[0] like #then, #pipe can take both a success and a failure handler

I'm finding that, with the aid of Backbone, the Deferred methodology is becoming obsolete. For instance, as mentioned by someone else in these comments, a great use case for Deferred is firing off multiple queries and waiting on their return.

You can accomplish this in Backbone, inherently even, by listening to change events in models. In my app, I used the Deferred methodology to begin with, but now that I'm refactoring the site into Backbone, everything is much cleaner (thanks to the additional structure that MVC provides).

I'm working on a Backbone app where multiple XHRs are required to populate one model and after reading this article I'm thinking about using deferreds to only fire the change event once all the XHRs have finished. I can't think of a native Backbone way to do it.