Vue 3.6 Vapor Mode: the first major-framework attempt to skip the virtual DOM

Vue 3.6 entered beta in early 2026 with a rendering mode that does something no major UI framework has done before: it removes the virtual DOM from the hot path. The feature is called Vapor Mode, and it is currently shipping at v3.6.0-beta.12 (May 15, 2026), with stable release targeted for Q4 2026. The Vue 3.5 line continues in parallel (v3.5.34, May 6, 2026) while 3.6 stabilizes.

For Vue developers the practical question is when to actually use it. For everyone else, Vapor Mode is the most interesting rendering experiment in mainstream UI tooling since hooks shipped in React.

What Vapor Mode actually is

Vapor Mode is an opt-in rendering path that runs alongside the existing Vue rendering model. Components marked for Vapor Mode compile to code that updates the DOM directly via fine-grained reactivity, skipping the virtual DOM diff entirely. Components not marked for Vapor Mode continue to render through the existing virtual-DOM path. The two coexist in the same application.

The target Evan You has cited is a 2 to 4 times render-performance improvement on dynamic UIs. The improvement is largest on components with lots of small state changes, where the cost of the virtual-DOM diff dominates the work. On static UIs or components that update infrequently, the improvement is smaller because there is less to optimize.

The current state, per the Vue core team, is “feature-complete but unstable.” The features are present, the API is in roughly its final shape, but edge cases (especially around mixed-mode interop where a Vapor component sits inside a virtual-DOM component or vice versa) still have rough edges.

Why the virtual DOM became the tax

For most of the last decade, the virtual DOM has been the dominant shape of UI rendering. React popularized the pattern: maintain a JavaScript representation of the desired UI, diff it against the previous representation when state changes, then apply only the minimum set of DOM updates. Vue, Preact, Inferno, and most React alternatives followed the same shape.

The virtual-DOM pattern’s payoff was simplicity. Developers describe the UI as a function of state, the framework figures out which specific DOM nodes need to change. The cost, increasingly visible as applications grew, is that the diff itself is real work the browser has to do on every state change. For a button click that updates a single counter, the framework still walks the entire component tree to figure out that only one text node moved. On a fast machine the cost is invisible. On a slower device or a complex dashboard with frequent updates, it adds up.

Two frameworks built later avoided the virtual DOM from the start. Svelte compiles components at build time into imperative DOM operations, so the diff never has to run. Solid uses fine-grained reactivity to track exactly which DOM nodes depend on which signals, updating each one directly when its signal changes. Both produce faster runtime rendering than virtual-DOM frameworks on dynamic UIs.

Vapor Mode is Vue’s attempt to bring that approach into an existing virtual-DOM framework without forcing the entire ecosystem to migrate.

How Vapor Mode bypasses the virtual DOM

Under Vapor Mode, the Vue compiler produces a different output for marked components. Instead of compiling to a render function that returns a virtual-DOM tree, it compiles to code that creates DOM nodes directly and wires reactive subscriptions to the specific attributes, text content, or child nodes that depend on each piece of state.

The reactivity system underneath was rewritten for this purpose, internally referred to as Alien Signals. The rewrite makes the dependency tracking precise enough that the framework can identify, at the per-DOM-node level, exactly which nodes need to update when any given piece of state changes. There is no diff because there is no need for one.

For developers, the authoring experience does not change much. The template syntax, the Composition API, the reactivity primitives (ref, reactive, computed, watch) all work the same. The difference shows up at compile time and at runtime, not at the template level.

How it compares to Solid and Svelte

Solid and Svelte both avoid the virtual DOM, but they do it differently from Vapor Mode and from each other.

Solid uses JSX and fine-grained reactivity from day one. Components are functions that run once to set up reactive dependencies, then never re-execute. The result is one of the fastest runtimes in the category, but the authoring model is fundamentally different from React’s: components do not re-render in response to state changes. Developers coming from React have to unlearn intuitions.

Svelte compiles components at build time into imperative DOM operations. The runtime is tiny because most of the work happens at compile time. The authoring model is closer to plain HTML and JavaScript than to JSX or template-DSL approaches, which makes Svelte cleaner to read but harder to share patterns with non-Svelte codebases.

Vapor Mode sits between the two. The authoring model is unchanged from Vue 3, so existing Vue developers keep their muscle memory. The runtime cost is now closer to Solid’s. The trade is that Vapor Mode is retrofitted into an existing framework, so the integration points (how Vapor components interact with virtual-DOM components, how third-party libraries that assume the virtual-DOM shape behave) need more care than the from-scratch approaches.

What this means for working Vue developers

For Vue teams already shipping production code, the short answer is nothing changes immediately. Vapor Mode is opt-in, the existing virtual-DOM path keeps working, and the Vue 3.5 line is production-ready as before. No migration is required to stay on the existing approach.

For teams hitting render-performance walls on dynamic UIs (real-time dashboards, complex form-state UIs, anything with hundreds of frequent state updates per second), Vapor Mode is the first optimization worth evaluating before committing to a framework switch or a deep manual rewrite. Marking the heaviest components for Vapor Mode while leaving the rest of the application unchanged is the intended adoption pattern.

For teams starting new Vue applications, the current guidance from the Vue core team is to default to the existing path and opt in to Vapor Mode for bounded regions where the performance benefit matters. Vue 3.6 itself is still beta. Production-wide Vapor Mode adoption is not recommended yet.

When to actually adopt it

Three practical filters:

1. Wait for Vue 3.6 stable. The current beta is feature-complete but explicitly described as unstable, and mixed-mode interop has rough edges. The stable target is Q4 2026. Production adoption before then carries real risk.
2. Identify the actual bottleneck first. If render performance is not currently a problem, Vapor Mode is not currently a solution. The improvement is measurable on dynamic UIs, marginal on primarily static ones.
3. Treat it as opt-in. Even when 3.6 stabilizes, the Vue core team’s guidance is to mark specific components for Vapor Mode, not to flip the application wholesale.

The Vue Vapor positioning for 2027 is that Vapor Mode becomes the recommended default for new applications. That timeline is contingent on the mixed-mode interop work landing cleanly. Teams making framework decisions today should treat Vapor Mode as real-but-experimental rather than as the new Vue default.

The broader signal is that the virtual DOM is no longer the unquestioned default for new UI frameworks. Solid and Svelte proved the alternative was viable. Vue 3.6 Vapor Mode is the first attempt to bring that approach into an established framework without forcing the ecosystem to migrate. If it lands cleanly, React’s response will be the next thing to watch.

Sources cited

1. Vue Core releases on GitHub github.com
2. Vue Vapor repository github.com
3. Evan You: preview of Vue 3.6 Vapor Mode (Vue.js Nation 2025) vueschool.io
4. Vue.js 2025 in review and a peek into 2026 vueschool.io