Every React developer knows “React uses a virtual DOM.” Few can explain what that actually means. Here’s the full picture.

The problem: DOM updates are slow

The browser’s DOM (Document Object Model) is a tree of objects representing your HTML. Updating it is expensive because every change can trigger:

• Style recalculation
• Layout (reflow)
• Paint
• Compositing

Changing one element’s text? Fast. Changing 100 elements? The browser might reflow the entire page.

React’s solution: diff first, update minimally

Instead of updating the DOM directly, React:

1. Keeps a lightweight copy of the DOM in memory (the virtual DOM)
2. When state changes, builds a new virtual DOM tree
3. Compares the new tree with the old tree (diffing)
4. Calculates the minimum set of real DOM changes needed
5. Applies those changes in a batch

What the virtual DOM looks like

It’s just JavaScript objects:

// This JSX:
<div className="card">
  <h1>Hello</h1>
  <p>World</p>
</div>

// Becomes this virtual DOM object:
{
  type: 'div',
  props: { className: 'card' },
  children: [
    { type: 'h1', props: {}, children: ['Hello'] },
    { type: 'p', props: {}, children: ['World'] }
  ]
}

Creating and comparing JavaScript objects is orders of magnitude faster than touching the real DOM.

The diffing algorithm (reconciliation)

React’s diff algorithm has three rules that make it O(n) instead of O(n³):

Rule 1: Different types = full replace

If an element changes type (e.g., <div> to <span>), React destroys the old tree and builds a new one. No attempt to reuse.

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

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

// React: destroy everything inside <div>, rebuild inside <span>
// Counter's state is lost

Rule 2: Same type = update props

If the type is the same, React keeps the DOM node and only updates changed attributes.

// Before:
<div className="old" style={{color: 'red'}} />

// After:
<div className="new" style={{color: 'blue'}} />

// React: only updates className and color. One DOM operation.

Rule 3: Keys identify list items

When diffing lists, React uses key props to match old and new items:

// Before:
<li key="a">Alice</li>
<li key="b">Bob</li>

// After:
<li key="b">Bob</li>
<li key="a">Alice</li>

// With keys: React knows to reorder, not recreate
// Without keys: React updates both elements' text content

This is why missing keys cause bugs and performance issues.

The update cycle

setState() called
    ↓
New virtual DOM tree created
    ↓
Diff old tree vs new tree
    ↓
List of minimal changes (patches)
    ↓
Batch apply to real DOM
    ↓
Browser repaints

React batches multiple setState calls into a single update cycle. If you call setState three times in an event handler, React diffs once and applies once — not three times.

React 18: Concurrent rendering

React 18 added the ability to pause and resume rendering. If a high-priority update (user typing) comes in while a low-priority update (loading data) is rendering, React can:

1. Pause the low-priority render
2. Handle the high-priority update
3. Resume or restart the low-priority render

The virtual DOM makes this possible because it’s just JavaScript objects — you can throw away a half-built tree and start over with no DOM side effects.

Is the virtual DOM actually faster?

Controversial take: the virtual DOM isn’t faster than hand-optimized DOM updates. A developer who knows exactly which element to update can do it in one line of vanilla JS.

The virtual DOM is faster than naive DOM updates. It’s a trade-off: you write declarative code (“here’s what the UI should look like”) and React figures out the minimal DOM changes. You sacrifice some raw performance for developer productivity.

Frameworks like Svelte and SolidJS skip the virtual DOM entirely and compile to direct DOM updates. They can be faster for certain workloads. But React’s approach is “fast enough” for 99% of applications.

Related resources

• React complete guide
• JavaScript array methods cheat sheet
• JavaScript complete guide

Related: React Interview Questions