React Fiber: The Complete Guide to React’s Reconciliation Engine Chapter 1

Photo by Lautaro Andreani on Unsplash

Chapter 1 — Why React Fiber? The Story Behind React’s Biggest Rewrite

Introduction

If you’ve been building React applications for a while, you’ve probably heard terms like Fiber, Concurrent Rendering, Time Slicing, or Reconciliation. They’re often mentioned in conference talks, blog posts, and documentation — but rarely explained from first principles.

Many developers think:

• React Fiber is the Virtual DOM.
• Fiber is just a performance optimization.
• Fiber makes React asynchronous.

None of these are completely accurate.

React Fiber is much more than a performance enhancement. It is a complete rewrite of React’s rendering engine, introduced in React 16, designed to solve problems that the original architecture simply couldn’t handle.

To understand why Fiber exists, we first need to understand how React worked before it.

Before React 16, React used what was known as the Stack Reconciler.

Whenever a component’s state changed, React would perform a synchronous update.

setState()

      │

      ▼

Render Component Tree

      │

      ▼

Compare Virtual DOM

      │

      ▼

Update DOM

This process was simple and effective for small applications. But as applications grew in size and complexity, its limitations became apparent.

How the Stack Reconciler Worked

Imagine an application like this:

<App>

 ├── Navbar
 ├── Sidebar
 ├── Dashboard
 │      ├── Charts
 │      ├── Reports
 │      ├── Analytics
 │      └── Widgets
 └── Footer

Now suppose a user updates a filter inside the dashboard.

Dashboard.setState()

The Stack Reconciler begins traversing the component tree from the affected node.

Unlike modern Fiber, it cannot pause once it starts.

The update continues until the entire rendering process is complete.

Start Rendering

↓

Dashboard

↓

Charts

↓

Reports

↓

Analytics

↓

Widgets

↓

Finish

There is no opportunity to stop halfway through and let the browser handle user interactions.

The Browser Has a Job Too

While React is rendering, the browser is also responsible for:

• Responding to clicks
• Processing keyboard input
• Handling scroll events
• Running animations
• Painting pixels to the screen

To provide a smooth experience, browsers aim to render a new frame every 16.67 milliseconds, which corresponds to 60 frames per second (FPS).

Frame 1  → 16.67ms
Frame 2  → 16.67ms
Frame 3  → 16.67ms

If JavaScript occupies the main thread for too long, the browser cannot render the next frame.

This results in dropped frames and noticeable UI lag.

The Problem

Consider a React application with thousands of components.

A single state update might take:

80ms

Since the browser only has 16.67ms per frame, React blocks approximately five frames.

80ms

↓

Frame ❌

Frame ❌

Frame ❌

Frame ❌

Frame ❌

To users, this appears as:

• Stuttering animations
• Delayed clicks
• Frozen scrolling
• Poor responsiveness

The application may still be technically correct, but it feels slow.

Why This Was a Serious Issue

Around the time React was gaining popularity, Facebook was supporting products such as:

• Facebook News Feed
• Messenger
• Instagram
• Ads Manager

These applications contained:

• Thousands of React components
• Live notifications
• Infinite scrolling
• Rich animations
• Real-time updates

Updating everything synchronously simply didn’t scale.

Facebook needed React to become interruptible.

What Did Facebook Want?

Imagine a user is typing into a search box.

At the same time, React starts rendering a very large list.

Without Fiber:

User Types

↓

React Starts Rendering

↓

UI Freezes

↓

Rendering Completes

↓

Input Updates

The user immediately notices keyboard lag.

Instead, Facebook wanted this:

User Types

↓

Pause Rendering

↓

Update Input

↓

Resume Rendering

In other words,

User interactions should always have higher priority than background work.

This idea became one of the core design principles behind React Fiber.

Introducing React Fiber

React Fiber breaks rendering into small units of work.

Instead of treating rendering as one large task, Fiber divides it into many smaller tasks that can be paused, resumed, or even discarded if something more important happens.

Large Update

↓

Work Unit 1

↓

Pause

↓

Browser Paint

↓

Work Unit 2

↓

Pause

↓

User Click

↓

Handle Click

↓

Resume Work

↓

Commit

This makes React much more responsive under heavy workloads.

Why the Name “Fiber”?

A Fiber is simply a JavaScript object that represents a single React component and all the information React needs to render and update it.

Each component in your application corresponds to one Fiber node.

For example:

<App>

↓

Fiber

↓

<Dashboard>

↓

Fiber

↓

<Chart>

↓

Fiber

Together, these Fiber nodes form a tree that React can traverse efficiently.

Stack Reconciler vs Fiber

Stack ReconcilerReact FiberSynchronousInterruptibleCannot pauseCan pause and resumeOne large taskSmall units of workFixed priorityPriority-based schedulingLess responsiveMore responsiveBlocks the main threadCooperates with the browser

This architectural shift laid the foundation for many modern React features.

Features Enabled by Fiber

Fiber isn’t just about smoother rendering.

It enabled capabilities that were previously impossible, including:

• Concurrent Rendering
• Suspense
• startTransition
• Automatic batching
• Streaming Server-Side Rendering
• Server Components
• Selective Hydration

Without Fiber, these features couldn’t exist in their current form.

A Simple Analogy

Imagine you need to clean an entire house.

Stack Reconciler

You clean every room in one go.

If the doorbell rings, you ignore it until you’re done.

Fiber

You clean one room, then check if anything more important needs your attention.

If the doorbell rings, you answer it, then continue cleaning.

The total work is similar — but the experience is much better.

Key Takeaways

• React originally used the Stack Reconciler, which processed updates synchronously.
• Long renders blocked the browser’s main thread.
• This led to dropped frames and unresponsive user interfaces.
• React Fiber breaks rendering into smaller, interruptible units of work.
• Fiber introduces scheduling and prioritization, allowing React to respond to user interactions before completing less important work.
• Modern React features such as Concurrent Rendering, Suspense, and transitions are built on top of the Fiber architecture.

What’s Next?

In Chapter 2, we’ll move beyond the motivation and explore the heart of Fiber itself:

• What is a Fiber Node?
• How are Fiber nodes connected?
• Why does React use child, sibling, and return pointers?
• What is the alternate pointer?
• How does React build the Fiber tree in memory?

By the end of Chapter 2, you’ll understand the core data structure that powers every React application.