I think eventual synchronicity of `then` is just theoretical problem and in practice we face much bigger issues when we force asynchronicity.
If we want to have "fast" asynchronicity, then we enter the problem of overloaded recurrence of next tick calls. It was already exposed by popular libraries: https://github.com/kriskowal/q/pull/259 https://github.com/tildeio/rsvp.js/issues/66 If we do it with setTimeout or setImmediate, then performance is significantly affected, and that diminishes the benefit of why we're actually using asynchronous calls. Promises while being aid for asynchronicity should not introduce any extra asynchronicity on it's own. Any optional next-tick resolution should be decided by user of library and not by library itself. If library forces it by design then we enter the world of issues like that one: https://github.com/cujojs/when/issues/135 I'm using promise library which few versions back moved away from forced next-tick resolution (mainly for performance reasons), and I didn't register any issues caused by that change. It actually confirmed me, that it's the way it should be. -- View this message in context: http://mozilla.6506.n7.nabble.com/Promise-Future-asynchrony-in-then-tp278846p279080.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
