For many developers, React operates as a highly reliable black box. You trigger a state mutation and the UI eventually reflects that change. However, when you are architecting large-scale applications with high-frequency updates, complex animations or heavy data visualization, treating React as a black box is a liability. To resolve frame drops, optimize render cycles, and leverage Concurrent React properly, you must understand the underlying engine: React Fiber. This article explores the architectural shift from React’s legacy Stack Reconciler to the Fiber architecture, examining the underlying data structures, cooperative scheduling and the mechanics of the render and commit phases. The Bottleneck: The Legacy Stack Reconciler To understand why Fiber exists, it helps to analyze what React was doing before version 16 and where that model broke down. The original reconciliation algorithm, known as the Stack Reconciler, relied on a synchronous, recursive traversal of the Virtual DOM tree. When setState was called, React would push the update onto the JavaScript call stack and recursively walk the entire component tree, parent to child, depth-first, computing the differences between the previous and next virtual DOM snapshots. This process is called reconciliation or the diffing phase. The architectural flaw was not in the diffing algorithm itself. React’s O(n) heuristic-based diffing was and still is, efficient for most trees. The flaw was in the execution model. This traversal was strictly synchronous and atomic. Once React began reconciling a tree, it held an exclusive lock on the JavaScript main thread until the entire tree was processed. The call stack had to unwind completely before control was returned to the browser. If a deeply nested component tree took 80–150 milliseconds to reconcile, an easy threshold to cross in data-heavy dashboards or large list renders, the browser could not execute anything else during that window. The consequences were concrete and measurable: Input latency — Keystrokes and click events queued in the browser’s event queue, but were not processed until React released the main thread. Users experienced sluggish, unresponsive inputs. Animation jank — CSS animations and requestAnimationFrame callbacks missed their 16ms frame budget, the threshold for a smooth 60fps experience, causing visible stuttering. Scroll blocking — Scroll event handlers were starved, producing a frozen or choppy scrolling experience. The root of the problem is architectural: the native JavaScript call stack cannot be paused, reprioritized or partially rewound. Once a function is executing, it runs to completion. React had no mechanism to say, “pause here, let the browser paint a frame, then resume.” React needed four capabilities the Stack Reconciler fundamentally could not provide: Pause work and resume it later. Abort work that is no longer relevant, such as a state update superseded by a newer one. Reuse previously completed work. Prioritize different types of updates differently. The solution was radical: move the stack from the native call stack to the heap, and build a custom scheduler on top of it. The Paradigm Shift: Fiber as a Virtual Stack Frame React Fiber is a complete rewrite of React’s core reconciliation and scheduling engine, shipped in React 16 in September 2017, with the full Concurrent Mode capabilities unlocked progressively through React 18. The overarching goal of Fiber is to enable cooperative scheduling and time-slicing, the ability for React to voluntarily yield execution back to the browser between units of work. From Recursion to a Linked List The Stack Reconciler traversed the component tree using JavaScript’s native recursion. Each function call pushed a new frame onto the call stack. This made the traversal inherently synchronous: the only way to pause recursion is to not start it, which is not useful in practice. Fiber solves this by virtualizing the call stack. Instead of relying on the engine’s call stack, React allocates a custom data structure on the heap for each component in the tree. This data structure is called a Fiber node. A Fiber node is a plain JavaScript object. It is React’s unit of work, a heap-allocated representation of a component instance, equivalent to a single frame in the call stack that React controls entirely. Because these objects live on the heap rather than the call stack, React can: Stop processing at any Fiber node. Store the current Fiber node’s reference. Hand control back to the browser’s event loop. Resume from the exact same Fiber node in the next available time slice. This is cooperative scheduling: React voluntarily yields rather than being forcibly interrupted. The Anatomy of a Fiber Node Understanding what a Fiber node contains is key to understanding how React tracks, schedules and executes work. Each Fiber node holds The return, child, and sibling pointers are critical. Rather than a traditional tree structure, Fiber represents the component tree as a singly-linked list traversal graph. This structure is what allows React to traverse iteratively in a while loop rather than recursively, making it interruptible at any node boundary. The Double Buffer: Current and Work-In-Progress Trees At any given moment, React maintains two fiber trees in memory simultaneously: Current tree — The fiber tree that corresponds to what is currently rendered and visible on screen. This tree is stable and never mutated directly. Work-in-progress tree — A new tree React is constructing in the background to reflect the next UI state. This is where all reconciliation and diffing occurs. Each fiber node in the work-in-progress tree has an alternate pointer back to its counterpart in the current tree, and vice versa. React reuses fiber objects between renders, updating their fields rather than creating new objects, to minimize garbage collection pressure. When the work-in-progress tree is complete and all mutations are committed to the DOM, React performs an atomic tree swap: the work-in-progress tree becomes the new current tree. This pattern is called double buffering, the same technique used in graphics programming to prevent screen tearing. The critical architectural benefit is that if work on the work-in-progress tree is interrupted or abandoned due to a higher-priority update arriving, React can simply discard the in-progress tree. The current tree, representing the last consistent