Perhaps, but lacking a formal ToC and using the "review" that's listed on Amazon, I'm not seeing any indication of:
* ES5
* CommonJS
* promises/deferreds
* AMD/UMD/etc.
* NodeJS
* asynchronous concerns such as callback hell (and other focus areas as addressed by Async.js[1])
* packages
* HTML5
* the MV* hysteria
Granted, many of those aren't central to "JS" proper, they should at least bear a mention....but perhaps not. Just seems like what's covered is mostly run-of-the-mill JS fodder...
1. https://github.com/caolan/async#readme
In John Resig's ‘Secrets of the JavaScript Ninja’ has been releasedcaolan
async
JavaScript2010–2020
caolan / async
async
Async utilities for node and the browser
76Distinct people
81Mentions
2Explicit recommenders
28.1KGitHub stars
What to know before exploring
What it is
Async utilities for node and the browser
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development…
yid used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- creationix/step · linked in 3 of the same discussions
- kriskowal/q · linked in 2 of the same discussions
- nodejs/node-v0.x-archive · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year81 dated mentions
Observed mentions: 2010-10-12 01:05:50 UTC to 2020-01-21 18:21:07 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 18 | 1 | 17 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 21 | 0 | 21 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Async is a utility module which provides straight-forward, powerful functions for working with asynchronous JavaScript. Although originally designed for use with Node.js and installable via npm i async, it can also be used directly in the browser. An ESM/MJS version is included in the main async package that should automatically be used with compatible bundlers such as Webpack and Rollup.
A pure ESM version of Async is available as async-es.
For Documentation, visit https://caolan.github.io/async/
For Async v1.5.x documentation, go HERE
// for use with Node-style callbacks...
var async = require("async");
var obj = {dev: "/dev.json", test: "/test.json", prod: "/prod.json"};
var configs = {};
async.forEachOf(obj, (value, key, callback) => {
fs.readFile(__dirname + value, "utf8", (err, data) => {
if (err) return callback(err);
try {
configs[key] = JSON.parse(data);
} catch (e) {
return callback(e);
}
callback();
});
}, err => {
if (err) console.error(err.message);
// configs is now a map of JSON data
doSomethingWith(configs);
});
var async = require("async");
// ...or ES2017 async functions
async.mapLimit(urls, 5, async function(url) {
const response = await fetch(url)
return response.body
}, (err, results) => {
if (err) throw err
// results is now an array of the response bodies
console.log(results)
})
Read the full README on GitHubWhat Hacker News says
21 sourcesI don't think that this style is fantastic. This means that the pair of success/error callbacks is not reified, so there isn't a single object to pass around or manipulate. The result is that composition is harder. In order to create higher order asynchronous operations, like those in Async.js [1], you need to either pass two arguments or use an array or object to pair the error handlers together. This is particularly important if you want to return a pair of handlers from a function.
In the two-callback model, the most common way to reify the handler pair is with a {success:...,error:...} object. This is much better than function(x,y,z,success,error), but still has the problem that you now need to override two handlers if you want to wrap some completion logic, regardless of success/failure. For example, if you want to close a file handl
Read the rest
e, win or lose, you need to provide two new functions.
Composition greatly benefits from a singular object. The Node.js approach is the (err,data) callback. It's an extremely simple and successful approach. The other approach are promises/futures, which internally can be implemented with one or more callbacks, but provide a nice clean interface for composition. You could get that with success/error objects, but you're exposing the internals rather than an interface, like you should be doing. A good promise interface would let you choose an implementation without tying you to any particular callback model.
[1] https://github.com/caolan/async
I'm surprised the author doesn't mention the async library[0] to avoid callback hell. Also, he should probably have mentioned "continuation passing style"[1] as it is the term for that style of programming.
[0] https://github.com/caolan/async
[1] https://en.wikipedia.org/wiki/Continuation-passing_style
In Nonsense Accusations of Spaghetti Code Considered HarmfulSorry, but what do stars have to do with it? That's like saying DuckDuckGo should be allowed to rename itself as Google if they become more popular than Google. https://github.com/caolan/async had zero stars (i.e. didn't exist) back when I released async.js.
In Escape from Callback Hell: Callbacks are the modern gotohttps://github.com/caolan/async: 3293 stars on Github
https://github.com/eligrey/async.js: 15 stars on Github
Sorry, you lost this one.
In Escape from Callback Hell: Callbacks are the modern gotoThere's also this library: https://github.com/caolan/async
In Escape from Callback Hell: Callbacks are the modern gotoHow is this different from the async library? Are they both trying to solve the same problem or are they complementary? https://github.com/caolan/async
In Rsvp.jsNested callbacks are a problem that every javascript/node.js developer runs in to. A common library to help with this and other issues is Async: https://github.com/caolan/async
Sometimes, it's just better to give your functions names, and pull them out.
RSVP.js looks nice. Also, I like jQuery's implantation of promises specifically with the ajax function.
In Rsvp.jsHere's a few sources I really liked:
* Express - https://github.com/visionmedia/express - I don't like TJ's coding style, and general trolling of CoffeeScript, but this is a really great, clean and tiny codebase. (As well as all the connect middlewares - https://github.com/senchalabs/connect)
* Async - https://github.com/caolan/async - is very readable. Async is a great library for async ops handling in JS, and it's really neat seeing the implementation patterns.
* Ray - is a games DSL in Ruby - https://github.com/Mon-Ouie/ray - I love it, and it's a great read especially if you are interested in DSLs as much as I do.
* Jekyll - https://github.com/mojombo/jekyll - really helped me going forward with my ruby skills. It's nice, clean, commented, not too big, and useful.
* Redis - https://github.com/antirez/redis - lots of data structure imp
Read the rest
lementations. Antirez just writes C so nicely. anet.c has networking, TCP bits, ae.c is an event loop. Lots of great code there.
Node.js actually has two problems that I think will be very major issues for it in the long run:
- it's based on JavaScript, which is a crappy language (despite how nice V8 is)
- (OP's point) the async style is horrible for readability, which puts a tremendous toll on productivity (though many will deny it).
There are libraries like async (https://github.com/caolan/async) and streamline (https://github.com/Sage/streamlinejs) which try to eliminate #2. They are band-aids: the language itself must support asynchronous execution without callbacks.
Node has many advantages that make it really nice - V8 is awesome because of an interesting case of technological path dependence; the standard library has a lot of modules that take great advantage of asynchronous I/O; the standard library is very high quality; the community is great - but I think
Read the rest
the two issues above really leave room for another project to take the good parts and not the bad ones, and steal Node's thunder. It could be Go or Python (with some badly needed extra work on coroutines, concurrency, performance/adoption of pypy, etc), or something new.
You lose expressiveness, you lose maintainability, you lose peace of mind, and you get speed.
- I don't think my JS/CoffeeScript code is (significantly) less or more expressive and maintainable than the Python code I would have written. Use coffee if you want a whole bunch of language features, including some missing in Python. Oh, and a much cleaner way to write lambdas.
- Yes you need to understand async. It is of course, increasingly relevant with services and devices talking to each other. For example, in Microsoft's WinRT anything taking more than 50ms has to be async by design. After a while you might even wonder why async isn't the default way of doing most I/O.
- Flow control is hard in async, especially when you are getting started. But there are libraries which help, such as
https://github.com/caolan/async.
- The library approa
Read the rest
ch works for me and is a safer bet, but isn't the cleanest. If you are adventurous you could try iced-coffeescript, which introduces keywords to give you simpler code.
- Finally, you need to have a really good grip on JS.
The async nature of the language and platform is very easily managed with libs like https://github.com/caolan/async, I came from Django and to me, once I mastered the async nature and understood it, nodejs was a breath of fresh air.
In Why I think Node.JS is a terrible platformLooks like the author got upset that he needed to learn a platform in order to use it.
Another issue is that JavaScript doesn't really lend itself to continuation passing style, leading to ugly nested callbacks. There are many libraries that make this more manageable, like async: https://github.com/caolan/async
In Why I think Node.JS is a terrible platformWe use a whole bunch, some of the main ones:
- async => helpful async library https://github.com/caolan/async
- nodeinspector => node js debugging in a nice webkit UI https://github.com/dannycoates/node-inspector
- riakjs => for talking to Riak: http://riakjs.org/
- knox => S3 helper https://github.com/LearnBoost/knox
- optimist => helper lib for writing command line node apps (no more bash :) https://github.com/substack/node-optimist
- mocha => unit testing node code https://github.com/visionmedia/mocha
- emailjs => email helper https://github.com/eleith/emailjs
- uglifyjs => code minification https://github.com/mishoo/UglifyJS
In Show HN: clipboard.com, the best way to save anything online> The only technical problem where I've seen node be a unique solution is dealing with third party apis concurrently.
Use a library like Async, it makes this really easy.
https://github.com/caolan/async
(assume redis, mongo, facebook, and callback are all functions)
async.parallel([ redis, mongo, facebook], callback);
callback is called when all of the others are complete. If you have dependencies, like facebook needs the output of redis and mongo then use async.auto which will automatically run things in parallel and in the order you need them.
In The love and hate of Node.jsShowing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.