Vue 3.6 Enters Beta: Vapor Mode Complete, Reactivity Revamped

Vue 3.6 Enters Beta: Vapor Mode Complete, Reactivity Revamped

lschvn5 min read

Vue 3.6 beta has landed, and it marks a pivotal moment for the framework's evolution. The headline achievements: Vapor Mode has reached feature parity with the virtual DOM system, and the reactivity package has undergone a foundational refactor using the alien-signals library. Together, these changes position Vue 3.6 as one of the most significant releases in the framework's history.

Vapor Mode: Feature Complete

Vapor Mode is Vue's answer to a question the frontend world has been asking for years: what if we could have the ergonomics and component model of Vue with the runtime efficiency of compiled, direct-DOM frameworks like Solid or Svelte?

The core idea is straightforward. In the current Vue 3 compilation model, templates are compiled to render functions that produce virtual DOM nodes. When state changes, Vue creates a new virtual DOM tree and diffs it against the previous tree to determine the minimal set of real DOM mutations needed. This vdom diffing is fast enough for most applications, but it is not free, the creation of vnode objects and the diffing algorithm both consume CPU and memory.

Vapor Mode replaces this entirely. Instead of compiling templates to render functions, it compiles them to JavaScript that directly calls DOM APIs. A v-for loop over a list becomes a loop that calls document.createElement and appendChild directly. A v-if becomes a conditional that inserts or removes nodes. The result is a bundle with no virtual DOM runtime and fewer allocations at runtime.

The Vue team first outlined Vapor Mode in late 2024 and has been iterating on it throughout 2025. With 3.6 beta, the team has reached a milestone: Vapor Mode now supports all stable features available in virtual DOM mode. That means components using v-if, v-for, v-show, v-model, slots, Suspense, and the Composition API should work in Vapor Mode without modification.

The exception is Suspense in Vapor-only mode, it is not yet supported, though Vapor components can render inside a vdom-based Suspense boundary.

What Changes in Practice

For developers, the transition is designed to be mostly invisible. You write Vue components the same way. Under the hood, the compiler chooses the Vapor path. The bundle that reaches the browser is smaller because the vdom runtime is gone, and the runtime behavior is faster because DOM updates bypass the diffing step.

For library authors and developers using Vue's lower-level APIs, h(), createVNode, direct component instance manipulation, there may be adjustments needed. Vapor Mode works at the template compilation level, so code that goes through the render function pipeline still functions normally.

@vue/reactivity Overhaul with alien-signals

The reactivity system, the engine that powers Vue's ref(), reactive(), computed(), and watch(), has been refactored to use alien-signals. This is a foundational change rather than a surface API change, ref() and reactive() still work the same way.

The motivation is performance. The previous reactivity implementation, while well-engineered, had some overhead from the way it tracked dependencies and scheduled updates. alien-signals is designed with a narrower focus: execute reactive computations as quickly as possible with minimal memory allocation. The Vue team evaluated several signals implementations and chose alien-signals for its benchmark performance and its alignment with Vue's update scheduling model.

This refactor affects the @vue/reactivity package directly, which is also published separately on npm and used in projects outside of Vue, including some Solid.js integrations and other frameworks that adopted Vue's reactivity primitives.

Hydration Improvements

3.6 beta also ships a large batch of hydration-related fixes, over 30 commits in the beta.10 release alone. Vue 3's server-side rendering hydration, which matches the server-rendered HTML against the client-side component tree, has been tightened across edge cases involving:

  • Multi-root hydration boundaries and async components
  • Teleport targets with missing or changing targets
  • Slot content hydration with fallback content
  • Dynamic components rendered across SSR and client boundaries

These are the kind of fixes that only surface in complex real-world applications, and their presence indicates Vue 3.6 is being hardened for production use cases at scale.

Looking Toward Stable

Vue 3.6 entering beta means the feature set is locked and the team is focused on stabilization and compatibility fixes. Barring major regressions discovered during the beta period, the stable release should follow within weeks. The Vue team has been iterating quickly, beta.1 shipped on March 30 and beta.10 was published on April 13, indicating active development.

For project teams running Vue 3, now is a good time to test the 3.6 beta against your application, particularly if you use Vapor Mode-compatible code patterns. The Vue team's policy is to avoid breaking changes in minor releases, but the reactivity internals change in 3.6 means edge cases in custom reactivity usage are worth testing.

Frequently Asked Questions

Related articles

More coverage with overlapping topics and tags.

Astro 7.0.0-beta.6 Stabilizes Route Caching and Promotes JSX Whitespace Compression to Default
frameworks

Astro 7.0.0-beta.6 Stabilizes Route Caching and Promotes JSX Whitespace Compression to Default

Astro 7.0.0-beta.6 (June 19, 2026) promotes the experimental route caching API to top-level stable, dropping the experimental.cache and experimental.routeRules flags in favor of a new top-level cache config and a cache helper. Beta.5 (June 18) made 'jsx' the default compressHTML mode, changing the rendered output of every site that relied on the legacy whitespace preservation. Beta.6 also pulls in @astrojs/markdown-satteri 0.3.1-beta.2.
Astro 7.0.0-beta.4 Makes Sätteri the Default Markdown Processor, Promotes Advanced Routing, Custom Logger, and Queued Rendering to Stable
frameworks

Astro 7.0.0-beta.4 Makes Sätteri the Default Markdown Processor, Promotes Advanced Routing, Custom Logger, and Queued Rendering to Stable

Astro 7.0.0-beta.4 (June 15, 2026) flips the Sätteri Rust-based Markdown pipeline on by default, removes the experimental flag from advanced routing, the custom logger, and the new rendering engine, deletes the deprecated astro db/login/logout/link/init CLI commands, and folds the dev-server background mode added in alpha.2 into the default CLI.
Astro 6.4.4 Patches Seven Bugs Across Routing, i18n, and Dev Experience
frameworks

Astro 6.4.4 Patches Seven Bugs Across Routing, i18n, and Dev Experience

Astro 6.4.4 is a patch release fixing issues with dynamic routes, i18n domain routing, client-side component editing, and route pattern casing.

Comments

Log in Log in to join the conversation.

No comments yet. Be the first to share your thoughts.