JavaScript Promises: There and back again

http://www.html5rocks.com/en/tutorials/es6/promises/#!

by sacado2 • 13 years ago

217 74 13 years ago

html5rocks.com

thrush• 13 years ago

does this mean anything for NodeJS programmers that rely on an existing promise library (eg Q)?

PhrosTT• 13 years ago

Well presumably this makes it's way into V8 and therefore node. I'd assume the performance is better than Q.

The biggest issue for me is Q's habit of hiding errors despite me defining a Q.onerror handler. Hopefully a native implementation would fail a little louder.

iamwil2• 13 years ago

I've had this issue with Q and when. Sometimes, things would fail inside a then chain, and then I can't figure out where exactly it failed, because though it fell through a couple thens, I'm not sure exactly where it came from, or how it got that way.

zoips• 13 years ago

Q contains some helper functions for creating generators, tying them to a promise, and automatically starting the generator, eg Q.async(). I've found that I'd rather continue using Q and use Q.async()/Q.spawn() rather than dealing directly with the generators and managing them.

itsbits• 13 years ago

does latest NodeJS has this?

secoif• 13 years ago

not yet

camus22• 13 years ago

nodewebkit has Promises.

omgtehlion5• 13 years ago

you can always `npm install <your-favorite-promises-library>`

jonsherrard• 13 years ago

npm install es6-promise for a shim

iamwil2• 13 years ago

What version of Javascript has Promises and does anyone know the estimated time it might take to make it over to V8 and subsequently node.js?

The biggest issue I had with promises is interfacing with non-promise code. There are methods to 'lift' node.js code that uses callbacks into promises, but the resulting code is much noiser.

I'm a bit disappointed that the official JS version didn't cut down on the visual noise of the piping so the actual work being done stands out. Maybe there needs to be a different type of syntax highlighter that mutes the promises piping and highlights the actual calls.

astrodust2• 13 years ago

I've just been using the Q promise library and it works fine in NodeJS. The Q wrappers for NodeJS style functions is a bit ugly, but it works very well.

The real problem is the core NodeJS libraries aren't promise compliant. I don't know if there's a module that cleanly wraps all of these in their promise analogs but that'd be the best thing here.

Calling Q.nsend() on everything is messy, but is a lot better than dealing with ridiculously nested callbacks.

mjackson• 13 years ago

The real problem is the core NodeJS libraries aren't promise compliant.

This isn't a problem at all in practice.

To say that node core is not "promise compliant" gives people the idea that there is something that prevents them from using promises in node. In reality, most promise libraries have a "denodeify" function that will convert any function that expects a node-style callback into one that returns a promise instead.

  var fs = require('fs');
  var rsvp = require('rsvp');
  
  // Create a version of fs.readFile that returns
  // a promise instead of expecting a callback.
  var readFile = rsvp.denodeify(fs.readFile);
  
  readFile('/etc/passwd', 'utf8').then(function (contents) {
    // do something with the file contents
  }, function (error) {
    // handle the error
  });

It is similarly easy to convert functions that expect other types of callbacks (read: not node-style callbacks where the first argument is always an error) to functions that return promises using deferreds.

domenicd4• 13 years ago

The real problem is the core NodeJS libraries aren't promise compliant. I don't know if there's a module that cleanly wraps all of these in their promise analogs but that'd be the best thing here.

There's a few of these in npm, but I think the best one is probably the pr package [1], which lets you do e.g. var fs = require("pr/fs") and then use Bluebird-promise returning versions of the fs methods.

[1] https://npmjs.org/package/pr

JoshGlazebrook• 13 years ago

Have you looked into bluebird[1]? It and most of the available promise libraries have a nodify-esque function where you can simple do this:

    var fs = Promise.promisifyAll(require("fs"));

And all of the regular methods in fs are now promisable. Q also seems to be one of the slowest[2] promise libraries there is. I'm not sure why so many people use it. That guy has a rather large benchmark table from a couple months ago as well and Q seems to be shockingly slow compared to the dozen or so other promise libraries out there.

1. https://github.com/petkaantonov/bluebird

2. http://spion.github.io/posts/why-i-am-switching-to-promises....

domenicd4• 13 years ago

Promises are in ES6. There is a prototype version of them in V8 behind the usual --harmony flag, although it is very bad and deviates from the standard quite a lot. E.g. it passes 221/879 of the Promises/A+ tests [1], which only test the then method; it also deviates on other methods, as noted in the article [2].

Node tends to keep up with V8 versions pretty well, so I anticipate by the time Node 0.12 is released the --harmony flag will enable the Promise global. (Hopefully by then the V8 team will have gotten their act together on standards compliance.) Node core though is pretty committed to the error-first callback pattern; that will be a longer shift, I think.

[1] https://twitter.com/promisesaplus/status/407721467778846720 [2]: http://www.html5rocks.com/en/tutorials/es6/promises/#toc-api

paulirish• 13 years ago

The implementation in Blink is now passing the Promises/A+ tests at 100% [1], and we'll be updating the V8 implementation accordingly. We want to be shipping the one in V8 ASAP, but as you note it needs some work, so we'll be addressing those issues and then getting it out the door very soon.

[1] https://twitter.com/ChromiumDev/status/413035115665575936

jeswin• 13 years ago

Broader adoption of JS on the server will only begin after ES6 generators land in Node. Due to the complexity of async code, writing JS on the server is not easy for the average team.

As of now, you could use Promises but it is still kind of messy without generators. Here is a simple example:

  #Without generators
  Credentials.get({ token })
      .then (credentials) =>
          User.get({ username: credentials.username })

  #With generators
  credentials = yield Credentials.get({ token })
  User.get({ username: credentials.username })

We use FaceBook's regenerator project to compile ES6 features down to Node's currently supported Javascript features. If you don't want to use the --harmony flag, you should really try it out. https://github.com/facebook/regenerator

phaer• 13 years ago

What are the advantages of compiling to ES5 instead of using --harmory?

arianvanp• 13 years ago

"Cross-platformness". Someone who wants to use your library and doesnt use harmony won't have to start his node process up with `--harmony` which is sort of a win I guess

ihaveqvestion• 13 years ago

In the submitted article, two callback methods are usually provided (one for success and another for failure). Is that possible when using generators? If so, what does that look like?

sciolistse• 13 years ago

In generator code you'd use try/catch to handle failure instead.

    try {
      var user = yield Users.get(1234);
      return user.name;
    } catch(ex) {
      // do whatever
    }

rather than..

    return Users.get(1234).then(
      function (u) { return u.name; },
      function (ex) { /* do whatever */ }
    );

camus22• 13 years ago

Good but can you yield from the global scope? if not you still need to write at least a function.

The hardest stuff in JS is that :

    function F(){throw "error"}

   try{setTimeout(F,1000)}catch(error){ console.log("error")}

we cant catch async errors outside the async callback , will generators fix this ? ( by the way , that's why you should never throw any error yourself in js ).

coderzach• 13 years ago

That's why node modules generally don't throw exceptions, but rather pass them as the first argument to the callback.

I think you can catch async errors if you call the throw method on the generator.

http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...

domenicd4• 13 years ago

You cannot yield from the global scope; you have to explicitly be inside a generator function. This isn't really a problem in practice except for one-off-scripts, since most modules don't have side effects but instead export functions (possibly generator functions). But for those one-off scripts it is indeed a bit awkward... you could imagine ways to get around it.

You can catch async errors with generators and promises; see e.g. the linked post, or http://jlongster.com/A-Study-on-Solving-Callbacks-with-JavaS...

masklinn• 13 years ago

we cant catch async errors outside the async callback , will generators fix this ?

You can inject an exception into a generator via the throw method[0], and it'll be raised at the yield, as if `yield` had thrown[1].

JS exception handling facilities are still crap, though.

[0] http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...

[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#in...

esailija6• 13 years ago

Cool trick with the redundant indentation which can be applied to generators too:

    #Without generators
    Credentials.get({ token })
        .then(credentials => User.get({ username: credentials.username }))

    #With generators

    var credentials = 
        yield Credentials.get({ token })
            User.get({ username: credentials.username })

omgtehlion5• 13 years ago

This might be not a very good example. But generators have more good features than just cleaner code.

1. You write code almost like synchronous one. You can use any control-flow statements you are familiar with. Just dont forget to turn a promise into real value with `yield` keyword.

2. How much times have you wrote such statements?

    X.prototype.foo = function() {
        var self = this;
        // or
        var that = this;
        this.bar().then(function(x) {
            that.baz(x);
        });
    };

or }.bind(this));

With yield you can just write your logic, not a boilerplate:

    X.prototype.foo = async(function*() {
        var x = yield this.bar();
        this.baz();
    });

omgtehlion5• 13 years ago

Completely agree!

This isn't a new thihg anyway, there are currently a lot of implementations, I even wrote one myself[1].

By the way, most (sane) libraries that use yield/await perfom a lot better, than vanilla promises. Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case.

[1] https://github.com/omgtehlion/asjs

esailija6• 13 years ago

That is not true at all about Promises/A+.

The requirement is to always calls handlers with an empty stack and in a certain order. In practice only naivest implementations would call platform scheduler for every `.then()`. Implementations can in all cases call the handlers synchronously when it would matter.

danabramov3• 13 years ago

Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case.

Actually I learned to embrace next-tickness of promises in Q because I don't have to think twice about different possible execution order depending on promise's current state.

I would honestly prefer immediate continuation to be opt-in. This worked well in .NET (its Task's ContinueWith has a flag called TaskContinuationOptions.ExecuteSynchronously that tells the scheduler “you can run me right away if you like”).

zsombor2• 13 years ago

Whilst thanks to lack of choice JavaScript is so important on the browser side, I would hope the Node infatuation would eventually pass where you do have a choice. Async calls in Node are done via explicit passing of closures. Callbacks, Promises etc all look bad compared to simple sequential instructions like:

   credentials := NewCredentials(token)
   User.findByName(credentials.userName)

The above is in Go, and it is just as fast if not more. Whilst all requests are on their own goroutines, the runtime will schedule them using the same efficient async io that does not need to be made visible as in JavaScript.

spion8• 13 years ago

  var withThis = (object, f) => function bound() {
    return f.apply(object, arguments);
  }

  function getCredentialsByToken(token) {
    return newCredentials(token)
    .then(withThis(User, User.findByName));
  }

spion8• 13 years ago

  var just = property => object => {
    var o = {}; 
    o[property] = object[property]; 
    return o;
  }

  Credentials.get({token})
    .then(just('username'))
    .then(withThis(User, User.get));

withThis available in a comment below.

ufo• 13 years ago

While I agree that using callback parameters instead of variable assignment is a bit fugly I think its not that bad and just takes think some time to get used to. For me, the thing that really benefits the most from generator syntax is structured control flow, specially loops: if you use generators you can use the existing JS for and while loop which is much better than doing the same with raw callbacks (manual recursion is basically gotos) or a an async library (promise-based or not, its going to be very verbose and still won't play well with "break" and "return" statements).

fishtastic• 13 years ago

I recently found that AngularJS has supports for promises. I replaced some of the callback code to use promises and it's a lot more readable.

Callbacks:

    Backend.CallA(param, function() { 
      aDone = true;
      if (aDone && bDone) { doC(); }
    });
    Backend.CallB(param, function() { 
      bDone = true;
      if (aDone && bDone) { doC(); }
    });

Promises:

    var promiseA = Backend.CallA(param);
    var promiseB = Backend.CallB(param);
    $q.all([promiseA, promiseB]).then(doC);

danabramov3• 13 years ago

IIRC Angular's promises are based on stripped down version of Kris Kowal's Q. You may want to check it out:

https://github.com/kriskowal/q

jeremya• 13 years ago

As of AngularJS version 1.2, the promises provider ($q) is fully Promises/A+ compliant.

http://blog.angularjs.org/2013/11/angularjs-120-timely-deliv...

davej• 13 years ago

Slightly off-topic but the new HTML5Rocks site is much more responsive and easier to read.

jbigelow762• 13 years ago

Agreed, it looks great. I was poking around the site hoping to find a link to a Bootstrap-esque code repository of the base HTML and CSS.

rcsorensen• 13 years ago

https://github.com/html5rocks/www.html5rocks.com

Is that what you were looking for?

The article linked looks to be at https://github.com/html5rocks/www.html5rocks.com/blob/master... .

tlrobinson2• 13 years ago

Fantastic! I don't know if promises are the ultimate solution to async programming, but they're a hell of a lot better than plain old callbacks.

arbesfeld• 13 years ago

Hopefully we will see ImageBitmaps soon:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

ajtaylor• 13 years ago

Unrelated to the article content, I just noticed the table of contents on the left side. The slow fade in/out when you mouse over it is perfect! It's fixed position so you always see it, yet it's totally unobtrusive while reading the article. Brilliant!

programminggeek• 13 years ago

Interesting. I found that TameJS or Iced CoffeeScript mostly solved the async terribleness problem in node, but you basically are using a non-standard toolchain at that point, and setting that up for a whole team is sort of absurd.

Also, I'm not fully convinced that node is worth the code complexity that all of these solutions bring with them when go or scala can give you better performance with much cleaner code.

pablovidal852• 13 years ago

Call me crazy, but I fail to see the improvement in this weird syntax and I've had enough. Go, there we go.

tlrobinson2• 13 years ago

Composibility and error handling.

pablovidal852• 13 years ago

I have that already with libraries like caolan/async and node.js convention of first-argument-error + callbacks. Now, of course I would like to have that features natively, but not at the cost of having more (ugly) syntax. My point is that if I have to learn new syntax, I would then use the time to learn a modern and efficient new programming language.

atrilumen• 13 years ago

I've been really enjoying ToffeeScript, which provides implicit continuations. It was trivial to implement coroutines on top of it: https://gist.github.com/luciangames/7776345.

It works very well if you bear in mind what's happening to the call stack. In my case, every call to pause! or wait! is scheduling a continuation to be called later by the game loop. If I'm not mistaken, the overhead of each continuation is just that of a closure.

It's very comfortable, coming from a background in Stackless Python, Lua, and Unity.

I wish more people would take a look at ToffeeScript.

kretor• 13 years ago

Are there tools that visualize code as a flowchart, like he did halfway through the tutorial?

JavaScript Promises: There and back again

Related Stories