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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
