The Virtual DOM is a programming abstraction in which a complete in-memory copy of the Document Object Model is maintained, diffed against a previous copy, and then the minimal set of changes is applied to the actual DOM — a process that sounds efficient until you realize it requires building the entire tree twice in order to avoid updating the parts that didn’t change.
The Virtual DOM was introduced by React in 2013, and it solved a genuine problem: direct DOM manipulation in complex JavaScript applications was error-prone, imperative, and scattered across event handlers that nobody could reason about. The Virtual DOM replaced this chaos with a functional model — describe what the UI should look like, and let the framework figure out how to get there.
This was a real insight. The implementation — maintaining a shadow copy of the entire document and running a tree-diffing algorithm on every state change — was the part that future archaeologists would find puzzling.
“I evaluated HTMX. And rejected it. And then we used it. For everything.”
— The Caffeinated Squirrel, who built several virtual DOMs before discovering hx-swap, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX
How It Works
- State changes
- The entire component tree re-renders into a new Virtual DOM (in memory)
- The new Virtual DOM is compared to the previous Virtual DOM (the “diffing” phase)
- The minimal set of actual DOM operations is computed (the “reconciliation” phase)
- Those operations are applied to the real DOM
Steps 2 through 4 exist entirely so that step 5 can be small. The framework builds the entire house twice, compares every brick, and then moves the three bricks that changed. This is called “efficient rendering.”
An alternative approach — telling The DOM which three bricks changed — was available the entire time. It was called document.getElementById().innerHTML. It was not declarative, and therefore it was not a framework, and therefore it was not presented at conferences.
The Reconciliation Problem
The tree-diffing algorithm at the heart of the Virtual DOM is, in the general case, O(n³). React reduces this to O(n) by making two assumptions:
- Elements of different types produce different trees (so don’t bother diffing them)
- The developer provides
keyprops to hint which elements are stable
The key prop is important. Without it, React cannot tell whether a list item moved, was added, or was removed. With it, React can track identity across renders. The practical result is that every React developer has, at some point, used index as a key, watched the UI break in subtle ways, googled “react key prop,” read the documentation, and switched to a stable identifier — a rite of passage so universal it could be a certification exam.
The Squirrel’s Manifesto
The most ambitious attempt to improve upon the Virtual DOM was the 827-line architectural manifesto known as Copper.js, authored by the Caffeinated Squirrel on a single November evening. The manifesto proposed: reactive signals instead of virtual DOM diffing, event-driven updates instead of full re-renders, idle-first architecture, and — in what scholars consider the document’s most visionary passage — a blockchain.
The manifesto was philosophically correct about everything. The Virtual DOM is wasteful. Full re-renders are unnecessary. Signals are more precise. But the manifesto required seven frameworks and a custom morphing algorithm to implement what six HTMX swap targets accomplished by not having a Virtual DOM at all.
THE SQUIRREL DESIGNED THE CATHEDRAL
THE LIZARD BUILT THE CHAPEL
— The Lizard, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX
The Server Sends HTML
The deepest irony of the Virtual DOM is that it exists to efficiently update the browser’s document, when the browser was already designed to efficiently receive documents from a server.
The original architecture of the web — server renders HTML, browser displays it — required no virtual copy, no diffing algorithm, no reconciliation phase, and no key props. The server knew what changed because the server computed what changed. The browser received the result. Nobody maintained two copies of anything.
HTMX returned to this model in 2020. The server sends HTML. The client says “okay.” The Virtual DOM is not optimized. The Virtual DOM is absent.
Measured Characteristics
- Copies of the DOM maintained: 2 (one real, one imaginary)
- Tree-diffing complexity (general): O(n³)
- Tree-diffing complexity (React’s optimized): O(n)
- Tree-diffing complexity (server sends HTML): O(0)
- Key-related bugs debugged per React developer: ~3 per year
- Frameworks that use a Virtual DOM: React, Vue 2, Preact, Inferno
- Frameworks that don’t: HTMX, Svelte, SolidJS, Alpine, the web (1993–2013)
- The server sends HTML. The client says: “okay”
