What are the differences between Deferred, Promise and Future in JavaScript?

105,493

Solution 1

In light of apparent dislike for how I've attempted to answer the OP's question. The literal answer is, a promise is something shared w/ other objects, while a deferred should be kept private. Primarily, a deferred (which generally extends Promise) can resolve itself, while a promise might not be able to do so.

If you're interested in the minutiae, then examine Promises/A+.


So far as I'm aware, the overarching purpose is to improve clarity and loosen coupling through a standardized interface. See suggested reading from @jfriend00:

Rather than directly passing callbacks to functions, something which can lead to tightly coupled interfaces, using promises allows one to separate concerns for code that is synchronous or asynchronous.

Personally, I've found deferred especially useful when dealing with e.g. templates that are populated by asynchronous requests, loading scripts that have networks of dependencies, and providing user feedback to form data in a non-blocking manner.

Indeed, compare the pure callback form of doing something after loading CodeMirror in JS mode asynchronously (apologies, I've not used jQuery in a while):

/* assume getScript has signature like: function (path, callback, context) 
   and listens to onload && onreadystatechange */
$(function () {
   getScript('path/to/CodeMirror', getJSMode);

   // onreadystate is not reliable for callback args.
   function getJSMode() {
       getScript('path/to/CodeMirror/mode/javascript/javascript.js', 
           ourAwesomeScript);
   };

   function ourAwesomeScript() {
       console.log("CodeMirror is awesome, but I'm too impatient.");
   };
});

To the promises formulated version (again, apologies, I'm not up to date on jQuery):

/* Assume getScript returns a promise object */
$(function () {
   $.when(
       getScript('path/to/CodeMirror'),
       getScript('path/to/CodeMirror/mode/javascript/javascript.js')
   ).then(function () {
       console.log("CodeMirror is awesome, but I'm too impatient.");
   });
});

Apologies for the semi-pseudo code, but I hope it makes the core idea somewhat clear. Basically, by returning a standardized promise, you can pass the promise around, thus allowing for more clear grouping.

Solution 2

These answers, including the selected answer, are good for introducing promises conceptually, but lacking in specifics of what exactly the differences are in the terminology that arises when using libraries implementing them (and there are important differences).

Since it is still an evolving spec, the answer currently comes from attempting to survey both references (like wikipedia) and implementations (like jQuery):

  • Deferred: Never described in popular references, 1 2 3 4 but commonly used by implementations as the arbiter of promise resolution (implementing resolve and reject). 5 6 7

    Sometimes deferreds are also promises (implementing then), 5 6 other times it's seen as more pure to have the Deferred only capable of resolution, and forcing the user to access the promise for using then. 7

  • Promise: The most all-encompasing word for the strategy under discussion.

    A proxy object storing the result of a target function whose synchronicity we would like to abstract, plus exposing a then function accepting another target function and returning a new promise. 2

    Example from CommonJS:

    > asyncComputeTheAnswerToEverything()
        .then(addTwo)
        .then(printResult);
    44
    

     

    Always described in popular references, although never specified as to whose responsibility resolution falls to. 1 2 3 4

    Always present in popular implementations, and never given resolution abilites. 5 6 7

  • Future: a seemingly deprecated term found in some popular references 1 and at least one popular implementation, 8 but seemingly being phased out of discussion in preference for the term 'promise' 3 and not always mentioned in popular introductions to the topic. 9

    However, at least one library uses the term generically for abstracting synchronicity and error handling, while not providing then functionality. 10 It's unclear if avoiding the term 'promise' was intentional, but probably a good choice since promises are built around 'thenables.' 2

References

  1. Wikipedia on Promises & Futures
  2. Promises/A+ spec
  3. DOM Standard on Promises
  4. DOM Standard Promises Spec WIP
  5. DOJO Toolkit Deferreds
  6. jQuery Deferreds
  7. Q
  8. FutureJS
  9. Functional Javascript section on Promises
  10. Futures in AngularJS Integration Testing

Misc potentially confusing things

Solution 3

What really made it all click for me was this presentation by Domenic Denicola.

In a github gist, he gave the description I like most, it's very concise:

The point of promises is to give us back functional composition and error bubbling in the async world.

In other word, promises are a way that lets us write asynchronous code that is almost as easy to write as if it was synchronous.

Consider this example, with promises:

getTweetsFor("domenic") // promise-returning async function
    .then(function (tweets) {
        var shortUrls = parseTweetsForUrls(tweets);
        var mostRecentShortUrl = shortUrls[0];
        return expandUrlUsingTwitterApi(mostRecentShortUrl); // promise-returning async function
    })
    .then(doHttpRequest) // promise-returning async function
    .then(
        function (responseBody) {
            console.log("Most recent link text:", responseBody);
        },
        function (error) {
            console.error("Error with the twitterverse:", error);
        }
    );

It works as if you were writing this synchronous code:

try {
    var tweets = getTweetsFor("domenic"); // blocking
    var shortUrls = parseTweetsForUrls(tweets);
    var mostRecentShortUrl = shortUrls[0];
    var responseBody = doHttpRequest(expandUrlUsingTwitterApi(mostRecentShortUrl)); // blocking x 2
    console.log("Most recent link text:", responseBody);
} catch (error) {
    console.error("Error with the twitterverse: ", error);
}

(If this still sounds complicated, watch that presentation!)

Regarding Deferred, it's a way to .resolve() or .reject() promises. In the Promises/B spec, it is called .defer(). In jQuery, it's $.Deferred().

Please note that, as far as I know, the Promise implementation in jQuery is broken (see that gist), at least as of jQuery 1.8.2.
It supposedly implements Promises/A thenables, but you don't get the correct error handling you should, in the sense that the whole "async try/catch" functionality won't work. Which is a pity, because having a "try/catch" with async code is utterly cool.

If you are going to use Promises (you should try them out with your own code!), use Kris Kowal's Q. The jQuery version is just some callback aggregator for writing cleaner jQuery code, but misses the point.

Regarding Future, I have no idea, I haven't seen that in any API.

Edit: Domenic Denicola's youtube talk on Promises from @Farm's comment below.

A quote from Michael Jackson (yes, Michael Jackson) from the video:

I want you to burn this phrase in your mind: A promise is an asynchronous value.

This is an excellent description: a promise is like a variable from the future - a first-class reference to something that, at some point, will exist (or happen).

Solution 4

A Promise represents a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers to an asynchronous action's eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of the final value, the asynchronous method returns a promise of having a value at some point in the future.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

The deferred.promise() method allows an asynchronous function to prevent other code from interfering with the progress or status of its internal request. The Promise exposes only the Deferred methods needed to attach additional handlers or determine the state (then, done, fail, always, pipe, progress, state and promise), but not ones that change the state (resolve, reject, notify, resolveWith, rejectWith, and notifyWith).

If target is provided, deferred.promise() will attach the methods onto it and then return this object rather than create a new one. This can be useful to attach the Promise behavior to an object that already exists.

If you are creating a Deferred, keep a reference to the Deferred so that it can be resolved or rejected at some point. Return only the Promise object via deferred.promise() so other code can register callbacks or inspect the current state.

Simply we can say that a Promise represents a value that is not yet known where as a Deferred represents work that is not yet finished.


enter image description here

Solution 5

  • A promise represents a value that is not yet known
  • A deferred represents work that is not yet finished

A promise is a placeholder for a result which is initially unknown while a deferred represents the computation that results in the value.

Reference

Share:
105,493
Tower
Author by

Tower

Updated on October 05, 2020

Comments

  • Tower
    Tower over 3 years

    What are the differences between Deferreds, Promises and Futures?
    Is there a generally approved theory behind all these three?

  • awdz9nld
    awdz9nld over 11 years
    While this answer might be useful, it does not factually address the question: so-called deferreds are either futures or promises, depending on the implementation.
  • fncomp
    fncomp over 11 years
    @MartinKällman You're right! I hadn't revisited this in a while and have learned a bit. I'll post a separate answer below, but leave this since people seem to have benefited from the usage example.
  • fncomp
    fncomp about 11 years
    @MartinKällman, considered writing a new answer. However, I think the OP actually wanted to know what Promises and Deferreds are for. The answer to his actual question would be, roughly, "deferreds can resolve their-self. AFAIK, the theory behind promises and deferreds comes from [Functional Reactive Programming|haskell.org/haskellwiki/Functional_Reactive_Prog‌​ramming], which is a technique for flattening callbacks."
  • oligofren
    oligofren almost 11 years
    A great explanation of Futures (now implemented in the DOM!) by a member of the W3 and Chrome core team is to be found here: xanthir.com/b4PY0
  • Camilo Martin
    Camilo Martin almost 11 years
    @oligofren Thanks for the link, that seems nice! By the way, what a mysteriously annoying favicon lol.
  • Chev
    Chev over 10 years
    This answer needs a lot more upvotes. It should be voted higher than the accepted answer IMO.
  • Esailija
    Esailija over 10 years
    This is just totally wrong and your examples are just as easy to do with callbacks. Promises are not about callback aggregation and decoupling but providing a DSL to write async code like sync code is written. Especially fn(callback, errback) is not any more tightly coupled or less useful than fn().then(callback, errback) - but that's a wrong way to use promises anyway. I especially hate the cargo cult $.when example - there is absolutely no reason you cannot have a $.when function that worked with callbacks.
  • Farm
    Farm over 10 years
    Domenic Denicola's youtube talk on Promises : youtube.com/watch?v=hf1T_AONQJU
  • Camilo Martin
    Camilo Martin over 10 years
    @Farm Great! I'll add that to the answer.
  • Bhojendra Rauniyar
    Bhojendra Rauniyar over 9 years
    This does not answer to the question though +1 that I could be able to know what the callback hell is.
  • gurung
    gurung almost 8 years
    Here is a link to the SPECIFIC PART of the above mentioned video on promises by Domenic Denicola.
  • Heather Miller
    Heather Miller over 7 years
    To add a bit more clarification on the term "Future" – futures have a long history across many programming languages dating back to the mid-80s. And the term is still in wide use today, in particular on the JVM. JavaScript seems to have chosen to use the term "Promise" to mean something similar to what Java means by "Future". Scala separates the same concept into a "Future" and "Promise" to refer to "read" handle and the "write" handle of what JavaScript programmers call a Promise.
  • BlueRaja - Danny Pflughoeft
    BlueRaja - Danny Pflughoeft about 7 years
    And of course Microsoft had to come up with their own term for it, so in C# they're called Task
  • Ashok M A
    Ashok M A about 6 years
    plus 1 for the chart representation. Bravisimo!! ^_^
  • user3245268
    user3245268 about 5 years
    For me, the key phrase for understanding deferreds from this post was " Deferred, it's a way to .resolve() or .reject() promises"