# Async (/academy/async)



Async is starting the kettle and answering the door.

`await fetch(...)` means "I'll come back when the water boils." The [runtime](/academy/runtime) can take other orders in the meantime. Sync would stand at the kettle and ignore the door — that is [latency](/academy/latency) you chose.

The slow part is almost never your TypeScript. It is the wait you do not control: a [database](/academy/database) query, someone else's [API](/academy/api), an email, a charge. The only question is whether the app freezes for that wait or keeps the lights on.

**You've felt both checkouts**

The bad Pay button goes dead. The page stops scrolling. You wonder if it took the money. That page stood at the kettle.

The good one says "working" and still behaves like a page. Same charge underneath. The room stayed open.

A [queue](/academy/queue) is async for whole [jobs](/academy/job) — "send the receipt after they close the tab." A Promise is async for one function. Both mean: don't block the line for work that is just waiting.

**The bug is using the water before it boils**

The most common async mistake: you fire the request, then read the result on the next line before it exists. Empty list. `undefined`. An [agent](/academy/agent) will swear the API is down. It isn't. The script forgot `await`.

When a model says it will go async so the UI stays alive, it is protecting you from a frozen demo. When it forgets to wait, you get a confident empty state. Paste the function. Ask: "Are we using the result before it arrives?"

At a hackathon, async the path the judge clicks — sign-in, save, pay. Leave the rest sequential if sequential is obvious. [KISS](/academy/kiss) still wins.

**What this unlocks**

Synchronous waits. Async walks off and comes back when the kettle clicks. The slow work did not get faster. The app stopped standing around for it.
