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?