DOM vs Virtual‑DOM
Visualize how a click creates a new VDOM, how React diffs it, and how the real DOM updates. Also see why some frameworks avoid a VDOM.
Refresh to see the 'Loading' state trigger in your browser.
Strategy
The Virtual‑DOM is a lightweight JavaScript representation of the DOM. React creates a new VDOM on state changes, diffs it against the previous VDOM, and patches the real DOM efficiently.
Hydration
Server sends finished HTML. Browser 'hydrates' it for interactivity.
Inspect Network
Open DevTools > Network. Look forCache-Controlheader. For DOM, you will sees-maxage=30, stale-while-revalidate
DOM vs Virtual‑DOM
See how a user interaction creates a new VDOM, how React diffs it, and how the real DOM updates.
Old VDOM
New VDOM
Patches (diff result)
[
{
"type": "PROPS",
"node": {
"type": "text",
"props": {
"nodeValue": "Count: 1"
}
},
"propChanges": {
"nodeValue": "Count: 1"
}
}
]Real DOM after update
<div class="p-4 rounded-xl bg-zinc-900/30 border border-zinc-800"> <button class="px-4 py-2 bg-purple-600 text-white rounded">Count: 1</button> </div>
Why Some Frameworks Skip VDOM
React / Next.js
Uses a VDOM to batch updates and minimise DOM writes.
Solid
Compiles fine‑grained reactive primitives directly to DOM updates, no VDOM.
Svelte
Compile‑time analysis generates optimal DOM patches, eliminating runtime VDOM.
Qwik
Resumable architecture streams only the needed parts, avoiding a central VDOM.
The VDOM Philosophy
Why does React still use it?
React was built on the idea of Pure Functions. By treating the UI as a function of state, the VDOM allows React to compute a "target state" without caring about the current state of the browser. This abstraction also makes React Native possible—the same VDOM logic can patch iOS/Android native views instead of browser DOM nodes.
If there is no VDOM, how does the browser work?
The browser always has a Real DOM. Frameworks like Svelte andSolid don't use a VDOM because they realize that "diffing" is runtime overhead.
Instead, they compile your code into direct instructions likep.textContent = count. When the count changes, they run *only* that line of code. They learned that the "Virtual" step is often unnecessary if you can track exactly which variable affects which part of the UI at compile-time.
The Verdict
"The VDOM is a great abstraction, but it's a runtime cost. New frameworks treat the problem as a Compilation problem rather than a Reconciliationproblem."