Vue 3 was a mistake that we should not repeat

More than 4 years have passed since the initial introduction of Vue 3. Many discussions over several RFCs and a lot of influence from other modern frameworks including React and Svelte have shaped Vue to become probably the most powerful and well-round

More than 4 years have passed since the initial introduction of Vue 3. Many discussions over several RFCs and a lot of influence from other modern frameworks including React and Svelte have shaped Vue to become probably the most powerful and well-rounded framework out there, capable of progressively supporting applications of any scale and architecture.

Sounds exciting, right? Well, the truth is far from that. A lot of delays and descoping have happened since then. And even though Vue 3 has recently become the new default, a lot of essential supporting libraries are not ready or even plan to be compatible with both versions. This means that many codebases are stuck with Vue 2 and the migration path to version 3 is not easy or straightforward.

Please don’t get me wrong Vue 3 is awesome. It’s probably the best framework out there. But the fact that there is no easy migration path from version 2 is a mistake we should not repeat in the future.

Vue 2 problems
Vue was always considered a progressive framework. The options API was easy to understand and you could learn and introduce more complicated patterns and libraries when needed. The small learning curve and the good documentation were often attributed as the reasons to prefer it.

On the other hand, an architectural flaw of using inheritance over composition when abstracting the common logic to a mixin created a lot of scalability issues and was breaking a lot of principles of a clean component declaration. Composition API was introduced as the solution.

Another important issue was the typescript support. Of course, writing typescript in a Vue component is as easy as adding the type="ts" in the script tag. But inside templates and the store the support was problematic.

Vue 3 solutions
A complete rewrite was an opportunity to improve the internals of the framework. Typescript was used extensively and many aspects including the reactivity mechanism were implemented from scratch. This led to significant performance improvements over the already performant Vue 2 in terms of bundle size, initial render, updates, and memory usage.

Additionally, a lot of new features were added:

Composition API
SFC Composition API Syntax Sugar (<script setup>)
Teleport
Fragments
Emits Component Option
createRenderer API from @vue/runtime-core to create custom renderers
SFC State-driven CSS Variables (v-bind in <style>)
SFC <style scoped> can now include global rules or rules that target only slotted content
Suspense
New features improve the overall developer experience and are always welcomed. The argument is that most of them including composition API, teleport, suspense etc. already work with Vue 2 so they can't really be counted as framework improvements.

The real problem
Breaking changes. And there are a lot of them. Some of which are straightforward like the depreciation of the Events API. This one means that the Vue instance can no longer be used as an event bus, but there are plug-and-play solutions like mitt or tiny-emitter that can be used as direct replacements. This still requires work but can be done in a timely manner without much risk.

On the other hand, there are changes that can not be made safely and without small or heavy refactoring. In an existing large-scale application built with Vue 2, you would probably use some of the deprecated or changed APIs. Migration build was supposed to be a bridge between the two versions but with so many deprecated functionalities it doesn't work for large projects. Additionally, the official recommendation for some essential supporting libraries is to migrate to a different one which further increases complexity. With so many moving parts, even if migration build worked it would require a code freeze and a huge amount of work which for big projects translates to many working hours that could be used to tackle technical debt instead.

Vue migration complexity
Each entry links to migration documentation
miro.com

What was not necessary
Vue was always the framework that made sense. You could try guessing how an API should work and you would probably be right. This was no longer the case with Vue 3. An example is the Request for Comment for the new function-based way of writing Vue components which had an overwhelming amount of responses, both positive and negative. No matter where you stand in this argument splitting the community in half is never a good sign and led to Vue’s Darkest Day and a lot of people getting discouraged over this.

Documentation
During development, especially with a new framework, Google and StackOverflow are your best friends. Currently, Vue 2 answers are dominating the results which might cause confusion and frustration since many things don’t work the same in Vue 3.

The ecosystem
A framework is as strong as its ecosystem. Controversial decisions and no accountability while deprecating features drove many contributors away and resulted in many libraries being abandoned. But blaming open source libraries for delays when you don't give them a feasible way to support both versions shows a lack of empathy and lack of understanding of the bigger picture.

The true power of a framework comes from the community and the ecosystem around it.

The past
If you were lucky enough to write code around 2015 chances are that you would be using the most dominant framework at the time, AngularJS.

The transition to Vue 3 looks a lot like the transition from AngularJS to Angular (Version 1⇒ 2)*. A lot of delays and breaking changes led to frustration and eventually Angular lost traction to React and Vue.

*update: The comparison with AngularJS triggered a lot of comments. From my personal experience migration in both cases was equally hard, time-consuming and unclear. In any case, the point of this article is to avoid making this mistake again so, please don't get distracted from that.

And if you are a full-stack engineer you are probably familiar with the same situation happening around 10 years ago in the Python ecosystem. For around a decade many projects couldn't upgrade because many core libraries didn't add Python 3 support and new libraries emerged that only supported Python 3. Of course, later Python releases started adding new and shiny features only on version 3 and this messy situation is not yet really over.

The Future - Will this happen again?
It looks like the way forward is going backwards, and porting everything to the migration build, but the damage is already done and development satisfaction is not looking good and can’t be ignored. Having the vision to involve the framework over time is reasonable but Development Experience is one of the framework's core responsibilities. Vue 4 should take into account the whole ecosystem and provide a migration path or it will be the best framework that no one will want to use.