await under the hood

One function pauses; the app does not

await pauses one async function until a value is ready. It does not freeze the page, the event loop, or the function that called it. The paused function remembers its local variables and the next line it must run.

1async function serve() {2  console.log("order taken");3  const food = await "burger";4  console.log("serving", food);5}6 7serve();8console.log("next customer");

Line 2 prints order taken. Line 3 reaches await "burger", so serve pauses. Line 7 is ordinary caller code, so it prints next customer. Later the continuation puts burger into food, and line 4 prints serving burger.

The real output is order taken, next customer, then serving burger. This is the same promise-job foundation from How promises work inside, but now the saved reaction resumes an async function rather than only calling a handler.

The await algorithm

The specification describes await as a short sequence of actions. First it evaluates the operand. Next it uses PromiseResolve: a native promise is used as it is, while a value or promise-like object is turned into a promise-shaped result that the rest of the algorithm can follow.

1async function serveOrder(order) {2  const food = await order;3  return "serving " + food;4}5 6serveOrder("burger").then(console.log);

Line 2 evaluates order and starts the await operation. The algorithm attaches a resume reaction and a throw reaction to its promise result. The async function suspends and line 6 gets a promise back immediately. When the value is fulfilled, a later job resumes line 2 and line 3 returns serving burger.

Rejection uses the same saved place with a different completion. If the awaited promise rejects, the later job throws the reason at line 2. A try/catch surrounding that await can handle it just like a normal throw. Await therefore keeps familiar error control flow while still leaving the current call stack.

1async function serveOrder(order) {2  const food = await order;3  return "serving " + food;4}5 6serveOrder("burger").then(console.log);Run

Native promises and tick markers

A microtask tick in this lesson means one promise job that we intentionally log. It is not a duration in milliseconds. Markers let us see relative order without turning a busy computer into a timing experiment.

1const nativePromise = Promise.resolve("tea");2 3async function waitForTea() {4  const drink = await nativePromise;5  console.log("native", drink);6}7 8waitForTea();9Promise.resolve()10  .then(() => console.log("tick 1"))11  .then(() => console.log("tick 2"))12  .then(() => console.log("tick 3"));

Line 1 creates an already fulfilled native promise. Line 4 awaits it. Calling waitForTea reaches that await and returns to the caller. Lines 8 through 11 queue marker jobs. In current engines, the tested output starts with native tea then prints tick 1, tick 2, and tick 3.

That first output does not mean await became synchronous. It means its resume job was queued before the marker chain. The caller had already returned from waitForTea before any of those logs happened. Add markers when debugging a real ordering question; do not infer order from a wall-clock measurement.

How V8 removed extra ticks

Older async-function implementations did extra promise wrapping work when awaiting a native promise. V8 7.2 described its faster async functions work: a native-promise await that had cost three microtask ticks could use one. The shorter path was later adopted into the specification.

History is useful, but this page does not pretend that an old engine is installed in your browser. The runnable snippet above proves only today's observable order on the runtime that executes it. It is a concrete reason that the native-promise path is worth distinguishing from a thenable path, not a benchmark claim about every past engine.

The important design result is modest: native promises can take a direct route because the engine knows their promise behavior. A custom object with a then method needs more careful adoption. The next two sections make that difference visible without requiring engine source code.

Async functions as resumable frames

A resumable frame is a useful model for the saved state of one async-function call. It includes values that will be used after an await and a continuation point: which part of the function should run when a job returns. Engines optimize and represent this in their own ways; the small object below is not engine source code.

1function makeServeFrame() {2  return { step: 0, order: "burger", food: undefined };3}4 5function resumeServe(frame, value) {6  if (frame.step === 0) {7    frame.step = 1;8    return "suspended";9  }10  frame.food = value;11  frame.step = 2;12  return "serving " + frame.food;13}14 15const frame = makeServeFrame();16console.log(resumeServe(frame));17console.log(resumeServe(frame, "burger"));

Line 2 creates a frame with step: 0. The first call on line 15 changes that step to 1 and returns suspended. The second call supplies burger, stores it in food, and returns serving burger. The real output has those two lines in that order.

This model makes one important fact visible: a later job does not restart the function at line 1. It resumes at the saved continuation. That is why a variable declared before await can still be used after it. It also explains why a local variable is not shared with a second, separate call to the async function.

Saving two waits

One async call can suspend more than once. Each resume moves the same activation forward. The frame keeps the first completed value while the second value is still pending, so a final line can combine both.

1function makeCheckoutFrame() {2  return { step: 0, drink: undefined, food: undefined };3}4 5function resumeCheckout(frame, value) {6  if (frame.step === 0) {7    frame.step = 1;8    return "wait for drink";9  }10  if (frame.step === 1) {11    frame.drink = value;12    frame.step = 2;13    return "wait for food";14  }15  frame.food = value;16  frame.step = 3;17  return frame.drink + " and " + frame.food;18}19 20const frame = makeCheckoutFrame();21console.log(resumeCheckout(frame));22console.log(resumeCheckout(frame, "tea"));23console.log(resumeCheckout(frame, "burger"));

Line 20 creates the frame. Line 21 reaches its first wait and prints wait for drink The next call stores tea in drink and prints wait for food The final call stores burger and prints tea and burger.

The step-through uses this same model with immutable snapshots. It is deliberately slower and more visible than an engine. Its value is that you can watch the saved variables and step change without guessing where a suspended function will continue.

1function makeCheckoutFrame() {2  return { step: 0, drink: undefined, food: undefined };3}4 5function resumeCheckout(frame, value) {6  if (frame.step === 0) {7    frame.step = 1;8    return "wait for drink";9  }10  if (frame.step === 1) {11    frame.drink = value;12    frame.step = 2;13    return "wait for food";14  }15  frame.food = value;16  frame.step = 3;17  return frame.drink + " and " + frame.food;18}19 20const frame = makeCheckoutFrame();Run21console.log(resumeCheckout(frame));22console.log(resumeCheckout(frame, "tea"));23console.log(resumeCheckout(frame, "burger"));

Awaiting ordinary values

await 42 is valid. It does not return 42 inline. PromiseResolve creates the fulfilled path, then the async function yields once so other already queued jobs can have a turn. This makes await behavior consistent whether a helper returns a value today or a promise tomorrow.

1async function waitForScore() {2  const score = await 42;3  console.log("value", score);4}5 6waitForScore();7Promise.resolve()8  .then(() => console.log("tick 1"))9  .then(() => console.log("tick 2"));

Line 2 awaits a number. Line 6 starts the function and line 7 adds a marker chain. The real output is value 42 then tick 1, then tick 2. The resume happened in a later job, but that job was queued before the marker chain.

This is helpful in app code. A cache function can return an already known product or a pending fetch promise, and a caller can always use await getProduct() The caller does not need two different control-flow shapes. It should still handle errors deliberately, because a rejected promise becomes a throw at the await.

Awaiting thenables

A thenable is an object or function with a callable then method. It is not required to be a native Promise Because that method is user-provided code, the promise machinery schedules a job to call it instead of simply treating it like a trusted native promise.

1const thenable = {2  then(resolve) {3    console.log("thenable then");4    resolve("tea");5  },6};7 8async function waitForTea() {9  const drink = await thenable;10  console.log("thenable", drink);11}12 13waitForTea();14Promise.resolve()15  .then(() => console.log("tick 1"))16  .then(() => console.log("tick 2"))17  .then(() => console.log("tick 3"));

Lines 1 through 6 define the thenable. Line 10 reaches its await. A later adoption job calls line 2, so the output first shows thenable then The marker job then prints tick 1 and the fulfilled continuation prints thenable tea before the remaining markers in the tested run.

The exact purpose of the extra boundary is safety and compatibility, not punishment. A thenable can come from a library, can throw, and can try to settle more than once. Promise resolution has rules for those cases. In day-to-day code, prefer native promises from APIs you own, and recognize thenables when a curious ordering difference appears.

Compare await inputs

Pick exactly one input: a value, a native promise, or a thenable. The playground prints the caller's synchronous line, two marker jobs, and the eventual resume. Reset restores the value selection and removes old output, so each comparison begins with an independent run.

1async function waitForScore() {2  const score = await 42;3  console.log("value", score);4}5 6waitForScore();7Promise.resolve()8  .then(() => console.log("tick 1"))9  .then(() => console.log("tick 2"));

Start with 42, then switch to a native promise, then choose the thenable. Look for one question rather than many: which jobs must happen before the suspended function can resume? The answer is clearer than trying to count invisible milliseconds.

What this changes in app code

You rarely need to write promise jobs yourself. The useful habit is to keep UI work small before an await, return promises to the owner that can handle failure, and remember that the rest of the screen can still receive work while one function is suspended.

1async function showOrder(order) {2  console.log("loading");3  const food = await order;4  console.log("show", food);5}6 7showOrder(Promise.resolve("burger"));8console.log("screen stays usable");

Line 2 prints loading before the wait. Line 3 pauses only showOrder Line 8 therefore prints screen stays usable before line 4 later prints show burger A real screen can render a loading state, accept unrelated input, or allow navigation while a request is pending.

This is not permission to ignore races. If a user starts two requests, each async call has its own frame and may resume in a different order. Give requests an owner, cancel stale work where an API supports it, or compare a current request ID before writing old data into the screen. The next lessons on microtasks and suspended frames add useful context.

Common misconceptions

• “await freezes JavaScript.” It suspends only the current async function.
• “await 42 is synchronous.” A plain value still resumes through a later promise job.
• “A thenable is a Promise.” It only has a callable then; its method is user code.
• “Tick count means elapsed time.” The markers reveal ordering, not milliseconds.
• “A saved frame is a browser frame.” It is the function's continuation state.

When output is surprising, write the synchronous code first. Then write each queued promise job in order. Finally ask which one resumes the async function. This small trace works better than describing all delayed code as “callbacks,” because it names the exact boundary.

Practice exercises

async function serve() {
  console.log("order taken");
  const food = await "burger";
  console.log("serving", food);
}

serve();
console.log("next customer");

async function waitForScore() {
  const score = await 42;
  console.log("value", score);
}

waitForScore();
Promise.resolve()
  .then(() => console.log("tick 1"))
  .then(() => console.log("tick 2"));

function makeCheckoutFrame() {
  return { step: 0, drink: undefined, food: undefined };
}

function resumeCheckout(frame, value) {
  if (frame.step === 0) {
    frame.step = 1;
    return "wait for drink";
  }
  if (frame.step === 1) {
    frame.drink = value;
    frame.step = 2;
    return "wait for food";
  }
  frame.food = value;
  frame.step = 3;
  return frame.drink + " and " + frame.food;
}

const frame = makeCheckoutFrame();
console.log(resumeCheckout(frame));
console.log(resumeCheckout(frame, "tea"));
console.log(resumeCheckout(frame, "burger"));

async function showOrder(order) {
  const food = await order;
  console.log("show", food);
}

showOrder(Promise.resolve("burger"));

Check your understanding

Use the three questions from the examples: what runs synchronously, what job gets queued, and what saved frame resumes later?

Key takeaways

• Await evaluates its operand, uses PromiseResolve, attaches resume and throw reactions, then suspends one async function.
• The caller gets control back while the suspended function waits for a later promise job.
• A native promise uses a short modern path; a thenable needs adoption work because its then is user code.
• Async functions act like resumable frames that retain local values and the next continuation point.
• Awaiting 42 still yields once, so code can use one async shape for values and promises.
• Tick markers show ordering in a specific snippet, not speed in milliseconds.

Coming next: The microtask queue, where those promise jobs wait before a host runs them.