Shortcomings of Vue.js compared to React
I have a natural affection for the frontend framework Vue.js. It was my first frontend framework, and I hadn't even used Javascript before it. Vue.js has comprehensive Chinese documentation, which allowed a novice like me to quickly get started with frontend development. Today, I still appreciate its intuitiveness, ease of use, and elegant design.
However, Vue is not the first choice globally; there is a monster in the world called React, which is the de facto number one frontend library, with a bright future and an unshakeable position. What's scary is that Vue and React both exist to solve the same problem (how to write UI better), and they are interchangeable tools.
Although I'm not an advanced frontend engineer, my understanding of the internals of these two libraries is superficial, based only on the documentation, without delving into the underlying mechanisms. But I have a bit of experience with both frameworks/libraries and consider myself a proficient user. I would like to share some of my experiences and insights from using these libraries. I hope it will help some beginners who are still making choices.
Vue's strengths, and React's shortcomings
We can clearly see the efforts of Vue's developers to improve the development experience (DX). Vue has two-way binding, automatic import of various tool combination functions, and syntactic sugar. The Vue team does more. Vue's built-in Transition is a thousand times better to use than the wild third-party Transition libraries in the React ecosystem. The official team also integrates commonly used development tools as modules into Vue to keep the project clean and allow us to focus on business logic. Core team members under Vue and Nuxt also maintain cool devtools, which provide a much better development experience than traditional browser plugins.
I want to say that all these Vue magics exist to improve the efficiency of writing business code, and the price is just a little bit of checking the documentation, which I think is worth it. In contrast, React is more pure in functionality, but it's not easy to do well. If you want to master the best programming paradigm of React, you have to wade through each pit. Many times, the behavior of Hook is not so intuitive, bringing more "mental burden". We not only need to check the documentation but also need to look for various experience lessons summarized by other developers. Just one useEffect has countless people writing many lengthy articles teaching you how to use it.
Complex frontend interaction logic with animation effects is difficult to implement with React hook. Developers often fail to successfully obtain the latest view state and have difficulty accurately grasping the timing of view updates. There are also various restrictions on the use of Hook. All this boils down to React's design philosophy that components can be executed multiple times. When developing React projects, I sometimes feel that it's much simpler to use the pure DOM API to achieve some desired effects than wandering in various use mazes, even though this sometimes leads to inconsistencies between the virtual DOM and the real DOM. Vue is sometimes easier to understand than React in this respect.
Also, some people feel that Vue's support for Typescript is not good, so they steer clear of it. But I think that, without developing a library, in the context of business development, Vue really doesn't need Typescript that much. Vue programs without Typescript strike a good balance between usability and rigor. Moreover, the support for Typescript in Vue today is not that bad.
React's strengths, and Vue's shortcomings
Compared to Vue, React is a leading framework. Being a leader here is twofold: on the one hand, React's ecosystem is better.
Actually, the ecosystem and the number of users are mutually reinforcing things. The more users there are, the more things there are. Naturally, the more bugs that are discovered and solved, the more stable the functions are. To judge a library in this way is not fair to Vue. It's not just about how good the Vue framework is that influences everything (of course, this is also a very important part). It's also related to timing or promotion. Just having Facebook's endorsement could attract more people to develop with React.
Because there are so many developers, React's ecosystem is blooming. There are three CSS in JS solutions, several state management libraries, and a variety of routing strategies. Some people feel that this is going to kill those with decision paralysis, unlike Vue, where the official team has already maintained the whole stack, and the ecosystem is very unified. Yes, this is indeed one of Vue's advantages. I find that one of Vue's advantages is that the peripheral projects maintained by the core team members are done very well, while those done by the React team members are left unattended. However, React's advantage is that in addition to the core team, there are more excellent teams doing more interesting things, and they are doing them well.
For example, the React world now has Redux, and then Vuex appeared in the Vue world. The React world had React Query, a kind of SWR library, much earlier than Vue, and with fewer features under Vue. Next and Nuxt were launched around the same time, but Next is much more mature than Nuxt.
The component library solution under Vue is much better than other frameworks, but it still falls short compared to React. In the era of Vue 2, I tried Element UI and then migrated to Vuetify, but I do not recommend new projects to use them under any circumstances, even if their Star count is much higher than all my projects combined, but if they are hard to use, they are hard to use, if they update slowly, they update slowly, and the user experience is clearly being beaten by React frameworks like Material UI, Mantine. Perhaps Naive UI is doing better? But this is almost a personal project. In the React world, there are headless solutions like Remix and more quirky ones like shadcn, while in the Vue world, there are more inspired by Remix, shadcn, and so on.
In addition to the above commonly used libraries, React also has solutions like Remotion for video production, and top-level FLIP animation solutions like Framer motion (although I first saw the word FLIP in the vue documentation). To sum it up in one sentence, Vue can only be said to be "adequate" in terms of ecosystem, while React truly deserves to be called "rich".
Those who follow Vue will say that if you want this feature, you can write one yourself, everyone can contribute to open source projects. But why should we develop a set of similar things for the Vue environment when there is already React available in the world? The motivation to contribute to the Vue ecosystem is probably not enough. Especially some libraries are very difficult to implement, such as React Native currently has no substitute in the Vue ecosystem (Weex has already cooled down, and has never been popular), it is almost impossible for individuals to lead the development of such complex libraries, it can be foreseen that in the future, Vue may not have wild teams to maintain such things. I don't want to say such negative words, but in terms of ecosystem, it is hard for Vue to catch up with React. Even if Vue has a new concept, it is copied to the React ecosystem faster, and maybe even better. But the other way around is hard for me to expect.
Another "leading" aspect is that React itself seems to be more advanced in thinking. For example, React Hook is a core feature of the React framework, which allows function components to have the same state and lifecycle as class components. Then came Vue's compositional API, which achieved similar separation of concerns while remaining friendly to existing Vue developers.
With the recent launch of Next.js 13, server components are now in use. Some people think that server components seem to be a return to the PHP era, but those who have understood or used them should feel that server components are advanced and the future is bright. Just like SWR technology can kill Redux/Vuex to some extent, the promotion of server components could perhaps change the frontend, bury SPA applications, and bury SWR. Even as a Vuer, I think we should start researching or preparing for server components now, just as we once embraced Typescript and then embraced compositional API similar to Hook. Don't be held hostage by public opinion, don't imitate - others' good things, I want my users to use, I think this is justified.
Another drawback of Vue in my mind is single file components. It's a bit inconvenient to have only one component in a file. Especially when there are some small, related components, defining them in their own .vue files may seem a bit redundant. This often leads to a rapid increase in the number of files in a project, especially in large projects, this can make the file structure more complex and make it difficult to find and manage specific components.
In addition, while Vue's single file components are very convenient in application development, they are not so in library or framework development. If you look at the implementation of some component libraries, you will find that they often use JSX/TSX, or render functions, which is actually quite awkward, it suggests that the expressiveness of templates may be really weak, and complex functions are not easy to implement. Vue and JSX have different supported features, and the programming experience is very inconsistent. I have some resistance to using JSX in Vue, because it seems not to be the officially recommended solution, and there is only a short chapter in the documentation, there are not many people using Vue, and even fewer people using Vue's JSX, perhaps, there will be many pits.
To be honest, React officially recommends Next as the development solution, and Nuxt will become the preferred production environment development solution for Vue. Therefore, Nuxt is worth paying attention to. Nuxt is now in a state of revival. You will encounter bugs in all kinds of places. I tried Nuxt to build a blog a few days ago and encountered a bunch of problems: replacing the default Image style will have a bug, setting page transition animation, clicking other links during animation execution will have a bug, using the content plugin, the path folder of the article can't even include capital letters, causing the inability to use paths like zh-CN, the bug of returning from Content, the homepage, the title didn't change back, ViewTransiton will have a few seconds of freezing bug when jumping on the same page...... you can find that many of these features are not in Next.js - Nuxt does more, so it's more prone to errors. But the good thing is that you can raise issues that you see can be solved, and you'll get a quick response. In just two weekends, I've merged 4 PRs in the Nuxt project and become a "nuxter".
Conclusion
Although it sounds a bit like sarcasm, I really think so: when choosing between the world's most popular framework and the second most popular (one of them), it may be better to choose the second most popular. The first reason is that in this field, React is the undisputed Top 1, in fact, many people choose it just because Top 1 is more famous. Rejecting Top 1 and choosing Top2 is ultimately a matter of love, showing that it really has its unique aspects waiting for you to discover. The second reason is that when you are willing to contribute to open source projects, you will find that adding bricks and tiles to the Vue ecosystem is much more noticeable than giving feedback to React. On the one hand, there are many things in the ecosystem that are worth doing. Because many small features implemented with React can be implemented with Vue, and may be implemented even faster.
In summary, I believe that Vue still has many shortcomings compared to React. Therefore, I would advise prioritizing React in a production environment, considering its flexibility, mature ecosystem, and efficient development mode. But in your personal learning journey, if you have enough passion and energy, you can definitely try Vue, it has enough influence, you can make it better.