This is tangential to the discussion, here, but if you want to make 3 simultaneous async requests, it's super easy with promises. Here's an example using bluebi

This is tangential to the discussion, here, but if you want to make 3 simultaneous async requests, it's super easy with promises. Here's an example using bluebird (https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird): Promise.all([async1, async2, async3]).then(function(results) { console.log('async1:', results[0]); console.log('async2:', results[1]); console.log('async3:', results[2]); }); or: Promise.all([async1, async2, async3]).spread(function(res1, res2, res3) { console.log('async1:', res1); console.log('async2:', res2); console.log('async3:', res3); }); With the co library (https://github.com/visionmedia/co https://github.com/visionmedia/co), it'd look like this: co(function*() { var results = yield [async1, async2, async3]; console.log('async1:', results[0]); console.log('async2:', results[1]); console.log('async3:', results[2]); })(); Until ES6 is available everywhere, the existing promises libraries are so mature and easy-to-use that I don't really see a problem with them. Bluebird will even promisify an entire module for you with `promisifyAll`, so mixing it with callback-based modules is typically trivial. I think that even though it relies on the use of third-party libraries like co, the generators solution is much easier to reason about than the proposed solution here. I can't find the source, unfortunately, but I remember reading somewhere that generators were actually designed with this use case in mind, so the claim that using them for async "requires hacking a language feature that was designed for an entirely different use-case" is false, if I'm remembering correctly.