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.
More information about the es-discuss