Jonas

You are right that they look identical from inside the function, and that is precisely the design goal — the whole point of the syntax is that asynchronous code reads like sequential code.

The difference is entirely outside the function.

When your function hits await, it returns control to the runtime. The single thread is now free to do something else: handle an incoming request, respond to a click, run a timer callback, process another user's work. When the awaited operation completes, your function is resumed from where it stopped.

A truly blocking call would hold the thread for the whole duration. Nothing else runs. On a server that means one slow database query stops every other request; in a browser it means the page freezes and does not even repaint.

So await does block your function and does not block the thread. Those are two different things and the confusion between them is the entire question.

"It blocks your function, not the thread" is the sentence I needed six months ago. Everything else follows from it.

The concrete way to see the trade is to look at how the shrinking is bought.

Suppose you have data made of four symbols. Fixed-length coding gives each one two bits, so a thousand symbols cost two thousand bits regardless of content.

Now suppose one symbol is far more common than the others. Give it a one-bit code, and give the rarest ones three-bit codes. Common data now costs less than two bits per symbol on average — you have compressed it. But data that happens to be full of the rare symbols now costs more than two bits per symbol. You have not created anything; you have moved cost from likely inputs to unlikely ones.

That is the entire mechanism, and it makes the theorem obvious rather than surprising. Every bit saved on a common input is a bit spent on a rare one.

Worth adding that the redundancy objection assumes the client always sees your status code, and there are cases where it does not.

An intermediate proxy can replace the response. A gateway can produce its own 502 that never reached your service. A CDN error page has a status but no body of yours at all. In those situations, a body that carries its own outcome lets a client distinguish "your service said no" from "something in between produced this".

That argument is stronger for public APIs crossing many networks than for a service called by your own front end over one hop.

There is also a maintenance argument that is fatal in practice: detached descriptions rot faster than names.

A misleading name is at least visible at every use site, so somebody eventually fixes it. A description that only appears on hover is invisible during ordinary reading, so when the meaning changes, nobody updates it. Within a year you have confident, authoritative, wrong documentation attached to a variable — which is worse than a terse name, because people believe it.

This is the same reason comments explaining what code does are discouraged while comments explaining why are encouraged. The why does not change when you rename something; the what does.