Vue 3.5's Reactivity Overhaul: A 56% Memory Diet for Your Reactive Graph

The Update Nobody Had to Change Their Code For

Every so often a framework release comes along that doesn't add a flashy new syntax but instead rewires the engine under the hood. Vue 3.5 (codenamed "Tengen Toppa Gurren Lagann") is one of those releases. Announced as a minor version with no breaking changes, it shipped a rewrite of Vue's reactivity system that Vue's reactivity system has undergone another major refactor that achieves better performance and significantly improved memory usage (-56%) with no behavior changes. That's a striking number for a system that millions of production apps depend on every day, and it happened without anyone needing to touch their ref() or reactive() calls.

What Actually Changed

Vue's reactivity has always worked by tracking dependencies between reactive state and the effects (renders, computeds, watchers) that read them, so that when state changes, only the right things re-run. That tracking graph is powerful but expensive to maintain, especially at scale. In 3.5, the internal data structures used to represent dependency links were reworked, and as a side effect the refactor also resolves stale computed values and memory issues caused by hanging computeds during SSR — a class of bugs that had quietly annoyed server-rendering users for a while.

The practical upshot, according to independent write-ups digging into the release, is that the reactivity system has been significantly refactored, leading to a 56% reduction in memory usage and up to 10 times faster operations on large, deeply reactive arrays. If you've ever built a data-heavy dashboard or a table with thousands of rows wrapped in reactive(), that array performance number is the one that matters most in practice — deep reactivity on big collections used to be a known weak spot.

Reactive Props Destructure Finally Graduates

The other headline feature in 3.5 is less about raw performance and more about ergonomics, but it's built on the same reactivity foundations. Reactive Props Destructure — long available behind a flag — is now on by default. As the Vue team puts it, Reactive Props Destructure has been stabilized in 3.5. With the feature now enabled by default, variables destructured from a defineProps call in script setup are now reactive. Previously, destructuring props in `` silently broke reactivity, a footgun every Vue developer eventually stepped on. Now the compiler quietly rewrites destructured variables back into tracked property accesses behind the scenes, so const { count } = defineProps(...) just works, including for default values.

Part of a Bigger Pattern

None of this happened in a vacuum. Vue's core team has been steadily iterating on reactivity internals across 3.3, 3.4, and now 3.5, and it's not stopping here — public comments from creator Evan You point to reactivity performance as a headline focus of the upcoming Vue 3.6 release as well, continuing to build on the trend from previous versions like Vue 3.4 and 3.5, focusing on optimizing the core reactivity system.

This is worth situating in the broader JS framework landscape. Fine-grained, signal-based reactivity — the idea that state changes should trigger the minimum possible amount of re-computation — has become the industry's shared obsession. Solid popularized signals as a first-class primitive, Svelte 5 rebuilt itself around runes, Preact and even React (via compiler-driven memoization) are chasing the same goal from different angles. Vue's approach is notable because it's not a rewrite exposed to userland; it's an internal engine swap that preserves the exact same ref/reactive/computed API surface while making the machinery underneath leaner.

Why This Matters Beyond Benchmarks

Memory usage improvements don't just make for good release notes — they compound. Lower per-reactive-object overhead means larger apps can maintain more state without triggering garbage collection pauses, mobile and low-power devices handle complex UIs more gracefully, and server-side rendering (which spins up and tears down reactive graphs constantly under load) gets both faster and more memory-stable. Combined with the fix for hanging computeds during SSR, this release is clearly aimed at teams running Vue at scale — think large dashboards, e-commerce platforms, and SSR-heavy Nuxt applications — rather than at toy demos.

The real takeaway from Vue 3.5 isn't any single number. It's a reminder that the framework performance race isn't just about who renders a to-do list benchmark fastest anymore. It's about who can make a decade-old public API cheaper to run underneath, invisibly, release after release — and Vue just proved there's still plenty of room to optimize even in a mature reactivity model.