async/await Under the Hood

The Async Function That Blocked the Event Loop

A developer writes this, fully expecting it to be "non-blocking" because they used async/await:

async function processItems(items) {
  for (const item of items) {
    await processItem(item); // each item takes 50ms of CPU work
  }
}

With 100 items, this takes 5 seconds. During those 5 seconds, the page is jank-free because... wait, no. The page freezes. Yep. await doesn't make CPU-bound work non-blocking. It only yields at await points, and processItem's 50ms of synchronous CPU work blocks the event loop just like it would without async/await.

Understanding what async/await actually does -- not what it looks like it does -- prevents this entire class of bugs.

The Mental Model

The Desugaring

Here's what's really going on. async/await is syntactic sugar over promises. Here's how the engine transforms it:

// What you write:
async function fetchData() {
  console.log('start');
  const response = await fetch('/api/data');
  const data = await response.json();
  console.log('done');
  return data;
}

// Conceptually equivalent to:
function fetchData() {
  return new Promise((resolve, reject) => {
    console.log('start');
    fetch('/api/data')
      .then(response => {
        return response.json();
      })
      .then(data => {
        console.log('done');
        resolve(data);
      })
      .catch(reject);
  });
}

Each await becomes a .then() that receives the resolved value and continues execution. The function's local variables are preserved across await points through a closure (or, in the engine, a generator-like state machine).

The Generator Connection

Before async/await was standardized, developers used generators with a runner function to achieve the same effect. This is actually close to how engines implement it internally:

// The generator approach (historical):
function* fetchDataGen() {
  console.log('start');
  const response = yield fetch('/api/data');
  const data = yield response.json();
  console.log('done');
  return data;
}

// Runner that drives the generator:
function run(generatorFn) {
  const gen = generatorFn();

  function step(value) {
    const result = gen.next(value);
    if (result.done) return Promise.resolve(result.value);
    return Promise.resolve(result.value).then(step);
  }

  return step();
}

run(fetchDataGen).then(data => console.log(data));

yield pauses the generator. The runner takes the yielded promise, waits for it, then resumes the generator with the resolved value. async/await does exactly this, built into the language.

What Happens at Each await

Let's get precise about what the engine does when it hits await expression:

1. Evaluate the expression — if it's not a Promise, wrap it in Promise.resolve()
2. Suspend the function — pop its frame off the call stack, save its state
3. Schedule a microtask — when the awaited promise settles, queue a microtask to resume
4. Return to the caller — the caller receives the async function's outer promise (still pending)
5. When the microtask runs — restore the function's state, push it back on the call stack, continue from after the await

Step through this to see exactly how await suspends and resumes:

The output is C, A, D, B. See the pattern? Everything before await is synchronous. Everything after await is a microtask. Once you internalize this, async/await ordering puzzles stop being puzzles.

await on Non-Promise Values

Here's a fun one -- you can await anything. Non-Promise values are wrapped in Promise.resolve():

async function f() {
  const x = await 42;      // Promise.resolve(42)
  const y = await 'hello';  // Promise.resolve('hello')
  const z = await null;     // Promise.resolve(null)
  console.log(x, y, z);     // 42 'hello' null
}

This means await 42 is not synchronous. It still suspends the function and resumes via a microtask. This is occasionally useful for intentionally yielding within an async function.

Error Handling with async/await

try/catch replaces .catch()

// Promise version
fetchData()
  .then(process)
  .catch(handleError);

// async/await version
async function run() {
  try {
    const data = await fetchData();
    await process(data);
  } catch (err) {
    handleError(err);
  }
}

try/catch in async functions catches both synchronous errors and rejected promises:

async function riskyOperation() {
  try {
    JSON.parse('{invalid}');      // synchronous throw — caught
    await failingFetch();          // rejection — also caught
    throwingFunction();           // synchronous throw — also caught
  } catch (err) {
    // Handles all three types
  }
}

The Unhandled Rejection Trap

If an async function throws and nobody awaits it or attaches .catch():

async function oops() {
  throw new Error('silent death');
}

oops(); // No await, no .catch() — unhandled rejection!

This triggers the unhandledrejection event in browsers and crashes the process in Node.js.

Production Scenario: Sequential vs. Parallel await

This is probably the most common async/await performance mistake in the wild:

// SEQUENTIAL: 3 seconds total (1 + 1 + 1)
async function loadDashboard() {
  const users = await fetchUsers();     // waits 1s
  const orders = await fetchOrders();   // then waits 1s
  const metrics = await fetchMetrics(); // then waits 1s
  return { users, orders, metrics };
}

// PARALLEL: 1 second total (all at once)
async function loadDashboard() {
  const [users, orders, metrics] = await Promise.all([
    fetchUsers(),    // starts immediately
    fetchOrders(),   // starts immediately
    fetchMetrics(),  // starts immediately
  ]);
  return { users, orders, metrics };
}

The sequential version awaits each fetch before starting the next. The parallel version starts all fetches simultaneously and awaits them together. If the requests are independent, the parallel version is always correct.

The Subtle Bug: Accidental Sequential

// This looks parallel but is SEQUENTIAL:
async function loadData() {
  const userPromise = fetchUsers();
  const orderPromise = fetchOrders();

  const users = await userPromise;   // OK so far
  const orders = await orderPromise; // This IS parallel... but only by accident
}

// The bug appears when you add error handling:
async function loadData() {
  try {
    const users = await fetchUsers();   // sequential — blocks here
    const orders = await fetchOrders(); // doesn't start until users finishes
  } catch (err) {
    // ...
  }
}

If you want parallel execution, always use Promise.all or Promise.allSettled. Don't rely on starting promises before awaiting them — it's fragile and error-handling doesn't compose well.

await in Loops

The way you use await in loops makes all the difference. Get it wrong and you're either needlessly slow or silently broken.

for...of with await — Sequential

async function processSequential(urls) {
  const results = [];
  for (const url of urls) {
    const res = await fetch(url); // one at a time
    results.push(await res.json());
  }
  return results;
}

Each iteration waits for the previous to complete. Use this when order matters or when you need to throttle requests.

Promise.all with map — Parallel

async function processParallel(urls) {
  const results = await Promise.all(
    urls.map(async url => {
      const res = await fetch(url);
      return res.json();
    })
  );
  return results;
}

All requests fire simultaneously. Use this when requests are independent.

forEach with await — BROKEN

// BROKEN — forEach doesn't await async callbacks
async function processBroken(urls) {
  urls.forEach(async url => {
    const res = await fetch(url);    // fires and forgets
    console.log(await res.json());   // this runs eventually, but...
  });
  console.log('done'); // this runs BEFORE any fetch completes!
}

forEach ignores the return value of its callback. Since async functions return promises, forEach gets back promises but doesn't await them. All fetches run concurrently with no error handling and "done" logs before any complete.

Common Mistakes

Challenge: Trace the Async Execution

Challenge: Async Ordering

async function first() {
  console.log('1');
  await second();
  console.log('2');
}

async function second() {
  console.log('3');
  await Promise.resolve();
  console.log('4');
}

console.log('5');
first();
console.log('6');

Key Rules