DOM vs
Virtual DOM

When the browser loads an HTML file, it parses the markup and builds a tree of Node objects. The root is the `document` object. Every HTML tag becomes an Element node, every piece of text becomes a Text node, and every attribute becomes an Attr node. Parent-child relationships in HTML are mirrored as parent-child relationships in the tree.

<!-- This HTML... -->
<div id="app">
  <h1>Hello</h1>
  <p>World</p>
</div>

<!-- ...becomes this DOM tree:
document
  └── html
       ├── head
       └── body
            └── div#app
                 ├── h1
                 │    └── "Hello" (text node)
                 └── p
                      └── "World" (text node)
-->

JavaScript interacts with the DOM through APIs like `document.getElementById()`, `document.createElement()`, `element.appendChild()`, and `element.innerHTML`. Every call directly mutates the live tree, and the browser must react to each change.

// Creating and inserting a new element
const newItem = document.createElement('li');
newItem.textContent = 'New Item';
document.getElementById('list').appendChild(newItem);

// Modifying an existing element
document.querySelector('.title').style.color = 'red';
document.querySelector('.title').textContent = 'Updated!';

Every DOM change can trigger the browser's rendering pipeline: Style Calculation → Layout (Reflow) → Paint → Composite. If you change an element's width, the browser must recalculate the layout of every element that could be affected. Changing 50 elements in a loop can trigger 50 separate reflow cycles. This is the core performance problem.

The browser reads your HTML file top-to-bottom and constructs the DOM tree. Each tag becomes a node object. This happens once on initial page load.

The browser parses all CSS (stylesheets, inline styles, browser defaults) and builds the CSSOM (CSS Object Model) — a tree of style rules. Each DOM node is matched against CSS selectors to determine its computed styles.

The browser merges the DOM and CSSOM into a Render Tree. Only visible elements are included — elements with `display: none` are excluded. Each node in the render tree knows its content AND its computed styles.

The browser calculates the exact position and size of every element in the render tree. This is the most expensive step. Changing one element's width can cascade and force the browser to recalculate the layout of its siblings, parents, and children.

Finally, the browser fills in pixels (paint) and combines layers (composite). Changes that only affect `opacity` or `transform` skip layout entirely and only trigger compositing — which is why CSS animations using `transform` are so much faster than animating `width` or `top`.

A Virtual DOM node is not a DOM element. It is a simple JavaScript object with properties like `type`, `props`, and `children`. Creating and comparing JavaScript objects is orders of magnitude faster than creating and comparing real DOM nodes, because there's no browser rendering overhead.

// When you write this JSX:
<div className="card">
  <h1>Hello</h1>
</div>

// React creates this Virtual DOM object:
{
  type: 'div',
  props: { className: 'card' },
  children: [
    {
      type: 'h1',
      props: {},
      children: ['Hello']
    }
  ]
}

React maintains TWO virtual DOM trees in memory at all times: the 'current' tree (representing what's on screen right now) and the 'work-in-progress' tree (representing the next update). When state changes, React builds the new tree, diffs it against the current tree, and patches only the differences.

Reading properties from real DOM nodes is slow because it forces the browser to flush pending style calculations. Comparing two JavaScript objects in memory is essentially free. The Virtual DOM lets React do all its comparison work without touching the browser at all.

If the root element type changes (e.g., from `

// Before: React renders a <div> tree
<div><Counter /></div>

// After: React sees <section> — completely different type!
<section><Counter /></section>
// Result: Old <div> is destroyed. Counter is unmounted and remounted.
// All state inside Counter is LOST.

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

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

// React does NOT destroy the <div>. It only runs:
// element.className = 'new';
// element.style.color = 'blue';

// BAD: No keys — inserting at top re-renders the entire list
{items.map((item, index) => <li>{item}</li>)}

// GOOD: Stable keys — React tracks each item individually
{items.map(item => <li key={item.id}>{item.name}</li>)}

// TERRIBLE: Using index as key when list order can change
{items.map((item, i) => <li key={i}>{item}</li>)} // DON'T!

The old stack reconciler processed the entire component tree in one synchronous pass. If you had 10,000 list items to update, the browser was frozen until React finished diffing and patching all of them. Animations would stutter, typing would lag, and the UI felt unresponsive.

Fiber splits the work into small chunks (one fiber per component). After processing each chunk, React checks: 'Is there something more urgent to do?' (like handling user input). If yes, it pauses the current work and handles the urgent task first. This is the foundation of React 18's concurrent features.

Fiber assigns priority levels to different types of updates. User input (typing, clicking) gets the highest priority. Data fetching results get medium priority. Off-screen rendering gets the lowest. This is how `useTransition` and `useDeferredValue` work under the hood.

With vanilla JavaScript, the naive approach rebuilds the entire list by setting `innerHTML`. This destroys all 1,000 existing DOM nodes and creates 1,000 new ones — triggering a massive reflow. The smarter approach targets only the changed node, but you have to manually track which one changed.

// ❌ NAIVE: Rebuilds the ENTIRE list (1,000 DOM nodes destroyed + recreated)
list.innerHTML = items.map(i => `<li>${i.text}</li>`).join('');

// ✅ SMART: Only update the single changed item
const targetLi = list.children[changedIndex];
targetLi.textContent = newText;
// But YOU must track which index changed — error-prone in complex UIs

With React, you simply update the state. React's diffing algorithm automatically detects that only ONE item changed in the list. It generates a single DOM operation to update that specific `

// You just update state — React figures out the minimal DOM changes
setItems(prev =>
  prev.map((item, i) =>
    i === changedIndex ? { ...item, text: newText } : item
  )
);

// React's diff result: "Only item at index 42 changed"
// React runs: list.children[42].textContent = newText;
// The other 999 <li> elements are completely untouched!

The Virtual DOM adds overhead — React must create the virtual tree, diff it, and then apply changes to the real DOM. For simple, targeted updates (like changing one element's text), direct DOM manipulation with `element.textContent = 'new'` is actually faster. The Virtual DOM wins when updates are complex and scattered across many components.

React absolutely touches the real DOM — that's how pixels get on your screen! The Virtual DOM is just an intermediary. React calculates the MINIMUM set of real DOM operations needed and executes them in a batch. It's not avoiding the DOM, it's minimizing contact with it.

While React popularized the concept, the idea of diffing a virtual representation against a real one existed before React. Vue.js, Preact, Inferno, and other frameworks also use virtual DOM implementations. Svelte takes a completely different approach by compiling away the virtual DOM entirely at build time.

The real value of the Virtual DOM isn't raw speed — it's that developers can write simple, declarative UI code (describe WHAT the UI should look like) and let the framework figure out HOW to efficiently update the real DOM. This is a massive productivity and maintainability win.