- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Fri, 26 Apr 2013 18:39:27 +0000
- To: David Bruant <bruant.d@gmail.com>, Mark Miller <erights@gmail.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
I think this is a really good description of the problems and possible solutions. Unfortunately, I think you underestimate the problems. > Where should this wrapping occur? Each library can add a check+convert to all surface API. It doesn't sound that hard (library authors can jump in to say I'm crazy here). It's not fun, and it's pretty hard. We do this daily with Node.js libraries. Creating duplicates of existing APIs, and keeping them in sync, sucks. I would go almost as far as to say that this results in people thinking that the W3C has invented yet another sucky callback API that they can't use in a composable way with their existing code. Hooray, back where we started... > Hopefully, that should work until an ecosystem (or several) built on top of platform promises emerge and new projects should be built on top of this new ecosystem. And, because of how the platform forced users to wrap platform promises, this seems unlikely. Why would they dedicate resources to build on top of a library that didn't feel fit to give them the time of day and integrate with them? Better to just keep using the ecosystem they already have, which doesn't cause such problems and doesn't need to be forked and rewritten for an outlier. We are no stranger to the W3C producing crappy APIs that we bury under wrapping layers as soon as possible and never see again (see: jQuery). It would be a shame if promises in the DOM turned out to be another one of those.
Received on Friday, 26 April 2013 18:40:12 UTC