Vue 3.0: What Core Team Members Want You To Know
Vue 3.0 is finally here, and it brings a lot of changes. Natalia Tepluhina, a core team member, sat down with Drew McLellan to walk through what’s new, how the migration path looks, and what developers should focus on first.
Migration Might Be Easier Than You Think
One of the biggest concerns with any major version bump is the amount of work required to upgrade existing projects. For Vue 3.0, the team has published an official Migration Guide to help developers plan their move. According to Tepluhina, most of the breaking changes are isolated, and the experience for the majority of existing Vue 2 codebases is not as disruptive as some might fear.
The core team also prepared an automated migration tool to help find deprecated patterns and API changes. That tooling, combined with the guide, is designed to turn what could be a tedious manual review into a much more straightforward process.
No More Global Event Bus
One significant change that could trip up developers is the removal of the global event bus from the core library. In Vue 2, using $on, $off, and $once to emit and listen for events across components was a common pattern. In Vue 3.0, these instance methods are gone entirely.
Tepluhina explained that this was a deliberate architectural decision — the functionality is no longer part of the core library. Teams that rely on the event bus will need to look for third-party libraries to handle cross-component communication, or redesign their state management approach. It is a breaking change that goes beyond merely updating syntax, so it deserves early attention during migration planning.
A Focus On Faster Loads
Size and performance were also on the agenda. Vue 3.0 has a smaller runtime footprint than its predecessor, which directly improves load times for users. The project also introduced a new tree-shaking strategy that eliminates unused code more effectively when bundlers like webpack or Rollup are involved. This means that developers who import only selected parts of the API can ship an even leaner bundle.
Beyond bundle size, there is a new compiler that makes design decisions aimed at better runtime performance. These are not superficial tweaks — they reflect a focus on making Vue 3.0 noticeably faster on initial load and during updates. For large production applications, both bundle size and render efficiency matter.
Breaking Down The Big Changes
While Tepluhina described the move to Vue 3.0 as generally smooth, several items require attention:
- Filters are removed. They existed in Vue 2 for text formatting inside templates but are no longer supported in 3.0.
- There is a shift in how migration is approached — the team cautions against trying to move an entire project at once. Instead, the recommended path is incremental
v-modelusage changes. - Following the removal of the global event bus, the docs and the migration guide now push a more deterministic pattern of handling events, such as using props and recognized parent-child communication.
How Different Code Styles Are Handled
For developers coming from Vue 2, Options API keeps working pretty much as-is. The new wiring feels familiar to those who have used the library for years. On the other hand, Composition API is introduced as an additional way to organize logic, especially for large components where related code is spread out across a single methods block.
Tepluhina highlighted that both approaches are supported in Vue 3.0, and that the official recommendation is not to rewrite all components to the new style overnight. Instead, developers can adopt the Composition API where it solves a real maintainability problem, such as reuse of logic across multiple components.
Wrap Up
The takeaway from this conversation is that Vue 3.0 was designed with a clear direction — slimmer bundles, faster runtime, and a more deliberate API surface. The migration path is paved with official guides and tooling, but not every part of the move is automated. The removal of the event bus, the deprecation of filters, and a rethink of template directives are real tasks that need to be scheduled into a project plan. Those who approach the upgrade methodically rather than hastily will find a solid framework that gives them more granular control — and a sensible path forward.
Listen to the full episode on Smashing Magazine for more details from Natalia Tepluhina on the inner workings of Vue 3.0.
Why Vue 3 Took Two Years And What Changed
Vue 3.0 emerged from ideas first floated in spring 2018, with active development beginning that autumn and an official announcement at the London Conference in October 2018. The two years of work that followed came after a period when the previous major release, Vue 2, had shipped in 2016 — meaning half of Vue 2's lifespan was spent preparing its successor.
Several motivations drove the decision to build a new major version. The reactivity system in Vue 2 rested on Object.defineProperty, which carried documented caveats that developers hit anyway. Performance improvements were another target. TypeScript support was a significant pain point: Vue 2 was internally written in Flow, and working with TypeScript — especially with Vuex — was difficult. Finally, the team wanted a way to abstract logic beyond components, into composable pieces that could include reactive behavior, similar to what React Hooks offered.
Natalia Tepluhina, Vue Core Team member and Staff Frontend Engineer at GitLab, described this borrowing of ideas as healthy cross-pollination rather than copying. She compared it to GitLab's iteration value: ideas start rough and improve through multiple passes, with projects taking inspiration from each other in turn.
TypeScript Without The Ceremony
Vue 3 is written in TypeScript, and Tepluhina's experience documenting how to use it revealed how much simpler the new version is. Writing the TypeScript documentation, she initially typed everything explicitly, drawing on habits from years of Angular work. A colleague pointed out she didn't need to: providing an initial value lets TypeScript infer types automatically. In practice, developers only need to explicitly type the component proxy and return types for computed properties. Everything else is inferred when using the defineComponent method.
Not A One-Person Project
The perception that Vue is "a framework of one Chinese person" has persisted for years, but Tepluhina stressed that even during Vue 1.x there was a team, and the group behind Vue 3 is larger still. Evan You leads development and does much of the core work, but others contribute to the core, and separate teams handle Vue Router, Vue CLI, Vuex, and documentation. The core team currently lists around 20 or 21 people, though that list is dynamic. Contributors who consistently do the work of team members are granted repository access and formal recognition rather than being hired, since open source work is unpaid.
The Composition API Is Purely Additive
The Composition API was one of the most contentious changes — partly due to poor communication. When first announced through an RFC, it seemed the standard build would use only the Composition API, and that the Options API might be deprecated. Tepluhina admitted this was "our bad completely." The community reaction was swift: Reddit threads accused Vue of becoming "new Angular," and an article on dev.to declared it "Vue's Darkest Day." Evan You edited the RFC without announcing changes, which only compounded the confusion as people argued about points that disappeared on refresh.
The reality is that the Composition API is purely additive. The Options API remains fully supported and is the default in documentation. Developers can use the Composition API, stick with the Options API, or mix both in the same component.
The problem the Composition API solves is component fragmentation. In Vue 2, a component handling multiple features — say search and sorting — splits code by options rather than logic. Reactive properties go in data, methods in methods, and calculations in computed. A developer working on one feature must jump between these sections, and features often overlap. Large components become difficult to navigate.
Why Mixins And Renderless Components Fall Short
Vue 2 offered two main ways to extract logic, each with serious drawbacks. Mixins are static objects merged into components. They accept no parameters, so a mixin for searching a specific endpoint can only search that endpoint. Property collisions silently resolve in favor of the component with no warning. Tepluhina described debugging a GitLab component that contained two mixins, each containing further mixins, requiring a deep dive through multiple layers to trace where a property came from. Mixins are, in her words, "dumb ways of extracting logic."
Renderless components with scoped slots improve on mixins — they accept parameters and expose logic explicitly — but they come with their own costs. Creating a component instance is not cheap, and the logic only exists at runtime within the slot's scope. Exposed properties are unavailable outside that slot, and there's no way to share reactive state elsewhere in the component.
Standalone Reactive State
The Composition API changes this by decoupling reactive state from components. Any object or primitive can be made reactive outside a component and then explicitly exposed where needed. Because composed functions are pure — apart from lifecycle hooks — they're straightforward to test: pass parameters, check the return value.
Tepluhina also noted that adding Composition API code to a component using the Options API "just works," allowing incremental adoption.
The Migration Story: Patience Advised
For those worried about migrating large projects, Tepluhina offered reassurance about API stability while advising against rushing. The API surface is 90% the same; the notable breaking changes are removed filters and the deprecated Vue-based event hub, which requires an external EventEmitter library.
Her dual perspective — Core Team member and engineer on GitLab's large Vue codebase — made her cautious. She would not recommend migrating a big project immediately. Core libraries like Vue Router, Vuex, and Vue CLI are release candidates rather than final releases, and many third-party libraries such as UI component and form validation libraries aren't yet Vue 3-ready.
The recommended path involves several steps. An LTS build of Vue 2.7 will include deprecation warnings, letting teams refactor proactively while still on Vue 2. A migration tool, available as a Vue CLI plugin, acts as a codemod: it replaces what it can and warns on the rest. Expected around December, it's already usable for small or personal projects — Tepluhina reported only one or two issues on mid-sized codebases — but she cautioned against running it on production-scale projects with legacy code.
For GitLab, preparation began even without the migration tool. The team created an epic to hunt down deprecated syntax, like old slot syntax from Vue 2.6, which warns in development but still runs. They also replaced Vue-based event hubs with external libraries.
Not every deprecation affects every project. Filters were rarely used even at GitLab with its seven-year-old codebase. The truly universal changes are the v-model behavior and attribute handling — including class and style — which touch nearly every project and deserve close attention.
vuejs.org still points to Vue 2 intentionally until a subdomain is set up; a small banner (which Tepluhina admits needs better contrast) links to Vue 3 docs. For new projects, learning Vue 3 is reasonable — the docs present familiar Options API syntax first, with the Composition API reserved for advanced topics, so the learning curve is similar to Vue 2.
Documentation-Driven Design
Vue's intuitive API isn't accidental. During Vue 2's development, the team followed a concept called Documentation Driven Design: if an API is hard to explain, it's probably wrong. Directives like v-if, v-else-if, and v-else read like natural JavaScript, and v-for mirrors a for loop. The goal, carried from Vue 1.x, was developer experience — building with a tool that doesn't get in the way of what you're building.
Tepluhina contrasted this with Angular, which she used from version 2 through 6: "It's a great framework... but I constantly had the feel I am building a wall with huge heavy bricks." Vue feels like a walk in the park after that.
The Seriousness Question
Well-designed tools risk being dismissed as toys, and Vue's history includes questions about whether it suits enterprise projects. Her response: any framework can produce good or terrible architecture — "None of the frameworks... is dictating an architecture." Anther stigma was the lack of a big corporate backer. Angular has Google, React has Facebook, but Vue had "the small Chinese guy" — with dev.to even asking what happens if Evan You is hit by a bus.
Tepluhina argues the independence is actually a strength. The RFC process, introduced last year, lets the community shape proposals before anything is final. Vue serves its developer community rather than any single company's roadmap. The team list confirms it: members work at GitLab, as independent consultants, and everywhere in between — no single corporation controls the project's direction.
What's Next
Tepluhina is currently learning Apollo Client version 3, noting its release timeline ran parallel to Vue 3's: both sat at 2.6, both saw extended delays through beta and release candidate phases, and both released within months of each other. Apollo 3's removal of local resolvers is a notable adjustment. Building something with Vue 3 and Apollo 3 together is "not an easy task," but worth exploring.
Listen to the full interview in the Smashing Podcast episode.
