DEV Community

Cover image for How React Works (Part 2)? Why React Had to Build Its Own Execution Engine
Sam Abaasi
Sam Abaasi

Posted on

How React Works (Part 2)? Why React Had to Build Its Own Execution Engine

#react #javascript #scheduler #fiber

Why React Had to Build Its Own Execution Engine

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Prerequisites: Read Part 1 first — this article picks up exactly where it left off.

Where We Left Off

In Part 1 we landed on one sentence that explains why React had to be completely rewritten:

React needs to be able to interrupt what it's doing and resume it later.

Time Slicing needs it — to yield within the browser's 16ms frame budget.
Suspense needs it — to pause and wait for async data.

Simple enough requirement. But here's the problem: JavaScript itself won't let you do it.

This article is about why that's true, what React did about it, and why that decision — building an entirely custom execution model — is what makes modern React possible.

The Problem: JavaScript Runs to Completion

When JavaScript starts executing a function, it finishes it. There is no external API to say "pause here, do something else, come back." There is no way to freeze a running program mid-execution, hand control back to the browser, and resume from the exact same spot.

This is because JavaScript manages execution with something called the call stack — a data structure that tracks what the program is doing at any moment.

Every time a function is called, JavaScript creates a stack frame — a small record of that function's parameters, local variables, and where to return to when it finishes. These frames stack up as functions call other functions, and pop off as they return.

call stack growing as functions call each other, frames popping as they return

Here's the critical property of this stack: it's managed entirely by the JavaScript engine. You — the developer — cannot read it, pause it, or jump around in it. It's a black box. Once a chain of function calls starts, it runs to completion. The browser can't paint. The user can't interact. Nothing happens until the stack is empty.

For old React, this was fine. React rendered your whole tree in one big chain of function calls. The browser waited. Nobody noticed because apps were small enough.

But for Time Slicing — where React needs to stop mid-render, let the browser paint, then resume — this model is a hard wall. You can see the exact moment React solved it in two lines from the React source:

// Old — no way out until every component is done
function workLoopSync() {
  while (workInProgress !== null) {
    performUnitOfWork(workInProgress);
  }
}

// New — checks after every single component
function workLoopConcurrent() {
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}
Enter fullscreen mode Exit fullscreen mode

One extra condition: !shouldYield(). That's it. After every component, React asks: "Is the browser waiting? Is there higher-priority work?" If yes, the loop breaks. But for this to be safe — for breaking mid-loop to not lose work — React needed somewhere to store what it was doing. That storage is Fiber.

Sam Galson described it precisely in his talk "Magic in the web of it":

"Unlike stack frames, fibers can also keep around local data like state even if they're not currently active. With a stack frame, when it's popped off the stack, all of the local information stored in it is gone. But that's not the case with a fiber."

The Insight: What If React Had Its Own Stack?

Here's the idea that changed everything.

The native JavaScript call stack is a constraint because React doesn't control it. But what if React built its own version — one that it does control?

Not a replacement for JavaScript's stack. JavaScript still runs normally. But React would track its own rendering work in a data structure it manages itself. One it can pause, inspect, prioritize, and resume at any moment.

This is what React Fiber is. It is React's own custom execution model, built in plain JavaScript objects, sitting on top of JavaScript's normal execution.

Sam Galson described the CS concept behind it:

"A fiber is just a generic way to model program execution in a way where each individual unit of work works together cooperatively. No single fiber attempts to dominate the program."

React didn't invent this idea. Fibers exist in operating systems. Microsoft Windows uses them. OCaml built its entire concurrency model on them. The concept is old — React just brought it to the browser.

What a Fiber Actually Is

In JavaScript's call stack, a stack frame holds:

  • What function is running
  • What parameters it was called with
  • What local variables it has
  • Where to return to when done

A Fiber holds the exact same information — but for a React component:

Stack frame Fiber equivalent
The function Your component (App, Button, etc.)
Parameters Props being passed in
Local variables State and hooks
Return address The parent component

The difference that makes everything possible: stack frames live inside the JavaScript engine where you can't touch them. Fibers are just plain JavaScript objects. React creates them, reads them, pauses on them, and resumes them — completely under its own control.

Here's what a fiber for a <Button> component actually looks like at runtime:

{
  type: Button,              // your component function
  pendingProps: { label: "click me" },  // props coming in
  memoizedState: { count: 0 },          // state lives here
  return: ParentFiber,       // parent — like a return address
  child: null,               // first child component
  sibling: null,             // next sibling component
  alternate: null,           // the other version of this fiber
}
Enter fullscreen mode Exit fullscreen mode

That's it. A regular JavaScript object. Nothing magical. The fact that it's just an object is what makes pausing safe — React can stop at any point, and the fiber is still sitting in memory exactly as it was.

And because fibers are objects, they can hold more than stack frames can. Each fiber knows not just its parent (like a return address) but also its first child and its next sibling. This means React can navigate the entire component tree from any point — forward, backward, sideways — without losing track of where it is.

When the browser needs to paint, React stops updating workInProgress (its pointer to the current fiber), yields control, and returns to the work loop later. The fiber is still sitting in memory, exactly as React left it. Nothing was lost.

Two Trees, Always

Here's one more piece of the picture that makes this safe.

React always keeps two versions of your component tree in memory at the same time:

  • The current tree — what's actually showing on screen right now
  • The work-in-progress tree — what React is building for the next render

All rendering work happens on the work-in-progress tree. The current tree is never touched during rendering. So if React gets interrupted mid-render, the screen doesn't flicker or break — the current tree is still intact and showing correctly.

When the new tree is fully built and ready, React swaps them in one atomic operation. What was work-in-progress becomes current. What was current becomes the next work-in-progress (ready to be reused for the render after that).

two trees — current (on screen) and work-in-progress (being built), swap on commit

This pattern — keeping two versions and building the new one safely before switching — is called double buffering. It's the same technique video games use to prevent screen tearing. React borrowed it for exactly the same reason: you never want to show the user a half-built state.

How the Scheduler Uses This

Now the Scheduler — the module that decides when and in what order work runs — can do things that were completely impossible before.

Pause and resume. When shouldYield() returns true (time budget used up), the work loop simply stops. The workInProgress pointer stays exactly where it is. Next time the Scheduler gets control, the loop continues from that fiber. No work is lost. No state is rebuilt.

Prioritize. Because fibers are objects React controls, it can look at any fiber's priority (lanes) and decide to work on a different part of the tree first. A keystroke comes in while React is rendering a heavy chart? React stops the chart render, handles the keystroke (which runs at higher priority), then comes back to the chart from exactly where it left off.

Abort. If a newer update makes the current work-in-progress tree obsolete, React can throw it away entirely and start fresh with updated data. The current tree on screen is unaffected.

None of these were possible when rendering was one continuous chain of JavaScript function calls.

Scheduler work loop — shouldYield check, pause, high-priority task runs, resume

The Full Picture in One Paragraph

React saw that JavaScript's call stack — fast, simple, but completely opaque — was incompatible with the kind of interruptible, prioritized rendering that modern apps need. So it built a replacement: a tree of plain JavaScript objects (fibers) where each object is a stack frame React controls. It keeps two copies of this tree so it can always build the next version safely without disturbing what's on screen. And it has a Scheduler that decides what to work on next, how long to work before yielding, and how to resume exactly where it stopped.

That system — Fiber + Scheduler — is the engine underneath every useState, every useTransition, every <Suspense> boundary, every animation that doesn't drop frames.

What's Coming in Part 3

Now that we understand the engine, we can look at what the engine actually does — how React figures out which parts of your UI actually changed, and how it updates the minimum number of DOM nodes to reflect that. That's the Reconciler, and it's where key props, React.memo, and most of your performance intuitions come from.

🎬 Watch These

Sam Galson — Magic in the web of it: coroutines, continuations, fibers | React Advanced London
The computer science behind why Fiber works — what fibers are in CS terms, how they differ from threads and coroutines, and why React chose this model. The source for the cooperative execution framing in this article.

Dan Abramov — Beyond React 16 | JSConf Iceland 2018
The original demo of the problem this article solves. Watch 2:57 to feel exactly why the call stack was a problem.

Matheus Albuquerque — Inside Fiber | React Summit 2022
Goes deeper on the FiberNode data structure if you want the implementation detail. Start at 2:11.

🙏 Sources & Thanks

  • Sam Galson — Magic in the web of it (talk) and Continuations, coroutines, fibers, effects (article). The cooperative execution framing, the "fibers existed before React" point, and the comparison between fibers and stack frames all come from Sam's work.
  • Andrew Clark — react-fiber-architecture. The definition of Fiber as "a reimplementation of the stack, specialized for React components" and the double buffering concept.
  • jser.dev — source-level verification of how the two-tree system, workInProgress, and the Scheduler work loop actually behave in the React codebase.

Part 3 is next — the Reconciler: how React finds the minimum set of changes needed to update your UI, and why key props matter more than you think. 🔧

Tags: #react #javascript #webdev #tutorial

Top comments (0)