The Virtual DOM
Updating a web page by hand means finding the right element and changing it, which gets fragile fast as an interface grows. The virtual DOM is the idea that made a different approach popular: describe what the UI should look like, and let a library work out the minimal changes to the real page. This page defines the concept and the machinery around it; for how it sits within reactive frameworks, see reactivity systems, and for the real-DOM costs it tries to manage, see DOM rendering performance.
This is a definition of the term and its trade-offs, not a framework tutorial.
What you'll learn
What the virtual DOM is
The concept is simpler than its reputation suggests.
A definition
The virtual DOM is a lightweight, in-memory description of what the user interface should look like, kept as plain objects rather than real page elements. When the interface needs to change, a new description is created and compared against the previous one, and only the differences are applied to the actual page. It is a representation, not a faster kind of DOM.
How it works
Three steps turn a description into a screen update.
Render, diff, patch
First, the application renders its current state into a virtual tree of objects. Second, that tree is compared against the previous one to find what changed, a step called diffing. Third, the library applies just those changes to the real DOM, the patch. Because the costly real-page updates are limited to what actually changed, the interface avoids unnecessary work, which connects directly to DOM rendering performance.
Why it exists
The virtual DOM solves a problem of both correctness and effort.
Declarative updates
Manually updating the DOM as state changes is error-prone, because you must track every element that depends on every piece of data. The virtual DOM lets you instead describe the result you want for the current state and leave the updates to the library. This declarative style, rather than raw speed, is its main benefit, and it relates to the reactive approach in reactivity systems.
The virtual DOM in practice
The idea was popularised by one framework and then reconsidered by others.
Adoption and alternatives
React brought the virtual DOM into the mainstream, and several frameworks followed. Others, judging the diffing overhead unnecessary, take different routes: some compile components to direct DOM updates, and some use fine-grained reactivity to update exactly what changed without a diff. These alternatives are part of the story in framework evolution.
Related concepts
A few neighbouring ideas make the virtual DOM easier to place.
Reconciliation and the real DOM
Reconciliation is the name for the diff-and-patch process that decides how the virtual tree maps onto real changes. The real DOM is the browser is actual element tree, the thing reconciliation ultimately updates and whose update cost the virtual DOM exists to manage. Both connect to the browser rendering pipeline, which determines what those updates actually cost.
A common misconception
One claim is repeated so often it deserves a direct answer.
It is not automatically faster
The virtual DOM is not inherently faster than updating the DOM directly. Careful direct updates can be quicker, since diffing has its own cost. What the virtual DOM provides is a simpler, declarative way to keep the interface correct, often with good-enough performance, not a guarantee of speed. The real-DOM costs it manages are detailed in DOM rendering performance.
Frequently Asked Questions
What is the virtual DOM?
The virtual DOM is a lightweight, in-memory description of what the user interface should look like, held as plain objects. When state changes, a new description is compared against the old one and only the differences are applied to the real page.
How does the virtual DOM work?
In three steps: the app renders its state into a virtual tree, that tree is diffed against the previous one to find changes, and only those changes are patched onto the real DOM. This limits costly real-page updates to what changed.
Is the virtual DOM faster than the real DOM?
Not inherently. Careful direct DOM updates can be faster, since diffing has its own cost. The virtual DOM's main benefit is a simpler, declarative way to keep the UI correct, often with good-enough performance.
What is reconciliation?
Reconciliation is the process of comparing the new virtual tree against the previous one and applying the minimal set of changes to the real DOM. It is how a framework decides what actually needs to update on screen.
Read next: browser memory management, or the Concepts hub.
Want the wider context?
See how the virtual DOM fits among reactivity systems.
Read: Reactivity Systems →