On Mon, Apr 22, 2013 at 8: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.
>
Hi Domenic, I just repeated it too:
> If [standard platform-provided ES promises] ever wins
> definitively, so that there are no remaining libraries of
> concern, it will no longer need the assimilation mechanisms
> that enabled that co-existence; but by then it will be too
> late to shed it.
I agree that Promises/A+ are too minimal, that DOMFutures does not solve
the problems that need solving, and that the Q API you link to is an
excellent start. But I'm actually more hopeful that, after a transition
period, a standard platform-provided ES7 promises along the lines of Q
might be good enough that other library needs can be built on it rather
than more directly on the underlying platform. Nevertheless, the
constraints imposed by this transition period remain AFAICT inescapable,
and so the conclusion -- assimilation -- remains the same.
>
> 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.
>
--
Cheers,
--MarkM