Vue 3 was a mistake and we shouldn't make it again.

If you have dreams and dry goods, you can search for [Great Move to the World] on WeChat and pay attention to this Shawanzhi who is still washing dishes in the early hours of the morning.

This article GitHub https://github.com/qq449245884/xiaozhi has been included, there are complete test sites, materials and my series of articles for interviews with first-line manufacturers.

The text is translated by Fotis Adamakis, co-organizer of the Vue.js Athens conference, and the first person in the text refers to the big guy.

More than 4 years have passed since Vue 3 was originally introduced. After several RFC discussions, and the influence of other modern frameworks including React and Svelte, Vue has probably become the most powerful and comprehensive framework, able to gradually support applications of any size and architecture.

Sounds exciting, right? Well, that's far from the truth. Since then, there have been a lot of delays and degradations. Although Vue 3 has recently become the new default version, many important support libraries are not ready or even planned to be compatible with both versions. This shows that many codebases are still stuck on Vue 2, and the path to migrate to version 3 is not easy.

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 onwards is a mistake that we should not repeat in the future.

Problems with Vue 2

Vue has always been considered a progressive framework. The options API is easy to understand, and we can learn and introduce more complex patterns and libraries when needed. Small learning curve and good documentation are the reasons why everyone loves it.

On the other hand, the architectural flaw of using inheritance instead of composition when abstracting common logic into mixins creates many scalability issues and breaks many principles of clean component declarations. Vue3 introduced Composition API as a solution.

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

vue3 solution

A complete rewrite is an opportunity to improve the internals of the framework. Vue3 makes extensive use of Typescript, and many aspects, including the reactivity mechanism, were started from scratch. This results in a noticeable improvement in Vue 3's performance in terms of packet size, initial rendering, updates, and memory usage.

In addition, many new functions have been added.

• Composition API
• Syntax sugar <script setup>
• Fragments
• Emits Component Option
• createRenderer API from @vue/runtime-core to create custom renderers
• You can bind variables in style
• SFC's <style scoped> can now include global rules or rules for slot content only
• Suspense

The new features improve the overall development experience, and many developers are welcome. The point of contention is that most of these features, including composition API, teleport, suspense, etc., are already available in Vue 2, so they don't really count as improvements to the framework.

real problem

Destructive sexual changes, there are many . Some of them are simple, like the Events API . A 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 drop-in replacements. This requires a certain amount of work time, but it can be done in a timely manner without much risk.

On the other hand, there are some changes that cannot be made safely without a small or large-scale refactoring. In an existing large application built with Vue 2, you may use some deprecated or changed API.

Migration builds are supposed to be a bridge between two versions, but with so many deprecated features, it's not suitable for large projects. Also, the official recommendation for some basic support libraries is to migrate to a different library, which further adds to the complexity. With so many moving components, even a successful migration build requires a lot of work, which for larger projects requires more time to resolve technical debt.

unwanted things

Vue is always a meaningful framework. You can try to guess how an API should work, and you're probably right. This is no longer the case with Vue 3.

One example was a call for comments on the way new function-based Vue components are written, with a ton of responses, both positive and negative. Regardless of where you stand in this debate, splitting the community in half is never a good sign.

Documentation

During development, especially in a new framework, Google and StackOverflow are your best friends. Currently the Vue 2 answer is overwhelming, but in Vue 3 many API implementations work differently, so it can cause some confusion.

ecology

How powerful a framework is, how powerful is its ecosystem. Controversial decisions and irresponsible deprecated features drove many contributors away, resulting in many libraries being abandoned. But when you accuse an open source library of not keeping up with your version when you haven't given an open source library a viable way to support both versions, it shows a lack of empathy and understanding of the big picture.

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

past

If you were lucky enough to write code around 2015, you probably used AngularJS, the most popular framework at the time.

The move to Vue 3 looks a lot like the transition from AngularJS to Angular (version 1 ⇒ 2). Lots of breaking changes led to frustration and eventually Angular lost its appeal to React and Vue.

If you're a full stack engineer, you're probably familiar with the same thing that happened in the Python ecosystem about 10 years ago. For about a decade, many projects were unable to upgrade because many core libraries did not add support for Python 3, and new libraries emerged that only supported Python 3. Of course, later Python versions started adding new and shiny features only on version 3, and this mess isn't really over yet.

In the future - will this happen again?

It looks like the way forward is going backwards and porting everything into a migration build, but the damage has been done and development satisfaction doesn't look promising to ignore. It's reasonable to have the foresight to involve the framework, but development experience is one of the core responsibilities of the framework. Vue 4 should take the whole ecosystem into account and provide a migration path, otherwise it will be the best framework no one wants to use.

What has been your experience with Vue 3 migrations so far? Please share your thoughts and suggestions in the comments.

The bugs that may exist in editing cannot be known in real time. In order to solve these bugs afterwards, a lot of time is spent on log debugging. By the way, here is a useful BUG monitoring tool , Fundebug .

Author: Chris Translator: Xiaozhi Source: medium

Original: https://fadamais.medium.com/vue-3-was-a-mitake-that-we-should-not-repeat-81cc65484954

comminicate

If you have dreams and dry goods, you can search for [Great Move to the World] on WeChat and pay attention to this Shawanzhi who is still washing dishes in the early hours of the morning.

This article GitHub https://github.com/qq449245884/xiaozhi has been included, there are complete test sites, materials and my series of articles for interviews with first-line manufacturers.