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. On Tue, May 29, 2012 at 4:02 PM, Bruno Jouhier <bjouh...@gmail.com> wrote: > 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: > >> 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<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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
