Why did React replace the Stack Reconciler with Fiber?

WHAT THIS TESTS: This tests your understanding of React's reconciliation architecture and why the original implementation hit fundamental scheduling limits. Interviewers want to know if you grasp the difference between a blocking call stack and interruptible work, and whether you can connect that to real user experience problems like dropped frames.

A GOOD ANSWER COVERS: First, state the core problem with the Stack Reconciler: it was fully synchronous and recursive. When React began re-rendering a tree, it would descend through every component in one uninterrupted stack frame. If that tree was large, the work could exceed the browser's 16 millisecond frame budget, causing missed frames and janky animations. Second, explain Fiber's headline feature: incremental rendering. Fiber restructures the component tree into a linked list of fiber nodes, which allows React to walk the tree iteratively rather than recursively. This means the renderer can pause after a small unit of work, yield control back to the browser to paint or handle events, and resume later. Third, mention priority. Fiber lets React assign different priorities to updates, so a text input can be processed immediately while a background data fetch re-render can wait. Fourth, note the practical outcomes: the ability to pause, abort, or reuse work as new updates arrive, and the foundation for concurrency primitives that later enabled features like Concurrent Mode and Suspense.

COMMON WRONG ANSWERS: Saying Fiber was created to enable Hooks is a timeline error; Hooks were built on top of Fiber, not the other way around. Calling Fiber a vague performance optimization without mentioning frame budgets, the main thread, or incremental rendering shows shallow knowledge. Describing it as a Virtual DOM change is incorrect; the Virtual DOM concept stayed the same, but the traversal and scheduling mechanism changed. Claiming Fiber makes all renders asynchronous is also wrong; synchronous renders still exist, but Fiber makes interruptible rendering possible.

LIKELY FOLLOW-UPS: How does Fiber's linked list structure differ from the old recursive approach? What is time slicing and how does it relate to the scheduler? How does React decide which updates get higher priority? Can you explain how Suspense leverages Fiber's ability to pause and resume work?

ONE CONCRETE EXAMPLE: Imagine a complex dashboard with hundreds of widgets. In the Stack Reconciler, updating a filter at the top would trigger a synchronous recursive render through every widget, locking the main thread for 200 milliseconds. The browser cannot respond to user input or run animations during that time, so a sidebar animation stutters. With Fiber, React splits that 200 milliseconds of work into small chunks, say 5 milliseconds each. After each chunk, it checks whether the browser needs to paint a frame or handle a click. The sidebar animation stays smooth because the browser gets regular chances to update the screen, and if the user types into a search box, React can pause the dashboard re-render to process the high priority input first.