3 ms·

Promises do 2 things: 1) Give the illusion that control has been returned to the caller. It hasn't, but it kinda looks like it. This is soothing for people who

Promises do 2 things: 1) Give the illusion that control has been returned to the caller. It hasn't, but it kinda looks like it. This is soothing for people who don't really like JavaScript all that much. 2) Provide a structured way of dealing with callback-oriented code. You don't have to think about in a function whether the callback should be that last parameter, the only parameter. You don't have to think about whether it should include an errback or if the error should instead be the first parameter of the callback. You just do it the way the promises library describes, so the interface is predictable. #1 is of no concern to me. #2 I feel pretty meh about. A consistent interface is nice, but I don't lose sleep over a library using callbacks in a slightly different way than I like, I just write an extra function or two to wrap it into the way I like and move on with my life. I don't have a problem with Promises per se, I just don't want a library I'm using to pick a winner and tact on an extra few k. Doesn't look like ES6 is going to pick a promises winner, so I probably will largely ignore it until ES7.

rektide 14y ago
Your casual ambivalence for #1 makes me think you don't appreciate the greatest value of promises: that they are values, objects. Returning control to the caller is half the story. Along with returning control- which indeed is what is happening, no illusion, if the promise is triggering a non-blocking routine- the promise itself is returned: that object is what makes promises great. We have no other object for an execution or process in JavaScript: a promise, the value it returns, is an object. Objects can be used and talked about inside JS. If there is no object, there's nothing to compute about. A promise is a first class execution that we can compute about.
- im3w1l 14y ago
  What about timeout ids? I think I am missing the point.
  - jasondenizac 14y ago
    timeout IDs are similar in a sense. By having the promise as an object, you can do neat things to modify program control flow as a separate concern from resolving a particular asynchronous operation. Sure, you can compose promises, just like you might with callback-oriented code. But you can also do neat things like await an object graph of mixed synchronous and promised values, eg: https://npmjs.org/package/resolved https://npmjs.org/package/resolved
masklinn 14y ago
An emergent property of #2 is that promises provide composition. In purely callback-oriented code composition tends to be a pain, whether it's chaining operation or synchronizing on multiple concurrent operations. > Doesn't look like ES6 is going to pick a promises winner Why would ES6 "pick a promises winner"? Promises don't need to be a language feature. (ES6 will probably lead to people using coroutines with promises mostly being an implementation detail of that, e.g. http://taskjs.org/ http://taskjs.org/)
- munificent 14y ago
  > Why would ES6 "pick a promises winner"? If they don't, the surrounding ecosystem is less likely to standardize on a single promise implementation. That means you'll have fragmentation where foo uses Futures and bar uses Promises so you have to use a bunch of Future<->Promise shims to get them to play together. This is actually something I think is really nice about Dart: Futures are baked into the core library so they are The Way(tm) to pass around asynchronous computations.
  - jasondenizac 14y ago
    Promise consumers have a very small interface to worry about, and in fact there are many interoperable implementations (Q, when, rsvp, etc). Unfortunately, jQuery is not one of those implementations, because rejections don't propagate. At any rate, JavaScript is not built around having a monolithic base library, and as others have pointed out, it would not make sense to have language level support for promises per se. However, I do agree that it would be great to have host APIs, for example, DOM, to make more widespread use of promises. In fact, WinJS for Windows 8 _does_ make use of promises in their async APIs.
  - masklinn 14y ago
    > If they don't, the surrounding ecosystem is less likely to standardize on a single promise implementation. There's no need for a single promise implementation as long as they all implement the same API, in this case CommonJS Promises/A. And for the most part they do and are interoperable.
rictic 14y ago
I wrote a ton of callback-oriented code, thinking similarly to you. Promises have come a long ways since then, and I tried out Q.js and discovered that I was missing out on a significant and powerful abstraction. The two things you're missing out on here are: #1 Promises have strong guarantees. A promise will be resolved at most once, and it will be either resolves successfully or unsuccessfully. This makes reasoning about them and composing them together much easier. For example, whenever I need to perform multiple async calls with callbacks I've always got to write a bit of repetitive error-prone boiler plate to wait for and combine their results. With a good promise library this is a one-liner using a well tested library function. #2 Error propagation. With callbacks most exceptions vanish into the ether, only catchable by window.onerror and friends. Propagating that promise up to the caller who can handle it is an enormous pain in the ass and requires repetitive error handling code everywhere if you want to be resilient. With promises an exception raised in a handler counts as the resulting promise failing, which can propagate up similarly to the way exceptions propagate with try/catch. Again, this makes writing reliable abstractions so much easier.
- taproot 14y ago
  #2 cannot be emphasized enough, I can't count the number of times this would have improved my code in a huge way.
- rektide 14y ago
  These two points seem to tack closely to the original article. They're certainly important characteristics about promises, but the fact that the promise is an object for the future, and can be composed and their exception handling can be composed, speaks to me of greatness. These things you mention are technical bullet points emphasizing components of that greater greatness.
gritzko 14y ago
I am also rather confused by that concept of 'real' objects you may 'pass around'. Those are wrapped callbacks, not real objects, you must keep that in mind anyway.

rektide 14y ago

Your casual ambivalence for #1 makes me think you don't appreciate the greatest value of promises: that they are values, objects. Returning control to the caller is half the story. Along with returning control- which indeed is what is happening, no illusion, if the promise is triggering a non-blocking routine- the promise itself is returned: that object is what makes promises great. We have no other object for an execution or process in JavaScript: a promise, the value it returns, is an object. Objects can be used and talked about inside JS. If there is no object, there's nothing to compute about. A promise is a first class execution that we can compute about.

im3w1l 14y ago
What about timeout ids? I think I am missing the point.
- jasondenizac 14y ago
  timeout IDs are similar in a sense. By having the promise as an object, you can do neat things to modify program control flow as a separate concern from resolving a particular asynchronous operation. Sure, you can compose promises, just like you might with callback-oriented code. But you can also do neat things like await an object graph of mixed synchronous and promised values, eg: https://npmjs.org/package/resolved https://npmjs.org/package/resolved

masklinn 14y ago

An emergent property of #2 is that promises provide composition. In purely callback-oriented code composition tends to be a pain, whether it's chaining operation or synchronizing on multiple concurrent operations. > Doesn't look like ES6 is going to pick a promises winner Why would ES6 "pick a promises winner"? Promises don't need to be a language feature. (ES6 will probably lead to people using coroutines with promises mostly being an implementation detail of that, e.g. http://taskjs.org/ http://taskjs.org/)

munificent 14y ago
> Why would ES6 "pick a promises winner"? If they don't, the surrounding ecosystem is less likely to standardize on a single promise implementation. That means you'll have fragmentation where foo uses Futures and bar uses Promises so you have to use a bunch of Future<->Promise shims to get them to play together. This is actually something I think is really nice about Dart: Futures are baked into the core library so they are The Way(tm) to pass around asynchronous computations.
- jasondenizac 14y ago
  Promise consumers have a very small interface to worry about, and in fact there are many interoperable implementations (Q, when, rsvp, etc). Unfortunately, jQuery is not one of those implementations, because rejections don't propagate. At any rate, JavaScript is not built around having a monolithic base library, and as others have pointed out, it would not make sense to have language level support for promises per se. However, I do agree that it would be great to have host APIs, for example, DOM, to make more widespread use of promises. In fact, WinJS for Windows 8 _does_ make use of promises in their async APIs.
- masklinn 14y ago
  > If they don't, the surrounding ecosystem is less likely to standardize on a single promise implementation. There's no need for a single promise implementation as long as they all implement the same API, in this case CommonJS Promises/A. And for the most part they do and are interoperable.

rictic 14y ago

I wrote a ton of callback-oriented code, thinking similarly to you. Promises have come a long ways since then, and I tried out Q.js and discovered that I was missing out on a significant and powerful abstraction. The two things you're missing out on here are: #1 Promises have strong guarantees. A promise will be resolved at most once, and it will be either resolves successfully or unsuccessfully. This makes reasoning about them and composing them together much easier. For example, whenever I need to perform multiple async calls with callbacks I've always got to write a bit of repetitive error-prone boiler plate to wait for and combine their results. With a good promise library this is a one-liner using a well tested library function. #2 Error propagation. With callbacks most exceptions vanish into the ether, only catchable by window.onerror and friends. Propagating that promise up to the caller who can handle it is an enormous pain in the ass and requires repetitive error handling code everywhere if you want to be resilient. With promises an exception raised in a handler counts as the resulting promise failing, which can propagate up similarly to the way exceptions propagate with try/catch. Again, this makes writing reliable abstractions so much easier.

taproot 14y ago
#2 cannot be emphasized enough, I can't count the number of times this would have improved my code in a huge way.
rektide 14y ago
These two points seem to tack closely to the original article. They're certainly important characteristics about promises, but the fact that the promise is an object for the future, and can be composed and their exception handling can be composed, speaks to me of greatness. These things you mention are technical bullet points emphasizing components of that greater greatness.

gritzko 14y ago

I am also rather confused by that concept of 'real' objects you may 'pass around'. Those are wrapped callbacks, not real objects, you must keep that in mind anyway.