Inside React Reconciliation: From the Stack Reconciler to Fiber

React’s performance story is fundamentally a story about how it schedules and processes work. The reconciler is the engine that makes this possible. It determines what has changed between renders, prepares the required updates, and hands those changes to the renderer for DOM mutation. It is a planning system, not a rendering system.

Understanding why Fiber exists requires understanding the constraints of the browser environment. The main thread is shared by everything: user input, animations, layout, network callbacks, and JavaScript execution. If rendering work occupies this thread for too long, the application becomes unresponsive. Typing lags, animations drop frames, and the interface appears frozen.

The original stack reconciler processed rendering in a strictly synchronous, recursive manner. Once rendering began, it continued until the entire component tree had been traversed. Because progress lived inside the JavaScript call stack, there was no way to pause, reprioritize, or resume. Work could not be interrupted, even if something more important—like a keystroke—arrived.

This meant React was fast when work was small, but unpredictable when work became large.

The Limitation of the Stack-Based Model

Rendering followed a depth-first recursive traversal. Each component produced its children, and each child was processed immediately. Control returned to the browser only after the entire tree had finished.

Because the process was synchronous, React could not:

• pause rendering
• assign priority to updates
• reuse partially completed work
• discard obsolete work

The need for responsiveness, not just speed, led to a fundamental redesign.

Fiber: A Reconciler Designed for Scheduling

Fiber is both a new architecture and a new data structure. Instead of relying on the call stack, React represents each component as a plain JavaScript object called a fiber. Every fiber corresponds to a unit of work.

These fiber nodes form a linked tree using child, sibling, and return pointers. This structure allows React to move through the tree without recursion and to store progress directly on the nodes themselves.

Each fiber holds the information required to process and reconcile a component, including its previous state, pending props, update queue, and a link to its alternate. That alternate connects the current tree (what is on the screen) with the work-in-progress tree (what is being prepared).

This dual-tree structure enables rendering to happen in the background without affecting what the user currently sees.

Rendering Becomes Interruptible

With Fiber, rendering is broken into small units of work. React processes one fiber at a time using a manual work loop rather than recursion. After completing a unit, it can yield control back to the browser. If a higher-priority update appears, React pauses its current work and switches context.

Because progress is stored on the fiber tree rather than the call stack, work can resume exactly where it stopped.

This is the core shift: rendering is no longer an all-or-nothing operation.

The Two Phases of Rendering

The architecture separates rendering into two distinct phases.

The render phase builds the work-in-progress tree and calculates what needs to change. This phase is interruptible and can be paused, resumed, or abandoned.

The commit phase applies the prepared changes to the DOM. This phase is synchronous and cannot be interrupted.

During the render phase, React collects all required mutations into an effect list. The commit phase simply walks this list and performs the actual updates. This makes DOM mutation fast and predictable.

The swap between the current tree and the completed work-in-progress tree happens atomically, which is why UI updates appear consistent.

Priorities and Scheduling

Not all updates are equally important. Fiber introduces the ability to assign priority to work. High-priority updates, such as user input, can interrupt lower-priority rendering tasks.

This allows large UI updates to be processed in the background while the interface remains responsive.

The goal is not to finish rendering as quickly as possible, but to ensure the user never experiences blocking.

Reconciliation in the Fiber World

When React processes a fiber, it compares the previous fiber with the new element and determines whether the node should be updated, inserted, or removed. These decisions are recorded as effects rather than being applied immediately.

Because this work happens incrementally and can be paused, React can avoid wasting time on updates that become irrelevant before completion.

Double Buffering and Atomic Updates

React always keeps the current UI tree intact while building the next version in memory. Only when the new tree is fully ready does it replace the current one.

This double-buffering approach ensures that partially rendered UI never appears on screen.

The Conceptual Shift

The stack reconciler was designed for immediate, synchronous execution. Fiber is designed for controlled, prioritized, interruptible work.

Rendering is no longer a single blocking task. It is a scheduled process that cooperates with the browser.

Why This Matters for User Experience

The architectural change enables:

• smooth typing during large renders
• consistent animations
• predictable frame timing
• better perceived performance

Responsiveness becomes the primary metric, not raw render speed.

Closing Perspective

Fiber transforms reconciliation into a system that can pause, resume, reorder, and discard work. It introduces units of work, a linked tree structure, an interruptible render phase, a synchronous commit phase, and atomic tree swapping.

The result is a rendering model that aligns with how the browser actually works: time-sliced, priority-driven, and responsive.