step

Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow. By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples). [0] https://github.com/caolan/async [1] https://github.com/creationix/step [2] https://github.com/caolan/async#control-flow edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-

The step library [0] does something similar for javascript. Step( function() { getURL1(this.parallel()); getURL2(this.parallel()); getURL3(this.parallel()); }, function(err, res1, res2, res3) { } ); [0] https://github.com/creationix/step

That's why you use flow control libraries such as https://github.com/substack/node-seq or https://github.com/creationix/step.

I've been using this: https://github.com/creationix/step While I wouldn't quite call it pretty, it keeps things at the same indentation level, and I can still use closures to maintain the illusion of a single "thread".

There are some nice libraries that ease the pain of callbacks to a certain degree. Async[1] (the waterfall method) and Step[2] come to mind. [1]: https://github.com/caolan/async [2]: https://github.com/creationix/step

I've worked on a single, medium-size app to date, but I think these might have an impact: - try Coffeescript. It may look strange at first but ends up way more elegant and readable - use [Step](https://github.com/creationix/step) to ease sequential async calls - visually organise your code (formatting, lined up declarations, well separated pieces of functionality). This can help a lot after you've moved on from one part of the codebase to another

There are many many attempts at solving this problem, both libraries and preprocessors. None seem to satisfy a large audience, most people seem to deal with the callback nesting and hope to avoid cases where it gets super ugly. I have a lot bookmarked on github, these are mostly libraries. https://github.com/coolaj86/futures https://github.com/substack/node-seq https://github.com/marcuswestin/fun https://github.com/creationix/step https://github.com/chriso/chain.js https://github.com/substack/node-chainsaw https://github.com/caolan/async https://github.com/kriszyp/promised-io https://github.com/kriszyp/node-promise https://github.com/technoweenie/node-chain-gang https://github.com/creationix/do https://github.com/willconant/flow-js https://github.com/creationix/conductor Some branches of CoffeeScript are also trying to ease the pain. Defe

Use Step, man: http://github.com/creationix/step

re: promises/chaining Check out: http://github.com/rsms/node-promise http://github.com/creationix/step http://github.com/creationix/do Did the value proposition of node fall apart? . re: multi-proc support From www.nodejs.org architecture design statement: "But what about multiple-processor concurrency? Threads are necessary to scale programs to multi-core computers. Processes are necessary to scale to multi-core computers, not memory-sharing threads. The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing. In future versions, Node will be able to fork new processes (using the Web Workers API ), but this is something that fits well into the current design."