recommended flow control library?

[Davis Ford]

There does not appear to be a shortage of libraries out there that help with flow control.  I'm looking for something that is well tested, maintained, and has the capability to deal with parallel and sequential workflows - functional programming syntactic sugar is a plus...don't care about coffeescript, and documentation that is in coffeescript only is a minus.

https://github.com/joyent/node/wiki/modules#wiki-async-flow

I've been browsing a lot of these on github, and a number of them look good, but it is quite time consuming to investigate them all, so I'd love to hear any feedback from the group.  Are you using any of these (or other libs not listed) -- happy with them?  Any you would recommend?

Thanks in advance,

Davis

[ben]

https://github.com/dreamerslab/node.flow

I wrote this lib a while ago, it supports both parallel and sequential
flow control. It is fully tested, documented and has examples. I use
it everyday along with other libs, you might want to give it a try.

ben :)

> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Volkmann]

Many people, including me, recommend https://github.com/caolan/async.

---

R. Mark Volkmann

Object Computing, Inc.

--

[Tim Caswell]

I recommend not using one, but if you prefer to have a library for this, async is the most popular and quite robust.

[Jarka]

Well there are programming cases where you can not use async way.

On Saturday, 26 May 2012 22:59:17 UTC+3, Tim Caswell wrote:

I recommend not using one, but if you prefer to have a library for this, async is the most popular and quite robust.

On Sat, May 26, 2012 at 2:38 PM, Mark Volkmann <r.mark....@gmail.com> wrote:

Many people, including me, recommend https://github.com/caolan/async.

---

R. Mark Volkmann

Object Computing, Inc.

On May 26, 2012, at 1:54 PM, Davis Ford <davi...@gmail.com> wrote:

There does not appear to be a shortage of libraries out there that help with flow control.  I'm looking for something that is well tested, maintained, and has the capability to deal with parallel and sequential workflows - functional programming syntactic sugar is a plus...don't care about coffeescript, and documentation that is in coffeescript only is a minus.

https://github.com/joyent/node/wiki/modules#wiki-async-flow

I've been browsing a lot of these on github, and a number of them look good, but it is quite time consuming to investigate them all, so I'd love to hear any feedback from the group.  Are you using any of these (or other libs not listed) -- happy with them?  Any you would recommend?

Thanks in advance,

Davis

--
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 nod...@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

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to

nodejs+unsubscribe@googlegroups.com

[Joshua Holbrook]

+1 to async. We bundle it with flatiron's util library. :)

--Josh

>>> nodejs+un...@googlegroups.com

>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>> --
>>> 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 nod...@googlegroups.com
>>> To unsubscribe from this group, send email to

>>> nodejs+un...@googlegroups.com

>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>>
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to

> nodejs+un...@googlegroups.com

> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en



--

Joshua Holbrook
Engineer
Nodejitsu Inc.
jo...@nodejitsu.com

[Alan Hoffmeister]

+1 async
--
Att,
Alan Hoffmeister

2012/5/26 Joshua Holbrook <josh.h...@gmail.com>

[Roly Fentanes]

+1 async

[dolphin278]

Like what?

nodejs+un...@googlegroups.com

[Mariusz Nowak]

Be sure to check also: https://github.com/medikoo/deferred a very *functional* promise/deferred concept implementation.

[Oliver Leics]

I recommend using no flow control library, but I recommend to learn
how the async library does what it does.

If things are going to become a real mess, I recommend the
reorganization of the code.
If things are still a mess, well, start again from scratch :-)


The async library: npm install async - https://github.com/caolan/async

> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

--
Oliver Leics @ G+
https://plus.google.com/112912441146721682527

[deitch]

+1 for async. Only thing it is missing is a simple promise creation
functionality, but you have others for that.

On May 27, 9:40 am, Oliver Leics <oliver.le...@gmail.com> wrote:
> I recommend using no flow control library, but I recommend to learn
> how the async library does what it does.
>
> If things are going to become a real mess, I recommend the
> reorganization of the code.
> If things are still a mess, well, start again from scratch :-)
>

> The async library: npm install async -https://github.com/caolan/async
>
>
>
>
>
>
>
>
>
> On Sun, May 27, 2012 at 2:09 PM, Mariusz Nowak <mari...@medikoo.com> wrote:
> > Be sure to check also:https://github.com/medikoo/deferreda very

[babibu]

Why do you recommend using no flow control library?

On May 27, 3:40 pm, Oliver Leics <oliver.le...@gmail.com> wrote:
> I recommend using no flow control library, but I recommend to learn
> how the async library does what it does.
>
> If things are going to become a real mess, I recommend the
> reorganization of the code.
> If things are still a mess, well, start again from scratch :-)
>

> The async library: npm install async -https://github.com/caolan/async
>
>
>
>
>
>
>
>
>
> On Sun, May 27, 2012 at 2:09 PM, Mariusz Nowak <mari...@medikoo.com> wrote:
> > Be sure to check also:https://github.com/medikoo/deferreda very

[Oliver Leics]

On Mon, May 28, 2012 at 9:26 AM, babibu <wagener...@googlemail.com> wrote:
> Why do you recommend using no flow control library?

Because it's no rocket-science what libraries like async provide. They
are very helpful in the beginning, to get used to the async
programming style. But once you know how it works, you can just drop
the async-helper-library from your dependencies and deal for yourself
with all those callbacks with ease. Practice, well-known patterns and
modularization are the keys.

Fibers and promises are another story. They introduce new language
constructs to JavaScript. And if you need/want the functionality of
those constructs, you either have to extend 'normal' JavaScript for
yourself or you use one of the many libraries.

- o

[Mark Volkmann]

On Mon, May 28, 2012 at 7:43 AM, Oliver Leics <oliver...@gmail.com> wrote:
> On Mon, May 28, 2012 at 9:26 AM, babibu <wagener...@googlemail.com> wrote:
>> Why do you recommend using no flow control library?
>
> Because it's no rocket-science what libraries like async provide. They
> are very helpful in the beginning, to get used to the async
> programming style. But once you know how it works, you can just drop
> the async-helper-library from your dependencies and deal for yourself
> with all those callbacks with ease. Practice, well-known patterns and
> modularization are the keys.

A downside to dropping the async functions and dealing with the same
functionality yourself is that everyone who looks at your code has to
examine the code to familiarize themselves with what you are doing. On
the other hand, when many people see things like async.parallel or
async.waterfall, they immediately know what is happening. That's the
benefit of standardizing on a widely used library.

--

[Oliver Leics]

With or without using the async-library, everyone who looks at your

code has to examine the code to familiarize themselves with what you
are doing.

With or without using the async-library, you have to communicate what
you are doing.
Write proper comments (and document well!), use descriptive
function-names and use standard/well-known callback patterns.

- o

[Jake Verbaten]

A recent quora answer about flow control patterns might be helpful ( http://www.quora.com/JavaScript/What-are-known-javascript-design-patterns-for-asynchronous-programming/ )

It's a personal choice whether you use the primitives directly or abstract them lightly. The main question is "what abstraction is too heavy". I personally think half of async is too heavy, promises / deferreds / futures are too heavy, fibers are too heavy, etc.

[Xavi Ramirez]

Aync certainly has everything you'd ever want (and more), but I
personally find the API a bit overwhelming and at times verbose. For
example I dislike having to manually deconstruct an array to get the
results of two callbacks executed in parallell. Because of this, I
tend to use Step: https://github.com/creationix/step/

In addition to having a fairly minimal API, it has a solid test suite
and it's been used on million+ visitor/month sites for over a year
without issue. The only real downside is that the original Step been
more less abandoned. Luckily, a number of fork have popped up:

https://github.com/akidee/stepc
https://github.com/xavi-/two-step

None of them have been battle test quite as much as the original Step,
but they use the same test suite and are actively being worked on.

Hope this helps.

[Dominic Tarr]

if you write your own control flow library, you will learn enough so
that you never need one.

[dolphin 278]

Async.auto() avoids this problem, since you always have access to 'results' hash object that contains results of calculations, and you can access them by name.
---------
Boris Egorov
skype/gtalk/nickname: dolphin278
mobile: +7 905 728 1543

[Tim Caswell]

On Mon, May 28, 2012 at 5:50 PM, Xavi Ramirez <xavi...@gmail.com> wrote:

 

The only real downside is that the original Step been
more less abandoned.  

I prefer to think of it as "complete" not "abandoned" ;).  It still works just as well as the day I released it.  We're still writing ES5 code in node with callbacks.

Seriously though, Step has warts, async is fairly complicated, using nothing but js is generally quite verbose.  There is no perfect solution which is why I recommend people understanding how to do it themselves and then choose something that makes sense for each use case.

[Bruno Jouhier]

My take about it: flow control is not (or should not be) a library issue. It is a language issue.

The language has all the keywords that you need to do flow control (if, else, return, while, for, break, continue, throw, try, catch, finally, ....). These keywords let you express complex flow control very efficiently and elegantly, as long as you deal with sync code flows. If you can fix the language and restore the power of these keywords so that they can deal with both sync and async code flows then you win: no new API to learn, no extra noise, just simple and familiar JS code.

You also need a simple trick (with minimal syntax overhead) to parallelize stuff and express workflows but that's easy once you have fixed the language.

Bruno

On Saturday, May 26, 2012 8:54:13 PM UTC+2, Davis Ford wrote:

[Akzhan Abdulin]

Just read  http://www.infoq.com/articles/surviving-asynchronous-programming-in-javascript  - it's good interview about.

2012/5/26 Davis Ford <davi...@gmail.com>

--

[Davis Ford]

Thanks to everyone for all the great suggestions.  I appreciate the input from everyone.  I can also appreciate the suggestions on why not to use a library.  Personally, I have no problem using a library if it saves time and makes the code quicker and easier to write -- that's a personal preference, of course.  People build abstractions on top of software all the time for myriad reasons.  If that abstraction is simple and allows me to reach my end goal quicker, then I have no problem with that.

There are a billion examples of abstractions that allow people to work faster.  assembly -> C, jdbc -> hibernate, DOM -> jquery, javascript -> coffeescript  -- each case has its own characteristics and has pros/cons, and has its own learning curve.  I guess to each his own -- there must be something in general the async library is doing right, though, considering how widely adopted it seems, and the number of forks/watchers.

--

[Jeffrey Zhao]

+1

 

老赵 | Jeffrey Zhao
Blog: http://blog.zhaojie.me/
GitHub: http://github.com/JeffreyZhao/

--

[José F. Romaniello]

+1 fix the language. I think IcedCoffeeScript is a great thing, and very easy to use but i know most of people will disagree, thats the reason is not in coffee main repo.