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

RE: Futures

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Mon, 22 Apr 2013 15:16:25 +0000
To: David Bruant <bruant.d@gmail.com>, Anne van Kesteren <annevk@annevk.nl>
CC: 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>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF4149F@BY2PRD0510MB354.namprd05.prod.outlook.com>
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:


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC