W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: Dean Landolt <dean@deanlandolt.com>
Date: Mon, 22 Apr 2013 11:31:32 -0400
Message-ID: <CAPm8pjq+5tDeD+-QwRpaOXSj9ZpjBvFoKc9+uQujfGfFCnnG3g@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: David Bruant <bruant.d@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, es-discuss <es-discuss@mozilla.org>
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 :-/
Received on Monday, 22 April 2013 15:32:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC