6 ms·

I have just started doing development in Node.js. Originally using the excellent caolan/async library (https://github.com/caolan/async https://github.com/caolan

by SeanDav 13y ago

I have just started doing development in Node.js. Originally using the excellent caolan/async library (https://github.com/caolan/async https://github.com/caolan/async) for handling synchronous situations. Now started moving towards Promises but finding it quite hard to locate any "Promises for Dummies" type guide. Most of the libraries like "q" etc (https://github.com/kriskowal/q https://github.com/kriskowal/q) just give you a list of functions to use and related syntax but I have yet to come across a guide that goes into detail as to exactly how and why you use certain functions. I am kind of figuring things out as I go along but if anyone here can point me to such guides, I would be most grateful.

domenicd 13y ago
I have given several talks, for which slide decks and one video are available: http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript http://www.slideshare.net/domenicdenicola/callbacks-promises... http://www.slideshare.net/domenicdenicola/promises-promises http://www.slideshare.net/domenicdenicola/promises-promises with video at http://www.youtube.com/watch?v=MNxnHbyzhuo http://www.youtube.com/watch?v=MNxnHbyzhuo http://www.slideshare.net/domenicdenicola/boom-promisesa-was-born http://www.slideshare.net/domenicdenicola/boom-promisesa-was... which is more inspirational and motivational than practical Otherwise, in the Q readme we try for a "graduated tutorial" approach; would welcome any feedback you have to make it more friendly. We try to relegate the "list of functions" to the API reference at https://github.com/kriskowal/q/wiki/API-Reference https://github.com/kriskowal/q/wiki/API-Reference
- SeanDav 13y ago
  Hi Domenic, Thanks for those links - I will check them all. There is another one of yours (co-speaker) that I thought was excellent: Redemption from Callback Hell (http://www.youtube.com/watch?v=hf1T_AONQJU http://www.youtube.com/watch?v=hf1T_AONQJU)
  - domenicd 13y ago
    Oh yes, I always forget about this one because it's not on my SlideShare, but you're right, it's really excellent! Michael did a great job putting that together and I was honored he invited me to share the stage.
tgriesser 13y ago
I recently wrote two Node.js libraries that use promises extensively, an Active Record style ORM http://bookshelfjs.org http://bookshelfjs.org and Query Builder http://knexjs.org http://knexjs.org. I actually didn't find a need for many of the higher level functions, outside of .then I'd typically stick to .all, .reject / .resolve, and occasionally .defer. The source should be fairly annotated and is structured similar to Backbone.js, so it might be useful to take a look through and see where/how those functions are being used.
DanielRibeiro 13y ago
James Coglan did a good introduction of promises on his Callbacks are imperative, promises are functional: Node’s biggest missed opportunity[1] (HN discussion here[2]). The author of Promises/A+ also wrote a nice blost post on his You're Missing the Point of Promises [3] Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well[4] [1] http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/ http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-... [2] https://news.ycombinator.com/item?id=5466872 https://news.ycombinator.com/item?id=5466872 [3] https://gist.github.com/domenic/3889970 https://gist.github.com/domenic/3889970 [4] http://en.wikipedia.org/wiki/Future_%28programming%29 http://en.wikipedia.org/wiki/Future_%28programming%29
- SeanDav 13y ago
  >Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well This is my problem - when I last formally studied Computer Science we never covered this. I think most, if not all, of the Promises libraries assume you have a background that covers this, which makes it harder for those of us who have to work out all this from scratch. Not that I am complaining - just an observation. Probably also harder for people like me that are not working with anyone who actually knows Node.js or Promises. The upside is of course that knowledge gained the hard way often sticks better, even if the process is more frustrating.
  - 1qaz2wsx3edc 13y ago
    People like you? People that haven't studied CS? Hmm, let me check, yup. I understand promises fully. Anywho. They are not hard to learn. Watch a few videos. James Coglan talks are excellent, watch twice even. Finally if you don't like a library, find another, see if the glove fits.
  - lightblade 13y ago
    I think promises are easy to understand. Lets start with the most basic element of a promise: the `then` method. It is so basic in fact, that the spec only covers on how this method should behave and nothing else. All the other functions that you see in the libraries (Q, whenjs, etc) just have a lot of combinator functions that's built on top of the `then` method. Take the `Q.all` for example, it functions the same `then` except it wait for all promises passed into to it to finish before continuing with its own `then`. So understanding how the `then` behaves is essential to understanding promises. IMO, the advantage of using promise is how composable it is. To achieve desired effect, you can take a few existing promise combinators, compose them together with just object/array literals and function calls. For example, the other day I needed a html form to submit with a load mask covering the form while waiting for the submission to complete. The problem is that this submission can take anywhere from 21ms to 1500ms to complete. In order to achieve good UX, I needed the load mask to be not just a flash in the extremely fast case, but also not taking more than necessary time to complete in the extremely slow case. So I did this... Q.all([ asyncFormSubmitReturnPromise(), Q.delay(500) ]).then(function() { // hide mask & other cleanup }) For comparison, to achieve the same effect using asyncjs... async.parallel([ function(callback){ asyncFormSubmit({ success: callback }) }, function(callback){ setTimeout(callback, 500) } ], function(err, results){ // hide mask and cleanup }) I want to mention another advantage with promises: it creates an uniformed interface that disregards whether the loading is synchronous or asynchronous. Say for example you're writing a select box widget that needs to populate the dropdown's content. Your widget can expose a method just called `load` and it takes a promise. Now whoever is calling your `load` method will have the total freedom to pass in a promise's already resolved or pending to be resolved. If you have the data at hand, it's just as easy to wrap it in a promise `Q.resolve(data)` and pass it in.
dclowd9901 13y ago
The thing about promises is their real power comes when you return them out of functions you run, thus causing any function to become async, and the promise being returned allows it to be used in a variety of ways: promisesFunc().done(function(){ // execute on completion } q.when(promisesFunc).then( function(){ // do stuff } ) It's nice to be able to treat something that is inherently asynchronous like it is inherently asynchronous. Feels good man.jpg. And just wait til you start mixing in generators (well, eventually).

by SeanDav 13y ago

domenicd 13y ago

I have given several talks, for which slide decks and one video are available: http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript http://www.slideshare.net/domenicdenicola/callbacks-promises... http://www.slideshare.net/domenicdenicola/promises-promises http://www.slideshare.net/domenicdenicola/promises-promises with video at http://www.youtube.com/watch?v=MNxnHbyzhuo http://www.youtube.com/watch?v=MNxnHbyzhuo http://www.slideshare.net/domenicdenicola/boom-promisesa-was-born http://www.slideshare.net/domenicdenicola/boom-promisesa-was... which is more inspirational and motivational than practical Otherwise, in the Q readme we try for a "graduated tutorial" approach; would welcome any feedback you have to make it more friendly. We try to relegate the "list of functions" to the API reference at https://github.com/kriskowal/q/wiki/API-Reference https://github.com/kriskowal/q/wiki/API-Reference

SeanDav 13y ago
Hi Domenic, Thanks for those links - I will check them all. There is another one of yours (co-speaker) that I thought was excellent: Redemption from Callback Hell (http://www.youtube.com/watch?v=hf1T_AONQJU http://www.youtube.com/watch?v=hf1T_AONQJU)
- domenicd 13y ago
  Oh yes, I always forget about this one because it's not on my SlideShare, but you're right, it's really excellent! Michael did a great job putting that together and I was honored he invited me to share the stage.

tgriesser 13y ago

I recently wrote two Node.js libraries that use promises extensively, an Active Record style ORM http://bookshelfjs.org http://bookshelfjs.org and Query Builder http://knexjs.org http://knexjs.org. I actually didn't find a need for many of the higher level functions, outside of .then I'd typically stick to .all, .reject / .resolve, and occasionally .defer. The source should be fairly annotated and is structured similar to Backbone.js, so it might be useful to take a look through and see where/how those functions are being used.

DanielRibeiro 13y ago

James Coglan did a good introduction of promises on his Callbacks are imperative, promises are functional: Node’s biggest missed opportunity[1] (HN discussion here[2]). The author of Promises/A+ also wrote a nice blost post on his You're Missing the Point of Promises [3] Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well[4] [1] http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/ http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-... [2] https://news.ycombinator.com/item?id=5466872 https://news.ycombinator.com/item?id=5466872 [3] https://gist.github.com/domenic/3889970 https://gist.github.com/domenic/3889970 [4] http://en.wikipedia.org/wiki/Future_%28programming%29 http://en.wikipedia.org/wiki/Future_%28programming%29

SeanDav 13y ago
>Promises are actually a part of a of a very well understood programming mechanism that involves Futures and Deferred as well This is my problem - when I last formally studied Computer Science we never covered this. I think most, if not all, of the Promises libraries assume you have a background that covers this, which makes it harder for those of us who have to work out all this from scratch. Not that I am complaining - just an observation. Probably also harder for people like me that are not working with anyone who actually knows Node.js or Promises. The upside is of course that knowledge gained the hard way often sticks better, even if the process is more frustrating.
- 1qaz2wsx3edc 13y ago
  People like you? People that haven't studied CS? Hmm, let me check, yup. I understand promises fully. Anywho. They are not hard to learn. Watch a few videos. James Coglan talks are excellent, watch twice even. Finally if you don't like a library, find another, see if the glove fits.
- lightblade 13y ago
  I think promises are easy to understand. Lets start with the most basic element of a promise: the `then` method. It is so basic in fact, that the spec only covers on how this method should behave and nothing else. All the other functions that you see in the libraries (Q, whenjs, etc) just have a lot of combinator functions that's built on top of the `then` method. Take the `Q.all` for example, it functions the same `then` except it wait for all promises passed into to it to finish before continuing with its own `then`. So understanding how the `then` behaves is essential to understanding promises. IMO, the advantage of using promise is how composable it is. To achieve desired effect, you can take a few existing promise combinators, compose them together with just object/array literals and function calls. For example, the other day I needed a html form to submit with a load mask covering the form while waiting for the submission to complete. The problem is that this submission can take anywhere from 21ms to 1500ms to complete. In order to achieve good UX, I needed the load mask to be not just a flash in the extremely fast case, but also not taking more than necessary time to complete in the extremely slow case. So I did this... Q.all([ asyncFormSubmitReturnPromise(), Q.delay(500) ]).then(function() { // hide mask & other cleanup }) For comparison, to achieve the same effect using asyncjs... async.parallel([ function(callback){ asyncFormSubmit({ success: callback }) }, function(callback){ setTimeout(callback, 500) } ], function(err, results){ // hide mask and cleanup }) I want to mention another advantage with promises: it creates an uniformed interface that disregards whether the loading is synchronous or asynchronous. Say for example you're writing a select box widget that needs to populate the dropdown's content. Your widget can expose a method just called `load` and it takes a promise. Now whoever is calling your `load` method will have the total freedom to pass in a promise's already resolved or pending to be resolved. If you have the data at hand, it's just as easy to wrap it in a promise `Q.resolve(data)` and pass it in.

dclowd9901 13y ago

The thing about promises is their real power comes when you return them out of functions you run, thus causing any function to become async, and the promise being returned allows it to be used in a variety of ways: promisesFunc().done(function(){ // execute on completion } q.when(promisesFunc).then( function(){ // do stuff } ) It's nice to be able to treat something that is inherently asynchronous like it is inherently asynchronous. Feels good man.jpg. And just wait til you start mixing in generators (well, eventually).