Last chapter we learned THAT React creates a new Virtual DOM tree and compares it against the old one. But HOW does React actually do that, step by step, without freezing the browser? The answer is Fiber – React's internal rendering model since React 16 (before that: the simpler, but non-interruptible "stack reconciler" architecture).

The problem Fiber solved

Before React 16, rendering was a single, UNINTERRUPTIBLE recursive function call stack – once React started computing an update, it had to run all the way to completion BEFORE the browser could do anything else (not even process a keystroke, not even paint an animation frame). With a large component tree, this could block the "main thread" for noticeable milliseconds – exactly the "freeze" feeling we created ourselves in chapter 33 with the artificially slowed search.

What a "fiber" concretely is

A fiber is a JavaScript object representing ONE unit of work – roughly (though not exactly) one component instance in the tree. Unlike the old recursive approach, a fiber tree is an EXPLICIT data structure with links to child (first child), sibling (next sibling), and return (parent) – so React can WALK this tree step by step, like a list, instead of processing it recursively, and can PAUSE and RESUME it at any point.

The two phases: render and commit

React's work is split into two fundamentally different phases:

• Render phase (interruptible): React walks the fiber tree, calls component functions, computes what changed. This phase can be paused, resumed, or even DISCARDED (e.g. when a more urgent update comes in – exactly the principle behind useTransition from chapter 33).
• Commit phase (NOT interruptible): Once the render phase is done, React applies the computed changes to the real DOM SYNCHRONOUSLY and ALL AT ONCE. This phase must run uninterrupted, so the user never sees a "half-updated" screen.

Priorities: not all updates are equally important

Fiber lets React order updates by PRIORITY (internally via a system called "lanes"). A keystroke has higher priority than a startTransition-wrapped update (chapter 33) – React can therefore process the urgent input FIRST, even if computing the less urgent update had already begun. This exact capability – ordering and interrupting work by urgency – is what makes useTransition/useDeferredValue from chapter 33 possible for your team to use. Without Fiber, those hooks simply wouldn't exist.

Understanding StrictMode again, in a new light

Remember <StrictMode> in main.jsx ("React for Beginners" chapter 2), which calls some functions twice in development mode? Now it makes more sense: React deliberately uses this to test whether your components are robust against an INTERRUPTED and then REPEATED render phase – exactly the scenario Fiber can produce in real apps under load. A component function that returns different results when called twice (e.g. because of a side effect DIRECTLY in the function body instead of in useEffect) is a bug StrictMode is meant to surface.

Why this matters for your day-to-day work

• It explains why component functions MUST be "pure" (no side effects in the function body) – an interrupted, discarded, or repeatedly-run render phase must never produce visible side effects.
• It explains why useEffect exists instead of just writing side effects in the function body – effects are GUARANTEED to run exactly once per actual commit, not per (possibly discarded) render attempt.
• It's common interview knowledge (see chapter 47, interview preparation) – "What is React Fiber?" is one of the most classic advanced-level interview questions.