JavaScript Promises: There and back again

Re:JavaScript Promises: There and back again by danabramov on Tuesday December 17, 2013 @05:56PM (#6924577)

>Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case.

Actually I learned to embrace next-tickness of promises in Q because I don't have to think twice about different possible execution order depending on promise's current state.

I would honestly prefer immediate continuation to be opt-in. This worked well in .NET (its Task's ContinueWith has a flag called TaskContinuationOptions.ExecuteSynchronously that tells the scheduler “you can run me right away if you like”).

[ Parent | on HN ]

Re:JavaScript Promises: There and back again by omgtehlion on Wednesday December 18, 2013 @04:01AM (#6926546)

If you use yield in JS you don’t have to think about execition order too. Because execution sequence will always be the same, and JS lacks real threading, so you won’t notice it anyway.

[ Parent | on HN ]

Re:JavaScript Promises: There and back again by danabramov on Wednesday December 18, 2013 @12:46PM (#6929087)

What about this kind of code?

    var x;

    promise().then(function (result) {
      x = result;
    }).done();

    x.doStuff();

This is a contrived example, and pretty stupid too. Still, if promises are always resolved on next tick, it will always fail. If promises may be resolved in the same tick, then you may miss the mistake.

A more real-world example is synchronization code like this[1]. Can you say at a glance if this code works fine both with resolved and pending promises? You'd have to check every `then`. You don't get this kind of problem with always-asynchronous promises.

In other words, it's a tradeoff between performance and introducing possibility of several different code paths, and it gets messier with non-trivial code.

  [1]: https://gist.github.com/gaearon/7930162

[ Parent | on HN ]