How does the Virtual DOM work in React?

The Virtual DOM is a lightweight JavaScript representation of the actual DOM. When state changes, React creates a new Virtual DOM tree, diffs it against the previous one (reconciliation), and applies only the minimal set of actual DOM mutations needed. This avoids the performance cost of directly manipulating the real DOM for every state change, which would be slow because DOM operations trigger layout recalculations and repaints.

The real DOM is a complex, heavyweight structure. Every change to it can trigger the browser's rendering pipeline — style recalculation, layout (reflow), and paint. If you update 100 elements individually, the browser might recalculate layout 100 times. This is why frameworks that directly manipulate the DOM for every data change feel sluggish with complex UIs.

The Virtual DOM solves this by batching all changes and computing the minimum set of DOM operations needed — then applying them all at once. Instead of 100 individual updates, you get one batched update that triggers a single reflow.

React's Virtual DOM works in three distinct phases. Understanding these phases is key to understanding React's performance characteristics.

The Virtual DOM is just a tree of plain JavaScript objects. Each object describes a DOM node — its type, props, and children. When you write JSX, it compiles to React.createElement() calls that produce these objects. They're lightweight compared to real DOM nodes.

// Your JSX:
<div className="card">
  <h2>Title</h2>
  <p>Content</p>
</div>

// Compiles to:
React.createElement('div', { className: 'card' },
  React.createElement('h2', null, 'Title'),
  React.createElement('p', null, 'Content')
);

// Produces this Virtual DOM object (simplified):
{
  type: 'div',
  props: {
    className: 'card',
    children: [
      { type: 'h2', props: { children: 'Title' } },
      { type: 'p', props: { children: 'Content' } }
    ]
  }
}

// This is just a plain JS object — no DOM APIs, no browser rendering
// Creating thousands of these is fast

A naive tree diff algorithm is O(n³) — far too slow for UI updates. React uses two heuristics to achieve O(n) diffing, which makes it practical for real-time UI updates.

Heuristic 1: Different types produce different trees

If a node changes type (e.g., <div> becomes <span>, or <Header> becomes <Footer>), React tears down the entire old subtree and builds a new one from scratch. It doesn't try to diff children of different-typed parents — the assumption is that different types produce fundamentally different structures.

// Before:
<div>
  <Counter />
</div>

// After:
<span>
  <Counter />
</span>

// React sees: div → span (different type)
// Action: destroy the entire <div> subtree (including Counter's state)
//         create a new <span> subtree from scratch
// Counter loses all its state — it's a completely new instance

Heuristic 2: Keys identify stable elements in lists

When diffing lists of children, React uses the key prop to match elements between the old and new tree. Without keys, React matches by index — which breaks when items are reordered, inserted, or removed. Keys tell React "this is the same logical element" even if its position changed.

// Without keys — React matches by index (fragile)
// Before: [Alice, Bob, Charlie]
// After:  [Bob, Charlie]  (Alice removed from front)
// React thinks: index 0 changed Alice→Bob, index 1 changed Bob→Charlie, index 2 removed
// Result: updates TWO nodes and removes one (inefficient)

// With keys — React matches by identity (correct)
// Before: [key:1 Alice, key:2 Bob, key:3 Charlie]
// After:  [key:2 Bob, key:3 Charlie]  (key:1 removed)
// React thinks: key:1 removed, key:2 and key:3 unchanged
// Result: removes ONE node, moves nothing (efficient)

// That's why keys should be stable IDs, not array indices:
{todos.map(todo => (
  <TodoItem key={todo.id} todo={todo} /> // ✅ Stable identity
))}

Let's trace through a real diff scenario. A counter component increments — only the text content of one element changes. React's diff identifies this single change and updates only that DOM text node, leaving everything else untouched.

// Component:
function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div className="counter">
      <h2>Score</h2>
      <span>{count}</span>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  );
}

// Virtual DOM before click (count = 0):
// { type: 'div', props: { className: 'counter', children: [
//   { type: 'h2', props: { children: 'Score' } },
//   { type: 'span', props: { children: 0 } },        ← this changes
//   { type: 'button', props: { children: '+1' } }
// ]}}

// Virtual DOM after click (count = 1):
// { type: 'div', props: { className: 'counter', children: [
//   { type: 'h2', props: { children: 'Score' } },
//   { type: 'span', props: { children: 1 } },        ← changed!
//   { type: 'button', props: { children: '+1' } }
// ]}}

// Diff result: only the text content of <span> changed (0 → 1)
// DOM operation: spanElement.textContent = '1'
// Everything else is untouched — no reflow for the entire tree

React 16+ replaced the old recursive reconciler with Fiber — a reimplementation that can pause, resume, and prioritize work. Instead of diffing the entire tree synchronously (which could block the main thread for complex UIs), Fiber breaks work into small units and yields to the browser between them. This enables features like concurrent rendering, Suspense, and transitions.

The Virtual DOM is React's core architectural decision. Interviewers ask this to check whether you understand why React doesn't directly manipulate the DOM, how the diffing algorithm achieves O(n) performance, why keys matter for list reconciliation, and the tradeoffs of this approach vs alternatives. It shows you understand React at an architectural level — not just how to use it, but why it works the way it does.