I'd like to submit my promises talk for consideration as well :). I agree with Mariusz that once you get it you will never go back.
http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript On Sunday, July 1, 2012 2:55:05 PM UTC-4, Mariusz Nowak wrote: > > @Andy Async is just sugar for control flow written with plain callbacks > and promises address asynchronicity from very different angle. > In promises approach asynchronous state is represented with the object, so > instead of registering single callback, you get the object, which you can > pass to many different functions, or on which you can listen for value with > many different listeners. Promises also provide clean separation of success > and error flows. It's much more powerful than plain callbacks, but also > takes some time to get familiar with that. Once you get it, you will never > go back ;-) > I've once done introduction to promises speech. See > http://www.medikoo.com/asynchronous-javascript/ (promises starts at 16 > slide) > > -- > Mariusz Nowak > https://github.com/medikoo > http://twitter.com/medikoo > > > On Sunday, March 25, 2012 10:42:32 AM UTC+2, Andy wrote: >> >> *Note, I am not asking which tool is better, I am simply trying to >> understand the differences. >> >> *I'm trying to wrap my head around promises in node. Right now I'm >> writing all my code in callback soup. I am researching libraries and I >> found async <https://github.com/caolan/async> (duh) but I also found the >> horribly named but seemingly very popular q<https://github.com/kriskowal/q> >> . >> >> What I am trying to figure out is if these libraries are mutually >> exclusive. The async page mentions nothing about "promsies" and instead >> talks about "flow control." But it seems like both libraries are sugar for >> handling async function flow and callbacks. Do they both solve the same >> problem, or can / should they be used together? >> >> Take this example: >> >> async.waterfall([ >> function(callback){ >> callback(null, 'one', 'two'); >> }, >> function(arg1, arg2, callback){ >> callback(null, 'three'); >> }, >> function(arg1, callback){ >> // arg1 now equals 'three' >> callback(null, 'done'); >> } >> ], function (err, result) { >> // result now equals 'done' >> }); >> >> >> vs: >> >> Q.call(step1).then(step2).then(step3).then(step4).then(function (value4) { >> // Do something with value4}, function (error) { >> // Handle any error from step1 through step4}).end(); >> >> >> Both libraries are doing things in a series, and both are passing their >> results to the next function. Is there really any difference between the >> two results other than Q returning a promise that you can chain to with >> .then? >> >> Is async really just a more versatile q? Or are there reasons to use one >> and the other and they could be used together? >> >> And can you do parallel functions with promises? Or is that not what >> they're used for? (And if not, should you use async + q, or is there too >> much overlap?) >> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
