All topics
57 / 100
DOMintermediate

The Virtual DOM Concept

The in-memory representation of the UI that frameworks like React diff against the previous version to compute minimal real DOM updates.

A virtual DOM is a plain-object description of the UI. The framework compares the new description with the old one and applies only the differences to the real DOM.

The virtual DOM is like an architect making all their sketches and revisions on cheap scratch paper (virtual nodes) before ever touching the actual, expensive-to-modify physical building (the real DOM) — comparing the new sketch to the last one lets the crew figure out exactly which walls actually need to change, instead of demolishing and rebuilding the whole structure for every small revision.

Key Concepts

1
    // what JSX compiles to
    { type: 'div', props: { className: 'card' },
      children: [{ type: 'h1', children: ['Title'] }] }
2
Why it exists. Real DOM operations are expensive — each can trigger style recalculation, layout and paint. Rebuilding a list of a thousand rows by replacing innerHTML destroys and recreates everything, losing focus, scroll position and input state.
innerHTML
3
The virtual DOM lets you write as though you rebuild everything, while the framework updates only what changed.
4
The cycle.
    state changes
      -> render produces a new tree of plain objects
      -> diff against the previous tree
      -> apply the minimal set of real DOM operations
5
Diffing is heuristic, not optimal. A true tree-diff is O(n³). React assumes two things to get to O(n):
O(n³)O(n)
6
    different types      -> replace the subtree entirely
    same type            -> update attributes, recurse into children
7
Which is why changing a <div> to a <span> throws away everything inside it, including component state.
<div><span>
8
Keys are how lists are matched.
    items.map(i => <Row key={i.id} />)
9
Without a stable key, React matches by position. Insert at the top of a list keyed by index and every row appears to have changed — so inputs keep their old values against the wrong rows, which is the classic key bug.
10
The honest framing. A virtual DOM is not faster than well-written direct DOM manipulation. Hand-updating exactly the node that changed is always faster than diffing a tree.
11
What it buys is that you do not have to write that code, and it stays correct as the UI grows. The comparison is against realistic alternatives — rebuilding markup, or hand-maintained update logic — not against a perfect one.
12
Which is why newer frameworks skip it. Svelte compiles to direct updates; Solid uses fine-grained reactivity to update exactly the affected node. Both reach the same goal — write declaratively, update minimally — without a diff at runtime.
13
What the interviewer is probing.1. "Is the virtual DOM faster than direct DOM manipulation?" Probing: whether you repeat marketing. Stalls: "Yes, much faster." Moves up: no — hand-written minimal updates are faster; it buys a declarative model with predictable batching, at a cost.
14
2. "What does reconciliation do?" Probing: the algorithm. Stalls: "It redraws." Moves up: it diffs the new tree against the old and applies the minimal set of real DOM operations.
15
3. "Why do keys matter in a list?" Probing: identity. Stalls: "For uniqueness." Moves up: they tell the diff which items are the same across renders, so unchanged nodes are kept rather than recreated, preserving focus and state.
16
4. "What alternatives exist?" Probing: breadth. Stalls: "None." Moves up: fine-grained reactivity as in Solid or Svelte, which updates the exact binding and needs no diff at all.
Use cases:domperformanceframeworks