                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of axk...@gmail.com designates 209.85.216.180 as permitted sender) client-ip=209.85.216.180;
MIME-Version: 1.0
In-Reply-To: <6543823.1059.1332664952796.JavaMail.geo-discussion-forums@pbnt10>
References: <6543823.1059.1332664952796.JavaMail.geo-discussion-forums@pbnt10>
From: Axel Kittenberger <axk...@gmail.com>
Date: Mon, 26 Mar 2012 08:55:57 +0200
Message-ID: <CABg07fvUu-3WUbcO47PihFGGCLiEuiAzxu-PCKFOd7mYbK4...@mail.gmail.com>
Subject: Re: [nodejs] trying to wrap my head around "promises" - async vs Q
To: nodejs@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1

AFAIK they should be working together, but why would you need two
times the same thing with differnt dependencies? Also note that there
isn't an established vocabulary what is a "promise", "future", "flow
control" and the differences.

There are even far more libraries just like this, and even yet more
solutions approaching the problem from different .

This is the usual experience, "node.js oh so great" --- a day later,
"OMG I can't handle all that callbacks, statemachine logics etc.". One
Week later: yet another syncronisation library has been submitted to
teh repository.

On Sun, Mar 25, 2012 at 10:42 AM, Andy <delvarwo...@gmail.com> 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
> (duh) but I also found the horribly named but seemingly very popular 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en