What ships in the release candidate
Vue's core team pushed 3.6.0-rc.1 on July 18, 2026, marking Vapor Mode as feature-complete, and followed it four days later with rc.2. A stable 3.6 release is expected in autumn 2026. The headline feature has been years in the making: Evan You, Vue's creator, first previewed the idea publicly at Vue.js Nation in 2025, and it now lands as an opt-in compiler mode rather than a rewrite of the framework.
Every version of Vue up to this point, like React and most component frameworks, renders by building a virtual DOM: an in-memory representation of the page that gets diffed against the previous version so the framework knows what actually changed before touching the real browser DOM. The technique became standard in the mid-2010s because comparing lightweight in-memory objects is usually cheaper than touching the browser's actual document structure directly for every change, but that diffing step is still extra work happening on every single update, and it scales with how large and deeply nested a component tree gets. Vapor Mode removes it. Components marked for Vapor compile straight to imperative DOM instructions, so when a piece of state changes, Vue updates exactly the DOM nodes tied to that state and nothing else, with no comparison step in between.
Why it's opt-in, not a rewrite
A component switches into Vapor Mode with <script setup vapor>, and Vapor and standard virtual-DOM components can sit in the same application without extra wiring, calling each other normally. That matters because Vapor Mode doesn't support everything Vue does today: it works only with <script setup> single-file components, not the older Options API, and anything that depends on virtual DOM nodes or a component's public instance proxy isn't available inside a Vapor component. In practice, that means existing Composition API logic can move over largely unchanged, but code built around VNode manipulation or instance introspection can't yet make the jump.
The Vue team has described the goal explicitly: make the virtual DOM optional, not obsolete. Teams can convert a handful of performance-sensitive components, leave the rest of the app as it is, and revert individual components later if something doesn't work, rather than committing to an all-or-nothing migration. That reversibility is a deliberate contrast with how most frameworks have historically handled a rendering-model change: usually it means a new project or a rewrite, not an incremental switch inside an app already in production.
The performance case
The published numbers are steep. Vue's own benchmarks describe renders up to 97% faster in extreme cases, with one demo mounting 100,000 components in roughly 100 milliseconds, and bundle sizes for Vapor-only components shrinking 20 to 50%. Third-party benchmarking has put Vapor's rendering speed in the same range as Solid.js and Svelte 5, two frameworks that were designed without a virtual DOM from the start rather than having one bolted on as an option.
Even apps that never touch Vapor Mode get something out of 3.6: the @vue/reactivity package underneath all of Vue, Vapor or not, has been rewritten on top of the alien-signals library. Signals are a way of tracking dependencies between reactive values so that only the code that actually reads a given value re-runs when it changes, rather than re-checking a wider tree of possibly-affected code; the Vue team says the rewrite lowers overhead and scales better in component trees with many nested reactive values, along with using less memory generally. That change ships to every 3.6 app automatically, with no opt-in required.
What it means in practice
For teams already on Vue 3's Composition API, the release candidate is a reasonable point to start testing Vapor Mode against a few isolated, render-heavy components, such as large lists or data grids, rather than converting a whole application. Anything still built on the Options API, or on code that pokes at VNodes or component instances directly, won't be eligible for Vapor yet and should wait for later framework guidance on a migration path. Because 3.6 is still in release candidate status, production use should wait for the stable release, but the reactivity rewrite alone is a reason to test the RC early: it's a free improvement that doesn't require touching a single component.
