It doesn't have the "pyramid of Doom" feeling of the "traditional NodeJS" version, but it does not make it easy to follow the flow. A better approach, IMHO, would be to use a promise library like q [1]
Author here: I like promises and I think they have their uses but I think for most cases simply writing well structured and encapsulated code will make them superfluous. You also have the problem of working with APIs that don't return promises.
I think maybe you didn't understand why callback hell exists in node in the first place. Everything is evented in node, so that you get non-blocking IO and all the speed that comes with it. Which means, that by default you have callback hell. If you take away the evented everything nature of node, it's a single threaded, blocking dynamic language, which is to day much like traditional ruby or python code.
You can't just OOP everything in node because evented code breaks that. Once you touch a database or filesystem, you are in evented land, and all the callbacks that come with it. Saying you should just OOP things in Javascript is not wrong, but it doesn't work for node.
There are a few libs that make callback oriented things nicer, but they still kind of suck and OOP is not as much fun even with those tools in place.
I understand the evented nature of Node.js and I'm not taking that away. In the code example I gave I'm still using the async methods.
DirectoryScanner.scanLibraries = function(librariesRoot) {
// Asynchronous Function Callback function
// | |
fs.readdir(librariesRoot, this.onLibrariesDirRead.bind(this));
};
All I've done is pass in a bound method on an object as the callback function. OOP does work for Node as far as I can tell I broke nothing with my code, it's all async/evented...
Can you give me an example as to how my coding style would break Node? I'm genuinely confused.
1: https://github.com/kriskowal/q/