RE: Futures

From: David Bruant [bruant.d@gmail.com]

> Especially given that it's only for a transitioning period where native (or polyfilled) have to cohabit with previous library promises?

This is a really bad misconception that you have repeated several times now.

DOM Futures, and possibly ECMAScript promises, are practically feature-less. They have `then`, `catch` sugar, a few static combinator methods, and that's it. If you want to do anything serious with promises, you're going to need a lot more than that. Check out the extensive API Q provides, for example:

https://github.com/kriskowal/q/wiki/API-Reference

In particular, I and teams I have worked on in real-world projects use `promise.finally`, the promise-for-object methods, the promise-for-function methods, and the utility methods literally every day. (To say nothing of the Node.js-interfacing methods.) Features like long stack traces have been invaluable for us. When.js has similar extra capabilities beyond the basics, and even RSVP (which is pretty lightweight) has `RSVP.hash` for shallowly settling any promise properties of an object. And the Q ecosystem is built around different fundamental primitives from DOM Futures which allow things like promise for remote objects, promise pipelining, and the like---use cases which are increasingly important.

To think that users who are accustomed to this level of flexibility are going to suddenly switch to DOM Futures/ECMAScript promises is very naive. More likely, those will be used alongside more full-featured promises returned from other parts of the system---forever, not just in some transition period. Thus, interop is going to be necessary for an ergonomic experience.

Received on Monday, 22 April 2013 15:17:09 UTC