Promises

Brendan Eich brendan at mozilla.com
Wed Nov 7 07:48:57 PST 2012


Alex Russell wrote:
> My plan, as a result, inverts yours:
>
>  1. Get "DOMPromises" done in order to fix some busted proposed API.
>     My current hope is WebCrypto who can both avoid a design
>     catastrophe and introduce a new, widely implemented API on a
>     relatively short timeframe
>  2. Once we have DOMPromises implemented, we advocate broader
>     use throughout DOM APIs.
>  3. Introduce ES7 Promises as a compatible subset of DOMPromises
>

I agree with this approach provided TC39 (not just you) keeps tracking 
and commenting. public-script-coord is not overused...

> In an ideal world we'd go your route (as we would have with 
> Object.observe() vs. Mutation Observers), but TC39 isn't known for 
> adding API quickly, no matter how popular or well-argued the case.

That's truthy for some good reasons: programming language over library 
expertise, less domain expertise at the core.

It's also kind of false, in that ES5 added a lot of API, but we ended up 
with regrets. You (broadly speaking; DOM/w3/web/sysAPI people) will too. 
Going fast inevitably means adding APIs with flaws that will be hard to 
fix if the APIs are adopted on the web. HTML5 has more than a few such 
APIs, even discounting IDL effects.

Chrome as well as other browsers will not want to break compatibility, 
so we'll be stuck with flawed APIs. The web standards process must keep 
on composting ;-).

Bottom line: it's a good thing for domain experts who also have good API 
chops to lead the way on DOMPromises. But do keep es-discuss (David, 
Domenic, et al.) and TC39 (tomvc, especially) in the loop. Probably we 
will meet in the middle, in ES7.

/be


More information about the es-discuss mailing list