Vue 3.6's Vapor Mode Just Hit Feature-Complete. It Skips the Virtual DOM, and You Don't Have to Rewrite Anything to Try It.
Vue 3.6 reached release-candidate status on July 18, with the intended feature set for Vapor Mode locked in since the first release candidate. If you haven't been following Vue closely, the headline is simple: Vue now has a compilation mode that skips the virtual DOM entirely, and you can turn it on for a single component without rewriting the rest of your app. For anyone running a content-heavy site or an app with a few genuinely slow components, that's a more useful shape of feature than most framework releases ship.
What Vapor Mode actually does
Every version of Vue up to this point has rendered the same way React and most component frameworks do: build a virtual representation of the DOM, diff it against the previous version, then patch the real DOM with the difference. It's fast enough for almost everything, and it's the reason Vue and React both scaled to the size they did. But diffing has an inherent cost, and for components that update constantly (think a live dashboard, a large sortable table, or a component tree with a lot of independent reactive state) that cost adds up.
Vapor Mode compiles templates directly to DOM operations instead, skipping the virtual DOM step entirely for any component that opts in. As of the current release candidate, Vapor has full behavioral parity with the standard rendering path, with one documented exception: <Suspense> isn't supported under Vapor yet.
The adoption model is the actual news
Plenty of frameworks have shipped a faster rendering mode before. What makes this one worth paying attention to is that it's opt-in at the component level, not a framework-wide migration. You can take one slow, high-update-frequency component in an existing Vue 3 app, mark it for Vapor compilation, and ship that change without touching anything else in the codebase. If it works, keep it. If it doesn't, revert one component, not a migration you committed six sprints ago.
That's a meaningfully different bet than most "faster rendering engine" releases ask you to make. React Server Components, Svelte 5's runes, and most comparable rewrites in other frameworks ask you to either adopt the new model for the whole app or maintain two mental models side by side indefinitely. Vue's version lets you test the water with a single component, on a live app, before deciding whether the rest of your codebase is worth the change.
The benchmark, and why I'm not fully trusting it yet
The number circulating is 100,000 components mounting in roughly 100 milliseconds, described as putting Vapor Mode in the same range as SolidJS, which has built its entire reputation on skipping virtual DOM overhead from day one. That's a real, meaningful number if it holds up outside a synthetic benchmark. It's also exactly the kind of number that framework release benchmarks tend to overstate relative to what you'll actually see in a real app with real data shapes, real network waterfalls, and real component trees that don't mount 100,000 identical nodes in a clean test harness.
I'd treat that benchmark as "promising enough to test on one component," not "proven enough to plan a rewrite around." The honest move with any framework-level performance claim is to reproduce it against your own slowest component before you believe it applies to your app.
What this means if you're running an existing Vue app
Vue 3.6 is still a release candidate, not a stable release, as of this writing. Nothing here is a reason to touch a production app today. But if you maintain a Vue codebase with even one component that's a known performance problem (the kind everyone on the team has a workaround for, like debouncing a re-render that shouldn't need debouncing), this is worth bookmarking for the moment 3.6 goes stable. The entire value proposition is that you get to test the win in isolation before deciding whether it's worth more of your time.
For anyone building a new project, I wouldn't pick a framework based on a pre-1.0 rendering mode. Pick Vue for the reasons you'd normally pick Vue, and treat Vapor as a future lever you can pull on a specific component once the ecosystem (component libraries, SSR support, the usual list of things that lag a framework's core release) catches up.
The honest take
The part of this release I actually like isn't the speed number, it's the migration boundary. Most performance rewrites in frontend frameworks force an all-or-nothing decision, and that decision usually gets punted indefinitely because nobody wants to own a full-app rewrite for a performance problem that's currently only annoying, not urgent. A per-component opt-in changes the actual cost of trying it from "convince the team to commit to a rewrite" to "try it on the one component everyone already agrees is slow." That's a much lower bar, and lower bars are how performance work like this actually gets adopted instead of staying a conference-talk feature nobody ships.
Where I could be wrong: <Suspense> not being supported yet is a real gap if your app leans on it for data-loading patterns, and pre-1.0 rendering modes have a track record of surfacing edge cases once real apps with messier component trees start using them at scale. Wait for 3.6 stable, and don't be the first production app to find the edge case Vue's own test suite didn't catch.
Author
Lukas
@lukcombinator