async/await

In short: async/await is sugar over Promises, not a different mechanism. An async function always returns a Promise. Inside it, await somePromise pauses that function — not the whole program — until the Promise settles, then hands back the resolved value, letting asynchronous code read top to bottom like ordinary synchronous code. A rejected awaited Promise becomes a thrown error, catchable with a completely normal try/catch.

The same Promise, read top to bottom

Compare this with the .then() chain from the last lesson — same operation, much flatter:

checkMug is an async function, so it returns a Promise automatically. Inside it, await checkStock("mug") pauses right there until that Promise resolves, then result holds the actual string — no .then() callback needed. It reads exactly like synchronous code, even though it isn't.

Catching a rejection with ordinary try/catch

await turns a rejected Promise into something catch already knows how to handle:

When checkStockStrict("sold-out-item") rejects, await re-throws that rejection as a regular JavaScript error at the point of the await — the surrounding try/catch catches it exactly the way it would catch a throw. No .catch() method call needed; it's the same error handling you already know.

Sequential awaits vs awaiting together

The trap: awaiting one thing at a time, when the steps don't actually depend on each other, makes independent work wait in line for no reason.

sequential doesn't start checking "notebook" until "mug" has fully settled — two waits, back to back. concurrent starts both checks immediately with Promise.all, so the total time is roughly one check's worth, not two. Use sequential awaits only when a later step genuinely needs an earlier result; otherwise, start independent work together.

Quick practice