Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n
concurrent flows.
After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?
It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed many regions of code where
- synchronicity wouldn't introduce a performance bottleneck, and
- what would otherwise be an easy problem is made very difficult by the fact that everything must be phrased for the event loop.
For an example of this, try writing a function call that requires information from two separate HTTP API responses; I basically need to draw a diagram of what happens with async.waterfall
for a task that, given synchronicity, would've been solved with a trivial three-liner.
Easy things should be easy. Optimizations should be closeted until they're needed. Maybe I'm missing something here, some mechanism in node that allows opt-in synchronicity... dear node.js, is there such a thing? If not, why do you want to make many things harder than they need to be?
I don't think node.js will ever be a slam-dunk "first choice because it is easy and correct and consistent" system. In my mind it is a very pragmatic choice based on certain realities at the moment which only become compelling in combination and until something better arrives. Some of these include: same language as browser, v8 is very fast, the evented model has really proven itself superior in terms of concurrent connection efficiency for network servers (at least IMHO), the way npm works is vastly superior to all prior systems (pip, ruby gems, bundler, etc), the node community is building modern libraries in a way that (IMHO) is overall better than rubygems or pypi. Not that rubygems wasn't successful/effective, it's just that npm and the packages therein tend to be even better in being smaller, more flexible, easier to swap in and out, etc. Yes, asynchronous code is a big learning curve. No you should not go start converting your shell scripts to node.js just because. However, if you are writing a network server, node.js makes sense in many cases. But yeah if you need a CRUD app that you and 3 of your friends can use to share cookie recipes, the actual control flow coding will be easier in a synchronous launguage like Ruby or Python.