Write Better JavaScript with Promises | Hacker News Reader

Write Better JavaScript with Promises

davidwalsh.name

This was a helpful and informative writeup, but it hasn't really convinced me that I should use promises.

I currently use use callbacks and caolan/async on node.js, using in-place callbacks where simple and async methods where things get complex. It's been working very well so far, and it avoids my biggest issue with promises, which is that it seems I'd need all the modules I want to use to support promises, which they surely don't, and mixing two styles seems worse than picking a poison.

Maybe someone can show me why my reasoning is flawed, though.

I'm not a huge fan of promises on their own. I think they are clearer than straight callbacks, but it gets confusing as you do more complex things. However, they really start to shine when combined with generators. Being able to yield a promise makes code very clean and clear.

And you can always use something like bluebird's promisify if you're combining promises with existing callback code.

There are several promise libraries (the most promising among them seems to be Bluebird, though Q has some popularity as well), which can easily convert callback-style functions into promises. For example:

    var b = require('bluebird'), request = b.promisify(require('request'));
    request(...).then(...)

These libraries also have utilities for controlling callback flow -- e.g calling several promises in parallel, which is done in the article with jQuery's $.when, waiting until a certain number finish, etc

I hadn't heard of bluebird at all. Does it work for any library you require?

When I used promises for real in a section of my code processing data:

1) I found it hard to use mostly because of all the work I had to do to "lift" non promise code up into promises, before I could use them.

2) When chaining them, it wasn't clear how you would handle a "fan-out", where a piece of data generated an array, which you then had to process with callbacks.

3) Unless I inserted a fail() after every then(), it was hard to tell where exactly in the chain something failed, and the stack trace wasn't very helpful.

I suspect maybe I'm doing something wrong--that even though you can chain promises sequentially, you generally want to make functions using promises, that you can then chain? I still haven't seen well written promise code. Anyone got examples other than toy examples?

As long as the library follows the "function (err, data)" convention:

https://github.com/petkaantonov/bluebird/blob/master/API.md#...

It does work for any library that uses callbacks - a node library that uses callbacks but not the node js callback convention has a bug.

1) There is not much work in promisifying libraries, for example the entire redis library can be promisified using 2 lines:

    var Promise = require("bluebird");
    var redis = require("redis");
    Promise.promisifyAll(redis.RedisClient.prototype);
    Promise.promisifyAll(redis.Multi.prototype);

After those lines all redis client objects have promise-returning versions of the methods. E.g. `redisClient.getAsync()` is the promise-returning version of `redisClient.get()`

2) Mixing callbacks and promises will result in very ugly code, see 1) to avoid it.

3) Forget about .fail(), this is not how promise error handling works. Use `.catch()` like you would use try catch. In your case that means not using it at all - then a full stack trace is automatically logged. Try catch is meant to be used with expected errors like file not existing, not bugs.

>You've probably heard the talk around the water cooler about how promises are the future.

Just wait until the JavaScript developers learn about continuations!

BiwaScheme has call/cc

Reply on news.ycombinator.com