4 ms·

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 nat

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.

esailija 12y ago
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.
- thomasfoster96 12y ago
  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.
Lazare 12y ago
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 https://esdiscuss.org/topic/promise-any The conclusion basically that yes it would be useful, but it'll have to be ES7 not ES6.
- domenicd 12y ago
  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.
  - thomasfoster96 12y ago
    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.
- thomasfoster96 12y ago
  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.

esailija 12y ago

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.

thomasfoster96 12y ago
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.

Lazare 12y ago

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 https://esdiscuss.org/topic/promise-any The conclusion basically that yes it would be useful, but it'll have to be ES7 not ES6.

domenicd 12y ago
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.
- thomasfoster96 12y ago
  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.
thomasfoster96 12y ago
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.