What concurrency in Node.js could have been(notes.ericjiang.com)
notes.ericjiang.com
What concurrency in Node.js could have been
http://notes.ericjiang.com/posts/791
3 comments
So since it seems to me that this article entirely failed to mention why the callback pattern was harmful could someone else?
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.
* 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.
The point about fibers is incorrect. I posted a detailed comment on your blog.
It's plain JavaScript, concurrent, and works with plain node.js, unlike StratifiedJS.