An introduction to jQuery Deferreds | Hacker News Reader

An introduction to jQuery Deferreds

javascriptplayground.com

50 pointswtildesley10 comments

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.

Also, q is a really nice javascript library that models the same pattern:

https://github.com/kriskowal/q

> 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

In my experience Futures, Deferreds, and Promises all have different definitions. JS developers seem to be cooping some of these meanings for their own usage, which is natural in any fast growing community. All of the Promise APIs I've seen in JS are really just what I historically saw called Deferreds (like this jQuery API). Futures and Promises, historically, have been ways to express asynchronous work in a synchronous workflow, where a Future is just a read-only view of a Promise. If interested, play with Mozart/Oz and grab a copy of Concepts Techniques and Models of Computer Programming. I both very mind expanding when it comes to thinking of concurrency and data flow.

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.

What the article hints at, but doesn't really follow through on, is that you could use this to fire off multiple AJAX calls in parallel and the do something only when all of them have completed.

Futures/Promises are an interesting technique to do control flow. IMO, there are certain nuances like losing distinction between async/sync calls that work against the technique. I wrote an article about it at: http://javascriptturnsmeon.com/93769736

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

<troll>Yeah, Javascript make it one step closer Twisted, 1999</troll>

Reply on news.ycombinator.com