5 ms·

I don't understand your comment (or this is related to the lack of good introductory material noted in another comment). You can retrieve the results of promis

I don't understand your comment (or this is related to the lack of good introductory material noted in another comment). You can retrieve the results of promises in parallel, serially, or via some combination of both. That's part of their power versus straight callbacks which enforce a serial approach. Check out this link to q's documentation: https://github.com/kriskowal/q#combination https://github.com/kriskowal/q#combination

ufo 13y ago
TBH, both callbacks and promises are kind of similar when it comes to running things in parallel. In both cases you use the same sort of semaphore pattern and its something thats easy to hide behind a library function. function parallelCallbacks(cbs, onAllDone){ var nLeft = cbs.length; var results = [] var onOneDone = function(res){ results.push(res); nLeft -= 1; if(nLeft <= 0){ onAllDone(results) } } for(var i=0; i<cbs.length; i++){ cbs[i](onOneDone); } } parallelPromises([ function(){ return promise(10) }, function(){ return promise(20) } ).then(function(results){ ... }); parallelCallbacks([ function(onDone){ onDone(10) }, function(onDone){ onDone(20) } ], function(results){ ... });
- tlrobinson 13y ago
  One of the main differences is in error handling. Much like exceptions, errors are automatically propagated to the first error handler in the promise chain. With Node-style callbacks you need to explicitly check for errors and re-emit them at every stage. I also think promises' use of return values vs passing a callback as an argument is conceptually cleaner and easier to compose.
  - ufo 13y ago
    Absolutely correct, I ommited error handling to keeop the example simple but error handling is definitely more natural in a promise setting because you don't need to make your own error callback protocol. That said, I still feel that both promises and explicit callbacks kind of suck in their own way. Callback code is usually much more verbose and has bad error handling while promises are bad at "jumpy" control flow. When I last worked in a big JS project it got bad enough that I eventually wrote my own control flow library on top of the base Dojo promises we were using so nowadays if I had to work with a big JS project again I would definitely try to use of those tools that add async control flow to the language and compile doen to regular continuations (looks nice like promises, can use loops, break and return like regular JS and raw callbacks don't need extra runtime support)
_greim_ 13y ago
My main point is that Promises don't have any concept of parallelism; all() is specific to the Q library, not part of Promises/A+. Obviously that's the intent—low-level building blocks—but it leaves one feeling like Promises don't actually solve any hard problems. You still have to solve them yourself.
- ufo 13y ago
  But callbacks also don't have any concept of paralelism and its trivially easy to code all() yourself once and then forget about it. The hard problem that promises solve are 1. Its more similar to regular code versus explicit CPS (no pyramid of doom, use "return" to return values, can store promises in data structures or pass them around to other functions) 2. Error handling. Regular Javascript has try-catch blocks for exception handling but those don't work with async code. Promises let you use exceptions in async code without having to worry about error callbacks.
- jkrems 13y ago
  Promises/A+ is not a promise library. It's not a spec about "what should a promise library do". It's about interoperability - "how can I exchange data AND promises between libraries without relying on a shared library/on everyone using the same library for flow control?". Also the spec makes error handling non-surprising, I don't need to read through the docs of a library to know how errors propagate. It looks like your promise library would have been easy to make comply with the spec by just calling "onkeep" "then" (and maybe adapting a few minor details).

ufo 13y ago

TBH, both callbacks and promises are kind of similar when it comes to running things in parallel. In both cases you use the same sort of semaphore pattern and its something thats easy to hide behind a library function. function parallelCallbacks(cbs, onAllDone){ var nLeft = cbs.length; var results = [] var onOneDone = function(res){ results.push(res); nLeft -= 1; if(nLeft <= 0){ onAllDone(results) } } for(var i=0; i<cbs.length; i++){ cbs[i](onOneDone); } } parallelPromises([ function(){ return promise(10) }, function(){ return promise(20) } ).then(function(results){ ... }); parallelCallbacks([ function(onDone){ onDone(10) }, function(onDone){ onDone(20) } ], function(results){ ... });

tlrobinson 13y ago
One of the main differences is in error handling. Much like exceptions, errors are automatically propagated to the first error handler in the promise chain. With Node-style callbacks you need to explicitly check for errors and re-emit them at every stage. I also think promises' use of return values vs passing a callback as an argument is conceptually cleaner and easier to compose.
- ufo 13y ago
  Absolutely correct, I ommited error handling to keeop the example simple but error handling is definitely more natural in a promise setting because you don't need to make your own error callback protocol. That said, I still feel that both promises and explicit callbacks kind of suck in their own way. Callback code is usually much more verbose and has bad error handling while promises are bad at "jumpy" control flow. When I last worked in a big JS project it got bad enough that I eventually wrote my own control flow library on top of the base Dojo promises we were using so nowadays if I had to work with a big JS project again I would definitely try to use of those tools that add async control flow to the language and compile doen to regular continuations (looks nice like promises, can use loops, break and return like regular JS and raw callbacks don't need extra runtime support)

_greim_ 13y ago

My main point is that Promises don't have any concept of parallelism; all() is specific to the Q library, not part of Promises/A+. Obviously that's the intent—low-level building blocks—but it leaves one feeling like Promises don't actually solve any hard problems. You still have to solve them yourself.

ufo 13y ago
But callbacks also don't have any concept of paralelism and its trivially easy to code all() yourself once and then forget about it. The hard problem that promises solve are 1. Its more similar to regular code versus explicit CPS (no pyramid of doom, use "return" to return values, can store promises in data structures or pass them around to other functions) 2. Error handling. Regular Javascript has try-catch blocks for exception handling but those don't work with async code. Promises let you use exceptions in async code without having to worry about error callbacks.
jkrems 13y ago
Promises/A+ is not a promise library. It's not a spec about "what should a promise library do". It's about interoperability - "how can I exchange data AND promises between libraries without relying on a shared library/on everyone using the same library for flow control?". Also the spec makes error handling non-surprising, I don't need to read through the docs of a library to know how errors propagate. It looks like your promise library would have been easy to make comply with the spec by just calling "onkeep" "then" (and maybe adapting a few minor details).