<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi all,</div><div><br></div><div>As some of you might now already, I'm not a fan of Promise libraries and the wrappers that (might) come with it or will be developed in the future - during my talks with people during my short time of a month here at Mozilla.</div><div>The gist at <a href="https://gist.github.com/mikedeboer/5305020">https://gist.github.com/mikedeboer/5305020</a> explains the first ten reasons why, but these are certainly not the only ones, jut the first ten reasons.</div><div><br></div><div>My concerns are not at all with the concept and A+ specification, but more with how the libraries that implement them are used and more often abused in code that I've had the pleasure to read and maintain the past couple of years. In this regard my concern also goes out to project tba and its maintainability in the coming years, as that will be its impact.</div><div><br></div><div>When being faced with a major refactor that involves 'asyncifying' a considerable number of APIs - I've been there on numerous occasions with teams I have lead - I always urged developers to take a step back and not focus on trying to marry asynchronous code flows with synchronous ones, but instead focus on how the goal can be accomplished with the language features at hand. In the case of Javscript, `yield` semantics did not coincide with co-routines, thus the need for helper libraries arose pretty quickly.</div><div>If a projects' goal is to keep its iteration in sync with the pace of innovation of language design, than it is of great importance to keep the level of abstraction as lean as possible. In practice this meant that using a Promise library moves away too much from the structure of language.</div><div><br></div><div>Another positive side-effect of this focus was that asynchronous code <i>looked</i> substantially different from synchronous code. In practice this meant that the mental model of the engine the code is running on top of takes notice of code running in an event loop, out-of-process or in multiple threads. Continuous awareness of this fact obviously reduces the chance of introducing race-conditions.</div><div><br></div><div>In the case of JS, Iterators/ generators, first-class lambdas and arrow syntax (and more) all will greatly reduce the amount of code required for asynchronous flows. A simple convention to reserve the first argument to a callback for errors has the positive side-effect that errors are never discarded or 'forgotten' and always bubble up to the callee.</div><div><br></div><div>If it matters, my background is that of working on enterprise-scale NodeJS backends for over two years at Cloud9 IDE and in-browser JS for over eight years. For some reason, Promise libraries never caught on in the NodeJS ecosystem, I hope you now understand why.</div><div><br></div><div>I am pretty sure this ship has sailed already, in which case my story will just serve as a big fat 'I told you so' in two years or so from now :) And that's perfectly fine!</div><div><br></div><div>Have fun!</div><div><br></div><div>Mike.</div><br><div><div>On Apr 5, 2013, at 11:26 AM, David Rajchenbach-Teller <<a href="mailto:dteller@mozilla.com">dteller@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">As project Async & Responsive (tba) will largely depend on promises, I<br>would like to try and wrap this up quickly.<br><br>So far, it looks like the only reason for adopting *deferred* execution<br>that was actually defended is that, in simple cases (arguably race<br>conditions), their behavior is easier to predict syntactically. As far<br>as I am concerned, there is no good reason to rely on a specific<br>resolution of race conditions – doubly so since Task.js makes it trivial<br>to avoid the race conditions in all the meaningful cases that I can<br>imagine. As pointed out half-jokingly by Gps, we can even introduce<br>fuzz-testing to root out some race conditions. That might actually be<br>simple.<br><br>So, here is my proposal:<br>1. promises remain in add-on SDK, with the process outlined by Mossop;<br>2. get Paolo's implementation of promises finished and landed, confirm<br>that it solves the issues we have with stack explosion;<br>3. progressively (certainly quickly) add support for debugging options;<br>4. if we believe that developers will depend on subtleties of evaluation<br>order, work on fuzz-testing promises;<br>5. provide a simple wrapper to defer execution of a promise.<br><br>Best regards,<br> David<br><br>-- <br>David Rajchenbach-Teller, PhD<br> Performance Team, Mozilla<br>_______________________________________________<br>firefox-dev mailing list<br><a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>https://mail.mozilla.org/listinfo/firefox-dev<br></blockquote></div><br></body></html>