On Mon, Apr 22, 2013 at 11:16 AM, Domenic Denicola < domenic@domenicdenicola.com> wrote: > 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: > > https://github.com/kriskowal/q/wiki/API-Reference > > 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. > To be fair I don't think David is suggesting that these libraries won't be used, just that the kind of promises that are produced and consumed will coalesce in the presence of a platform standard. And in order for that standard to solve the primary problem being discussed, `then` would have to fall by the wayside. FWIW I disagree with him -- I strongly suspect that by the time this were to all go down and a stable polyfill existed there'd already be too much then-demanding code in the wild. There probably already is. And at that point it's __proto__ all over again -- the standard will have no choice but to respect then and the problem cannot be fixed :-/Received on Monday, 22 April 2013 15:32:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC