Last Friday, Evan You officially released Vue.js 3.0, codenamed “One Piece.” After more than two years of development and extensive community RFC processes, the third major version of Vue is here — and it’s not an incremental update. It’s a ground-up rewrite in TypeScript with fundamental changes to the reactivity system, component model, and rendering pipeline.
I’ve been keeping an eye on Vue since its early days, and while I primarily work on backend systems, the frontend framework landscape directly impacts every full-stack project I touch. Vue 3 represents some genuinely interesting architectural decisions that are worth examining, regardless of your framework allegiance.
The Composition API#
The headline feature is the Composition API, and it addresses a real problem that anyone who’s built complex Vue 2 applications has encountered: component organization doesn’t scale well with the Options API.
In Vue 2, you organize code by option type — all data in one block, all methods in another, all computed properties in yet another. For small components, this is clean and readable. For large components with multiple logical concerns, it means that related code gets scattered across the file. Your search feature’s data is in data(), its methods in methods, its computed properties in computed, and its watchers in watch. Understanding the search feature means jumping back and forth across the component.
The Composition API lets you organize by logical concern instead:
import { ref, computed, onMounted } from 'vue'
export default {
setup() {
// Search feature — all together
const searchQuery = ref('')
const results = ref([])
const hasResults = computed(() => results.value.length > 0)
async function search() {
results.value = await fetchResults(searchQuery.value)
}
// Pagination — all together
const page = ref(1)
const pageSize = ref(20)
function nextPage() { page.value++ }
onMounted(() => search())
return { searchQuery, results, hasResults, search, page, nextPage }
}
}More importantly, these logical blocks can be extracted into composable functions — Vue’s answer to React’s hooks. A useSearch() function can encapsulate the search logic and be reused across components with full reactivity intact.
The Options API isn’t going away, which is a smart decision. Existing codebases and developers who prefer the structured approach can continue as before. The Composition API is additive, not a replacement.
Performance Gains#
The performance improvements are substantial and come from multiple angles. The virtual DOM has been rewritten with a compiler-informed strategy. Vue 3’s template compiler analyzes templates at build time and generates optimized rendering code that skips static content during diffing.
Consider a template with mostly static content and a few dynamic bindings. Vue 2 would diff the entire virtual DOM tree on every update. Vue 3’s compiler marks static subtrees and hoists them out of the render function entirely. Only the dynamic parts participate in the diff process.
The numbers the team is reporting are impressive: up to 2x faster mounting, 2-3x faster updates, and up to 50% less memory usage compared to Vue 2. In tree-shaking scenarios, a minimal Vue 3 application weighs in at around 10KB gzipped versus Vue 2’s approximately 23KB baseline.
TypeScript from the Ground Up#
Vue 3 is written entirely in TypeScript, and the difference in developer experience is immediately noticeable. Vue 2’s TypeScript support always felt bolted on — class-based components through vue-class-component, decorated properties, and type definitions that didn’t always match the runtime behavior.
With Vue 3, TypeScript support is native. The Composition API’s function-based approach maps naturally to TypeScript’s type inference:
const count = ref(0) // Ref<number> — inferred
const doubled = computed(() => count.value * 2) // ComputedRef<number> — inferred
Props get proper type checking, emits can be typed, and the entire API surface has accurate type definitions because the types come from the same codebase as the runtime.
For teams that have been gradually adopting TypeScript (and at this point, who isn’t?), this removes one of the biggest friction points of using Vue in a typed codebase.
The Migration Question#
Here’s where it gets real: migration. Vue 3 introduces breaking changes. The filter syntax is removed. Event bus patterns using $on, $off, and $once are gone. The global API surface has changed. Some widely-used community libraries aren’t compatible yet.
The Vue team is taking a pragmatic approach with a migration build that provides Vue 2 compatible behavior while emitting deprecation warnings. It’s not a drop-in replacement, but it’s a migration path — which is more than some framework major versions have offered.
My advice for teams considering migration: wait a few months. Let the ecosystem catch up. Libraries like Vue Router, Vuex, and popular UI frameworks need time to ship Vue 3 compatible versions. Starting a new project? Vue 3 is ready. Migrating a large existing application? Patience will serve you better than haste.
My Take#
What impresses me most about Vue 3 isn’t any single feature — it’s the discipline of the process. The RFC system meant that major API changes were debated publicly before implementation. The two-year timeline, while longer than initially planned, reflects a team that chose to get it right over getting it shipped.
The Composition API is a genuine advancement in component design patterns, not just for Vue but as an idea. The performance work shows that framework-level optimization still has meaningful headroom. And the TypeScript rewrite positions Vue well for the next several years of frontend development.
Evan You and the Vue team deserve credit for pulling off a major framework rewrite without fragmenting the community. That’s harder than the technical work, and they seem to be managing it well. Vue 3.0 is a solid foundation — now let’s see the ecosystem build on it.
