Promises/A+

http://promisesaplus.com/

by Dekku • 13 years ago

61 45 13 years ago

promisesaplus.com

andrewcooke• 13 years ago

wouldn't it be good to explain somewhere, early on, that this is for javascript?

__david__• 13 years ago

Well, the link in the first sentence does point to http://commonjs.org/...

domenicd7• 13 years ago

This is actually a really good point, haha! Filed, and will fix in the upcoming so-close-to-done 1.1 revision: https://github.com/promises-aplus/promises-spec/issues/135

jasondenizac2• 13 years ago

While the Promises/A+ specification is primarily focussed on JavaScript, the concept of promises certainly did not originate in JavaScript. For that matter, there are actually a number of implementations of Promises/A+ in other languages and platforms: https://github.com/promises-aplus/promises-spec/blob/master/...

kolodny• 13 years ago

I wrote a library a while ago that nearly fulfills this entire spec. I've added/changed things that I thought were more intuitive. https://github.com/kolodny/wttt

jkrems3• 13 years ago

The point of having the spec is that libraries can freely exchange data and promises, even if they depend on totally different flow control libraries, while still being certain that error handling and chaining works as expected. It looks like if I build on top of your library, I'm locked in.

This is not to say that it invalidates your library or that every promise library has to comply to A+ or that A+ is the only good way to design promises in JS.

_greim_2• 13 years ago

My beef with JS Promises (uppercase "P") is that, as a programming idiom, I prefer once I have X, Y and Z, do something with X, Y and Z over get X, then get Y, then get Z. In the former case, the provisioning logic is a separate concern; it could be done in parallel, serially, or via some combination of both. In the latter case, it's inherently serial.

I wrote an alternate implementation of promises in JS (lowercase "p") that uses the former approach: https://github.com/greim/await.js

drhayes9• 13 years ago

I don't understand your comment (or this is related to the lack of good introductory material noted in another comment).

You can retrieve the results of promises in parallel, serially, or via some combination of both. That's part of their power versus straight callbacks which enforce a serial approach.

Check out this link to q's documentation: https://github.com/kriskowal/q#combination

ufo4• 13 years ago

TBH, both callbacks and promises are kind of similar when it comes to running things in parallel. In both cases you use the same sort of semaphore pattern and its something thats easy to hide behind a library function.

    function parallelCallbacks(cbs, onAllDone){
        var nLeft = cbs.length;
        var results = []
        var onOneDone = function(res){
           results.push(res);
           nLeft -= 1;
           if(nLeft <= 0){ onAllDone(results) }
        }

        for(var i=0; i<cbs.length; i++){
            cbs[i](onOneDone);
        }
    }

    parallelPromises([
       function(){ return promise(10) },
       function(){ return promise(20) }
    ).then(function(results){ ... });

    parallelCallbacks([
        function(onDone){ onDone(10) },
        function(onDone){ onDone(20) }
    ], function(results){
       ...
    });

_greim_2• 13 years ago

My main point is that Promises don't have any concept of parallelism; all() is specific to the Q library, not part of Promises/A+. Obviously that's the intent—low-level building blocks—but it leaves one feeling like Promises don't actually solve any hard problems. You still have to solve them yourself.

ufo4• 13 years ago

Personally, that sounds like a really odd complaint to make. After all, running promises in parallel should be just a matter of using a simple library function that you can very easily code yourself if its not already provided.

I tend to find that the biggest problem with promise libraries is writing code with lots of jumps and more advanced control flow. If you are using an explicit continuation-based approach then doing a jump (for a loop or for breaking out early) is just a matter of calling the appropriate continuation. On the other hand, promises naturally tend to prefer the sort of code where there is only a single return statement at the end (unless you abuse the error handling system but there are all sort of problems if you do that)

andywhite372• 13 years ago

I like your approach with your await library. You're probably aware of this, but the jQuery "Deferred" implementation of promises has a similar mechanism that I'm not sure is common in other JavaScript promise implementations:

$.when()

http://api.jquery.com/jQuery.when/

jasondenizac2• 13 years ago

Q has `Q.all()` which does the same thing: https://github.com/kriskowal/q/wiki/API-Reference#promiseall

tlrobinson2• 13 years ago

It's absolutely possible to do multiple things in parallel using Promises/A(+) then "resolve" a new promise once they're all done. That's what Q.all() in the Q library does, for example.

That API isn't written into the Promises/A+ spec because it doesn't need to be. That spec is the minimal things necessary for multiple promise implementations to be interoperable.

SeanDav3• 13 years ago

I have just started doing development in Node.js. Originally using the excellent caolan/async library (https://github.com/caolan/async) for handling synchronous situations. Now started moving towards Promises but finding it quite hard to locate any "Promises for Dummies" type guide. Most of the libraries like "q" etc (https://github.com/kriskowal/q) just give you a list of functions to use and related syntax but I have yet to come across a guide that goes into detail as to exactly how and why you use certain functions.

I am kind of figuring things out as I go along but if anyone here can point me to such guides, I would be most grateful.

domenicd7• 13 years ago

I have given several talks, for which slide decks and one video are available:

http://www.slideshare.net/domenicdenicola/callbacks-promises...

http://www.slideshare.net/domenicdenicola/promises-promises with video at http://www.youtube.com/watch?v=MNxnHbyzhuo

http://www.slideshare.net/domenicdenicola/boom-promisesa-was... which is more inspirational and motivational than practical

Otherwise, in the Q readme we try for a "graduated tutorial" approach; would welcome any feedback you have to make it more friendly. We try to relegate the "list of functions" to the API reference at https://github.com/kriskowal/q/wiki/API-Reference

SeanDav3• 13 years ago

Hi Domenic, Thanks for those links - I will check them all. There is another one of yours (co-speaker) that I thought was excellent: Redemption from Callback Hell (http://www.youtube.com/watch?v=hf1T_AONQJU)

tgriesser• 13 years ago

I recently wrote two Node.js libraries that use promises extensively, an Active Record style ORM http://bookshelfjs.org and Query Builder http://knexjs.org. I actually didn't find a need for many of the higher level functions, outside of .then I'd typically stick to .all, .reject / .resolve, and occasionally .defer.

The source should be fairly annotated and is structured similar to Backbone.js, so it might be useful to take a look through and see where/how those functions are being used.

DanielRibeiro• 13 years ago

James Coglan did a good introduction of promises on his Callbacks are imperative, promises are functional: Node’s biggest missed opportunity[1] (HN discussion here[2]).

The author of Promises/A+ also wrote a nice blost post on his You're Missing the Point of Promises [3]

Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well[4]

[1] http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-...

[2] https://news.ycombinator.com/item?id=5466872

[3] https://gist.github.com/domenic/3889970

[4] http://en.wikipedia.org/wiki/Future_%28programming%29

SeanDav3• 13 years ago

Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well

This is my problem - when I last formally studied Computer Science we never covered this. I think most, if not all, of the Promises libraries assume you have a background that covers this, which makes it harder for those of us who have to work out all this from scratch. Not that I am complaining - just an observation.

Probably also harder for people like me that are not working with anyone who actually knows Node.js or Promises. The upside is of course that knowledge gained the hard way often sticks better, even if the process is more frustrating.

dclowd9901• 13 years ago

The thing about promises is their real power comes when you return them out of functions you run, thus causing any function to become async, and the promise being returned allows it to be used in a variety of ways:

    promisesFunc().done(function(){ // execute on completion }

    q.when(promisesFunc).then( function(){ // do stuff } )

It's nice to be able to treat something that is inherently asynchronous like it is inherently asynchronous. Feels good man.jpg. And just wait til you start mixing in generators (well, eventually).

pspeter3• 13 years ago

Just out of curiosity, why don't we use node's event emitters to wrap callbacks as promises?

jkrems3• 13 years ago

Because promises resolve to one value which can be retrieved long after the promise was resolved. This is a fundamentally different approach than EventEmitters. node's streams are the closest thing to "promise meets event emitter" I'm aware of. But maybe I'm missing the point of your question.

domenicd7• 13 years ago

It's worth noting we are very close to finishing up a 1.1 revision of the spec, which clarifies a few things mainly around how promise libraries interoperate with each other's promises. You can find the work in our master branch (as opposed to gh-pages):

https://github.com/promises-aplus/promises-spec

Including a changelog:

https://github.com/promises-aplus/promises-spec/blob/master/...

And the issues still open versus closed in the 1.1 timeframe are at

https://github.com/promises-aplus/promises-spec/issues?miles...

We were hoping to do a revision of the website's look at the time of the 1.1 release as well, mainly adding links to additional resources in the repository (like the implementations list, credits, etc.). A bit sad that we haven't moved fast enough to finish that before making the front page of Hacker News!

domenicd7• 13 years ago

I gave a talk at JSConf US 2013 about the genesis of this spec, and how I believe it plays into the future of open, developer-driven APIs for the web platform. I hope the video is up soon, but until then, the slides are at http://www.slideshare.net/domenicdenicola/boom-promisesa-was...

tjansen• 13 years ago

The great thing about Promises/A+ is that it's so small. I have implemented it in 375 bytes, and was even able to add two convenience functions: https://github.com/timjansen/PinkySwear.js

scotth• 13 years ago

Great project name.

willvarfar2• 13 years ago

3.2.1.1 If onFulfilled is not a function, it must be ignored.

This is idiomatic JS I guess, but it bugs me to bits. IMO the parameter should be a function or it should be null; anything else should throw an error.

domenicd7• 13 years ago

`then` is meant to return a promise, i.e. return an asynchronous value; it should never synchronously throw an error.

That said, I somewhat agree (although in JavaScript it should be `undefined`, not `null`). If we were starting clean, instead of with tons of code in the wild that did `.then(null, onRejected)` or `.then(false, onRejected)`, we would have the resulting promise be rejected with a `TypeError` if `onFulfilled` was neither `undefined` nor a function.

willvarfar2• 13 years ago

Hmm null is easier to pass on purpose and undefined is easier to pass by accident.

Sending in undefined for a non-trailing argument takes effort.

I think the literal null is far more communicative of the developers intent.

But the general point is, JS APIs tend to fail silently on error by design and that's something that bugs me, literally. Bugs. Lots of them.

I agree regards returning a failure rather than throwing an exception, though.

ricardobeat• 13 years ago

Promises are coming of age too late, and still have unsolved fundamental issues.

Meanwhile, ES6 generators are coming to node v0.12, already in FF and soon to be in Chrome; that is a whole different game.

1st1• 13 years ago

It's still better to use promises as an underlying mechanism, so that you can "yield* promise" or "yield* generator". This approach is now implemented in python tulip framework, and it solves the problem of combining the existing callback-based code with coroutines.

martingordon2• 13 years ago

Maybe I'm missing something, but I find C#'s async/await much more intuitive (not having written any C# and currently working on a pet project using promises with Node and Q).

My issue with promises is that I find myself working around the API/language when I actually want synchronous code. My app calls a JSON API and then writes the results to three tables (in sequence). In "normal", blocking code:

  results = getResults(); writeTable1(results.foo); writeTable2(results.bar); writeTable3(results.baz);

Using Node and Q:

  db.load().then(()-> setupDB(db)).then(()-> collectData(db)).done()

In which setupDB() returns a chain of three promises and collectData, which loops through the results and attach a new promise to the chain in order to return a chain of `n` promises.

Are these just growing pains of learning a new paradigm or am I using the wrong tool for the job?

Can someone point me to any projects that actually use promises?

ShellfishMeme• 13 years ago

If you make your `db.load` method resolve the promise with `this` (where `this` is `db`), and do the same for `setupDB` and `collectData` you can easily chain them without having to have a reference to `db`.

    db.load()
        .then(setupDB)
        .then(collectData);

That way it looks much more like your blocking code.

You are currently basically throwing away the value you `resolve` with, where you should instead resolve with what would be the return value if it was a sync function so you can `.then` the function that takes the return value and returns a promise to be resolved with its return value.

    // Sync
    var foo = function () { return 'foo' };
    var addBar = function (foo) { return foo + 'bar'; }
    addBar(foo()) == 'foobar'

    // Promise using Q
    var foo = function () { return Q.resolve('foo') };
    var addBar = function (foo) { return Q.resolve(foo + 'bar'); }
    foo.then(addBar).done(function (result) {
        result == 'foobar'
    });

domenicd7• 13 years ago

It's worth noting that C#'s async/await is based directly on promises; they are called `Task<T>` in .NET. Indeed, they share a common ancestor I believe; .NET 4.5's `Task<T>` is derived from F#'s `Async<T>`, and both `Async<T>` and JavaScript promises are based on E's promises.

martingordon2• 13 years ago

Yeah, I think the big difference for me is the language support. You can just await a method call instead of having to wrap the remainder of your block in a function.

Perhaps I should look into IcedCoffeeScript (http://maxtaco.github.io/coffee-script/) instead of plain CS.

unwiredben• 13 years ago

Thanks for this discussion... after reading Domenic's slides, watching his talk, and going through the questions here and on the gist, I've filed a bug to try to move Enyo's async implementation to promises after our next release. (https://enyojs.atlassian.net/browse/ENYO-2700) Currently, our code is more like the jQuery 1.5 implementation, but it really lacks the nice error semantics that Promises/A+ has.

Promises/A+

Related Stories