Re: Futures

On Mon, Apr 22, 2013 at 11:16 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> 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.
>


To be fair I don't think David is suggesting that these libraries won't be
used, just that the kind of promises that are produced and consumed will
coalesce in the presence of a platform standard. And in order for that
standard to solve the primary problem being discussed, `then` would have to
fall by the wayside.

FWIW I disagree with him -- I strongly suspect that by the time this were
to all go down and a stable polyfill existed there'd already be too much
then-demanding code in the wild. There probably already is. And at that
point it's __proto__ all over again -- the standard will have no choice but
to respect then and the problem cannot be fixed :-/