React Virtual DOM & Diffing Algorithm — Complete Interview Guide

Why Direct DOM Manipulation Is Slow

Every time you modify a DOM element, the browser runs some or all of this rendering pipeline:

1. Style calculation — which CSS rules apply after this change?
2. Layout (reflow) — where does every element now sit on the page?
3. Paint — fill in the pixels for changed areas
4. Composite — merge layers and display the final frame

Changing 50 elements one by one can trigger this pipeline 50 times. Batching them into a single DOM update collapses it to one pass — and that's exactly what the Virtual DOM enables.

What the Virtual DOM Actually Is

The Virtual DOM is a tree of plain JavaScript objects describing what the UI should look like. JSX compiles to React.createElement() calls that produce these objects:

// JSX
<div className="card" id="u1">
  <h2>Alice</h2>
  <p>Engineer</p>
</div>

// The plain object React creates (simplified):
{
  type: 'div',
  props: { className: 'card', id: 'u1' },
  children: [
    { type: 'h2', props: {}, children: ['Alice'] },
    { type: 'p',  props: {}, children: ['Engineer'] }
  ]
}

Creating this object is instantaneous — no browser APIs, no layout, no paint. React keeps two snapshots: the tree from the previous render and the new tree from the latest render. Comparing them is diffing, and the result is a minimal list of real DOM operations to apply.

The Diffing Algorithm — From O(n³) to O(n)

Fully comparing two arbitrary trees is an O(n³) problem — a 1,000-node tree would require a billion comparisons. React reduces this to O(n) using two pragmatic rules:

Rule 1: Different element types → destroy and rebuild

If the root element type changes (e.g. div → section), React tears down the entire old subtree and builds a fresh one from scratch. It never tries to reconcile children across a type boundary.

// Before — Counter has local state (count = 5)
<div><Counter /></div>

// After — div changed to section: React destroys the subtree
// Counter remounts from zero — all local state is lost
<section><Counter /></section>

Accidentally changing a wrapper element type is a classic cause of "why did my component lose its state?"

Rule 2: Same element type → update in place

When the element type stays the same, React keeps the underlying DOM node and only updates the changed attributes:

// Before
<input type="text" className="idle" placeholder="Search..." />

// After — only className changed; React updates one attribute, reuses the DOM node
<input type="text" className="active" placeholder="Search..." />

For component elements (not DOM elements), React keeps the component instance alive and calls the function with new props. Local state and refs survive because the instance is reused — only the output changes.

Keys: Stable Identity for List Items

Lists break the position-based heuristic. Without keys, React assumes the item at index 0 is the same item on every render. Insert one item at the top of a 100-item list and React thinks all 100 moved — it re-renders every one. With keys, React tracks each item by identity regardless of position:

// Without keys — React matches by index: one insert = re-render all 100
{items.map(item => <Row data={item} />)}

// With stable keys — React matches by identity: one insert = render only that item
{items.map(item => <Row key={item.id} data={item} />)}

Why Index as Key Causes Bugs

If you filter or sort the list, the index no longer uniquely identifies the same item across renders. React sees that index 0 now points to a different item but reuses the DOM node (and its state) from the previous index 0. The result: component state appears in the wrong item, input values show up in the wrong row, animations fire on the wrong element.

// Only safe for lists that are static, append-only, and never filtered
{staticTabs.map((tab, i) => <Tab key={i} label={tab.label} />)} // OK

// Dangerous — sorting or filtering this will corrupt state
{sortedUsers.map((u, i) => <UserRow key={i} user={u} />)} // Bug waiting to happen

Render Phase vs Commit Phase

React splits its work into two distinct phases:

• Render phase — runs component functions, builds the new Virtual DOM, diffs against the previous snapshot, produces a list of changes. This is pure computation — no DOM writes, no side effects. In concurrent mode, React can pause and resume this phase.
• Commit phase — applies the diff list to the real DOM. Always synchronous and uninterruptible. React will never pause halfway through writing to the DOM.

This separation explains why useLayoutEffect fires synchronously after the commit (DOM updated, browser hasn't painted yet) and useEffect fires after the browser paint.

Where React Fiber Fits In

React Fiber (React 16) rewrote the reconciler — the scheduler that decides when to diff and commit. It did not replace the Virtual DOM object tree. What Fiber added:

• The render phase became interruptible — React can pause diffing to handle urgent work (a user click)
• Priority levels — urgent updates (typing, clicking) jump ahead of background work (data loading)
• The foundation for React 18's concurrent features: startTransition, useDeferredValue, streaming SSR

Fiber = the scheduler that processes the Virtual DOM. The Virtual DOM (the JS object tree) still exists; Fiber decides when and how to compare trees and apply changes.