I've described some in the post I linked at the beginning, and many many others have described similar things. I've cribbed these from TJ Holowaychuk's recent post and added some others:
* callbacks are not logical for expressing sequential logic
* you end up with deeply nested code when having many sequential actions
* you may get duplicate callbacks
* you may not get a callback at all (lost in limbo)
* you may get out-of-band errors
* emitters may get multiple “error” events
* missing “error” events sends everything to hell
* often unsure what requires “error” handlers
* “error” handlers are very verbose
* callbacks suck
* too many different libraries to "fix" callbacks that each have their own problems
* e.g. easy to lose errors in Q promises
* varying performance of various promises/async libraries
* "best" async library constantly changes
* callback style is the only common api, so you end up with wrappers for each library x library combination
* sometimes forget whether a function uses a callback, returns a promise, is a generator, returns a stream, returns something that looks like a promise
* some libraries may not call callback asynchronously
and more. Callbacks have gotten a reputation as a dead horse that people like to beat on.
var bakeCookies = async (function(cookie_mix) {
print("Baking cookies...");
var oven = new Oven(cookie_mix);
var cookies = await (oven.bake(15)); // bake for fifteen minutes
cookies.decorate();
return cookies;
});
It's plain JavaScript, concurrent, and works with plain node.js, unlike StratifiedJS.
4 comments
[ 3.5 ms ] story [ 28.7 ms ] thread* callbacks are not logical for expressing sequential logic
* you end up with deeply nested code when having many sequential actions
* you may get duplicate callbacks
* you may not get a callback at all (lost in limbo)
* you may get out-of-band errors
* emitters may get multiple “error” events
* missing “error” events sends everything to hell
* often unsure what requires “error” handlers
* “error” handlers are very verbose
* callbacks suck
* too many different libraries to "fix" callbacks that each have their own problems
* e.g. easy to lose errors in Q promises
* varying performance of various promises/async libraries
* "best" async library constantly changes
* callback style is the only common api, so you end up with wrappers for each library x library combination
* sometimes forget whether a function uses a callback, returns a promise, is a generator, returns a stream, returns something that looks like a promise
* some libraries may not call callback asynchronously
and more. Callbacks have gotten a reputation as a dead horse that people like to beat on.