Hacker News Reader

Comment by thomasfoster96 | Hacker News Reader

I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.

View on HN

The most popular[1] promises library (Bluebird) already has support for all of that, I think? .timeout() can be added to any promise chain to add a timeout, and there's .some(), .race(), .settle(), and .any(), etc. to handle various flavours of optionality.

[1]: Well, based on comments on HN and Reddit. Not sure about hard numbers, but it certainly gets talked about a lot.

I'm more interested in these sorts of features being in the ES6 Promises implementation. I expect that given a lot of new Web APIs are going to be using the native promises, these features being in the ECMAScript promises implementation is pretty important.

It doesn't matter at all what kind of promise flavor an API returns because promise implementations treat other implementations as interchangeable.

Even the ES6 Promises implementation supports this:

    Promise.all([{
        then: function(r) {
            r(3);
        }
    }]).then(function(result) {
        console.log(result);
    });

Here the plain object with then could have been any promise implementation, even jQuery, and it still works.

I do understand that, but it'd be very nice to be able to do some things like timeouts and the like, without loading quite a few kilobytes of another promise implementation.

For good or ill, it's not going to happen. ES6 is meant to have a VERY small promises API (although you can use a library like Bluebird as a wrapper around the native implementation to provide a better API). A more full features promises API will be coming in ES7.

See, for example, the discussion about adding a .any() method to the ES6 promise spec: https://esdiscuss.org/topic/promise-any

The conclusion basically that yes it would be useful, but it'll have to be ES7 not ES6.

The good news is ES7 is actually named ES2016, and will come out in one year.

The bad news is nobody has actually stepped up to champion such an addition, so it's looking unlikely that such a feature would be implemented in 2 browsers by the mid-2016 deadline necessary for it to be part of ES2016.

ES2016? As far as I knew, the ES7 name was being kept, but the ECMAScript script would be updated yearly, as opposed to the 5 or 6 years between ES5 and ES6.

Well ES6 is so far down the editing path that any additions now are pretty much impossible, but with ES7 coming about a year after ES6 it wouldn't be a long wait for a bigger Promises API to end up in the ECMAScript spec.

A 'timeoutable' promise could be represented as (pseudocode):

Promise.any([newTimeout(1000), otherPromise])

where:

newTimeout :: Milliseconds -> Promise

If the combination of these two isn't already in Promise implementations, it should be.

Bluebird already has the timeout function with similar semantics.

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

`when` and `bluebird` are both good libraries that supports both those features.

Have you looked at core.async in Clojure/ClojureScript?

Reply on news.ycombinator.com