Why I avoid async/await
Whatever your stance on async/await, I’d like to pitch to you on why, in my experience, async/await tends to make code more complicated, not less.
The utility of the async/await feature in JavaScript rests on the idea that asynchronous code is hard and synchronous code, by comparison, is easier. This is objectively true, but I don’t think async/await actually solves that problem in most cases.
Lies, damned lies, and async/await
Lies, damned lies, and statistics
One of the metrics I use for determining whether I want to use a given pattern is the incentives it promotes. For instance, a pattern may be clean, terse, or widely used, but if it incentivizes brittle or error-prone code, it is a pattern I am likely to reject. Often these are called footguns, because they are so easy to shoot oneself in the foot with. Like almost everything, it’s not a binary whether something is a footgun or not. It all exists on a spectrum, so how much of a footgun is often a better question than whether it is one or not.
On the footgun scale of 0 to with, async/await falls somewhere in the neighborhood of switch¹, so I have a few issues with it. For one, it is built on a lie.
Async/await lets you write asynchronous code like it is synchronous.
This is the common selling point. But for me, that’s the problem. It sets your mental model for what is happening with the code on the wrong foot from the start. Synchronous code may be easier to deal with than asynchronous code, but synchronous code is not asynchronous code. They have very different properties.
Many times this is not a problem, but when it is, it’s very hard to recognize, because the async/await hides exactly the cues that show it. Take this code as an example.