How async code is compiled down

What compiled down means

Modern JavaScript engines understand async, await, and generators. Older browsers did not. A transpiler is a tool that rewrites newer source code into older JavaScript while trying to keep the same visible behavior.

The rewrite does not make time disappear. It represents each pause explicitly. Local values need a place to wait, a label needs to say where execution should continue, and a promise callback needs to restart the work when a result arrives.

This continues from the microtask queue. That lesson explains where promise jobs wait. This lesson shows the extra JavaScript a build tool can create before those promise jobs get involved.

A generator pauses at yield

Start with a generator because it makes pausing visible. A generator function has a star after function. Calling it creates an iterator, but does not run the body all the way through.

1function* makeTea() {2  yield "boil water";3  yield "add tea";4  yield "pour";5}6 7const tea = makeTea();8console.log(tea.next().value);9console.log(tea.next().value);10console.log(tea.next().value);

Line 1 declares the generator. Lines 2 through 4 each pause at yield. Line 7 creates one generator object. Lines 8, 9, and 10 call next(), so the console prints boil water, add tea, and pour in that order.

A call to next() returns an object such as { value: "boil water", done: false }. The value is the pause point's message. The done flag stays false until the generator has no more work.

1function* makeTea() {2  yield "boil water";3  yield "add tea";4  yield "pour";5}6 7const tea = makeTea();Run8console.log(tea.next().value);9console.log(tea.next().value);10console.log(tea.next().value);

Generators as state machines

A state machine is ordinary code that remembers its current step and chooses what to do next. It is a useful model for a generator because a generator must remember which yield it reached before it pauses.

1function makeTeaMachine() {2  let state = 0;3  return {4    next() {5      switch (state) {6        case 0: state = 1; return { value: "boil water", done: false };7        case 1: state = 2; return { value: "add tea", done: false };8        case 2: state = 3; return { value: "pour", done: false };9        default: return { value: undefined, done: true };10      }11    },12  };13}

Line 2 starts the sticky note at state 0. The first next() takes line 6, returns boil water, and changes the saved state to 1. The second call takes line 7. The third takes line 8. A fourth call reaches the default branch and reports done.

This is a teaching model, not literal engine source. Real engines have optimized internal representations. The important connection is simple: a pausable function needs saved state, and a switch is one direct way to express saved state in ordinary JavaScript.

1function makeTeaMachine() {2  let state = 0;Run3  return {4    next() {5      switch (state) {6        case 0: state = 1; return { value: "boil water", done: false };7        case 1: state = 2; return { value: "add tea", done: false };8        case 2: state = 3; return { value: "pour", done: false };9        default: return { value: undefined, done: true };10      }11    },12  };13}

Compare generator and machine

The two versions look different inside, but they can offer the same outside behavior. Each call gets the next tea instruction. The model also reveals a number that a normal generator keeps hidden: its current state.

1function* makeTea() {2  yield "boil water";3  yield "add tea";4  yield "pour";5}6 7const tea = makeTea();8console.log(tea.next().value);9console.log(tea.next().value);10console.log(tea.next().value);

1function makeTeaMachine() {2  let state = 0;3  return {4    next() {5      switch (state) {6        case 0: state = 1; return { value: "boil water", done: false };7        case 1: state = 2; return { value: "add tea", done: false };8        case 2: state = 3; return { value: "pour", done: false };9        default: return { value: undefined, done: true };10      }11    },12  };13}

Try one call first. Both versions return boil water, while the machine saves state 1. Try three calls to reach pour. Try four calls to see done: true. Reset returns the comparison to its first call.

A compiler can choose different generated shapes, but it needs this same information somewhere. It must know the next label, preserve locals that will be read later, and return or schedule the next result without repeating earlier steps.

Regenerator and async-to-generator

Regenerator is the name commonly used for Babel's generator transform and runtime support. In plain words, it rewrites a generator body into a switch over a saved label, often named context.next, while saving values that later steps still need.

1// Simplified sketch of Regenerator output; not runnable by itself.2function makeTea(context) {3  while (1) switch (context.next) {4    case 0: context.next = 2; return "boil water";5    case 2: context.next = 4; return "add tea";6    case 4: return context.stop("pour");7  }8}

This sketch is deliberately simplified and is not runnable by itself. Line 3 reads the next label. Lines 4 through 6 select a branch, set the following label, and return a value. Real generated output also handles errors, return, throw, and more complex control flow.

Async-to-generator is the next layer. It rewrites an async function into a generator whose yielded values are promises. A small helper drives that generator: when a promise settles, it resumes the generator with the settled value.

1async function makeOrder() {2  console.log("start order");3  const item = await Promise.resolve("tea");4  console.log("serve " + item);5}6 7makeOrder();

Line 2 prints before the pause. Line 3 awaits a promise for tea. When that promise settles, line 4 prints serve tea. The next section builds the tiny helper that preserves that order using a generator.

A tiny async-to-generator runner

The runner is small because the promise already knows how to schedule its continuation. It starts the generator, checks whether it is done, and otherwise waits for the yielded promise before calling next(value) again.

1function run(genFn) {2  const iterator = genFn();3  function advance(value) {4    const step = iterator.next(value);5    if (step.done) return Promise.resolve(step.value);6    return Promise.resolve(step.value).then(advance);7  }8  return advance();9}10 11function* makeOrder() {12  console.log("start order");13  const item = yield Promise.resolve("tea");14  console.log("serve " + item);15}16 17run(makeOrder);

Line 2 creates the iterator. Line 4 resumes it. Line 5 ends the outer promise when the generator finishes. Line 6 wraps the yielded value as a promise and calls advance after it settles. Lines 11 through 14 are the lowered function body: it yields the promise, then receives the settled item on a later resume.

The real async function and this runner print the same order: start order followed by serve tea. The test runs both snippets with asynchronous snippet support so this claim comes from real promise scheduling, not a hand-written expected string.

Coroutines keep their local state

A coroutine is a function that can pause and later resume while keeping its local state. The word describes the behavior, not a particular syntax. A generator is a coroutine you drive with next(); an async function is a coroutine promise machinery drives after awaited work settles.

1function* countOrders() {2  let order = 1;3  while (order <= 3) {4    yield "order " + order;5    order += 1;6  }7}8 9const orders = countOrders();10console.log(orders.next().value);11console.log(orders.next().value);

Line 2 creates the local order once. Line 4 yields order 1. When line 10 calls next(), execution returns after that yield, increments the same local variable on line 5, and prints order 2. It did not start at line 1 again.

This is why generated output has to preserve locals. In the async example, the eventual item becomes a value available after the pause. A state-machine transformation stores enough information to make the later branch behave as if the original frame stayed open.

The cost of down-leveled async

Down-leveling solves a compatibility problem, but it adds code. A short native async function can become a generated generator or switch, a runner helper, promise continuations, saved locals, and sometimes a Regenerator runtime shared across the bundle.

1async function saveOrder(order) {2  const receipt = await send(order);3  return receipt.id;4}5 6// Older targets can add a runner, a generator body,7// saved state, and sometimes a Regenerator runtime.

Line 1 is compact native source. Line 2 pauses for send(order). A legacy transform must represent that pause and the later receipt local. The comments name the extra pieces without pretending that every compiler emits identical code.

There can be extra function calls and allocations at each represented pause. Debugging generated branches is harder because source line 3 may become several generated locations. Source maps help connect generated output back to the code you wrote.

Choosing your output target

Do not lower syntax by habit. First decide which browsers, embedded webviews, or runtimes your product must support. Modern browsers support async and await natively, so a modern target can keep the clear source you wrote.

A project with older support needs may accept generated helpers and a runtime. That is a valid trade-off when it lets users run the product. The important part is making the target deliberate, then checking output and bundle size instead of relying on a slogan about performance.

• Set browser support targets before comparing bundle output.
• Inspect the generated code when a stack trace looks unfamiliar.
• Keep source maps available for development and production debugging policy.
• Read transpilers and polyfills for the compatibility decision itself.
• Use native async where the supported audience can run it.

This does not mean native output is always best for every deployment. It means compatibility code should answer a real audience need, and its bundle and debugging cost should be part of that decision.

Common misconceptions

• “A generator runs in parallel.” It pauses and resumes when its caller invokes next().
• “A state machine is fake async.” It is one way to represent a real pause and continuation in ordinary code.
• “Every compiler emits Regenerator.” Output depends on the tool, configuration, and target.
• “Down-leveling has one fixed cost.” Code shape and runtime behavior vary, so measure the target workload.
• “Async functions lose locals while awaiting.” Their resumable frame preserves what later code needs.

The safe mental model is modest. A compiler can rewrite pauses into labels, saved values, and callbacks. The runtime still follows the promise and microtask rules from the previous lesson; generated code does not create a separate hidden clock.

Practice exercises

function* makeTea() {
  yield "boil water";
  yield "add tea";
}
const tea = makeTea();
console.log(tea.next().value);

const machine = makeTeaMachine();
console.log(machine.next().value);
console.log(machine.getState());

function run(genFn) {
  const iterator = genFn();
  function advance(value) {
    const step = iterator.next(value);
    return step.done ? Promise.resolve(step.value) : Promise.resolve(step.value).then(advance);
  }
  return advance();
}
function* work() {
  console.log("start");
  const item = yield Promise.resolve("tea");
  console.log("finish " + item);
}
run(work);

Check your understanding

Use the tea examples to separate three ideas: what pauses, who resumes it, and what older output must add. Read code questions one pause at a time instead of guessing from the name of a transform.

Key takeaways

• A generator pauses at each yield and resumes when someone calls next.
• A state machine can model that behavior with a saved label and a switch.
• Regenerator-style output represents generator pauses with labels and saved locals.
• Async-to-generator uses a promise runner to resume after each yielded promise settles.
• Coroutines pause and resume while preserving local state; generators and async functions differ in who drives them.
• Down-leveled async can add bundle code, calls, allocations, and debugging work, so choose modern targets when support allows it.

Coming next: Writing engine-friendly code. You will move from how code is represented to practical patterns that help engines stay on fast paths.