I’ve stopped using Vue. In fact, I just deleted twenty eight repositories and archived the remaining twelve (there’s a bunch of private repos I didn’t count in this).

In fact, I have not used Vue since early 2022 and don’t intend to use it again. I became deeply frustrated with the tooling, direction, community, and leadership. I am completely done with fighting against the current of passive ineptitude.

Any time I see the latest Vue thing, whether that’s a tweet demonstrating a ridiculous new “feature” that is actually a workaround for Vue’s historically poor TypeScript support, an old GitHub issue I was involved in finally getting a comment months or years later, or yet another pattern that copies developments in other frameworks without considering the ergonomics of doing so - it’s all the same: problems that shouldn’t have existed in the first place.

I used Vue from 2016 to the end of 2021. I was an active member of it’s online developer community, mainly focussed around their Discord server, before that succumbed to incompetent moderation.

I also noticed a strong bias among developers using Vue across the board:

• Often brand new to development or a junior developer. There is a distinct lack of experienced or knowledgable developers in the Vue community. This is a vicious cycle as more and more content and information is created by these same developers and then taken at face value by newer developers.
• I consider myself one of the more experienced developers in the Vue community and indeed I had their Discord “MVP” role for a few years. Outside of that circle, there is not much.
• It’s very hard to find highly technical or informative discussions about Vue. On the other hand, I could spend five minutes and probably find a dozen articles, videos, and tweets about a particular React feature.
• A strong unwillingness to learn new patterns or explore new ideas. Still to this day I see people attaching useless shit to the Vue global prototype and then littering this kind of code throughout all their components.

The Vue tooling situation is fragmented and full of needlessly deprecated tools:

• Vue CLI was deprecated in favour of Vite but with none of the configuration people interested in high quality code had come to rely on (unit testing, linting, formatting)
• I tried to address this specific concern in a GitHub issue but as usual with the Vue core team: silence.
• A new major version of Vuex was due and instead of making it a new major version they opted to release a totally new library called Pinia further fragmenting the user base
• The VS Code extension is now on it’s second iteration - and it seems like the second iteration now needs two different extensions installing

Of course, when asked why they do this they say something like “that’s how I’ve always done it”. When pressed further, they won’t understand that this makes reasoning about the code harder because of the implicit shared global state (one of the points of a framework is to make shared state easier to maintain and mutate not harder!).

Without fail, the developers writing this sort of code do not write unit tests and might even be completely unfamiliar with the term. Bonus points if they also do not use async/await.

    loadCustomers () {
        Vue.$api.getCustomers().then((response) => this.customers = response);
    }

This is but one problem of an entire catalogue of poor practices and mistakes I see consistently in Vue projects. I find it frustrating that these same problems like this particular one are still so prevalent meanwhile the more competent side of frontend developments has made huge progress in this space. You only have to spend five minutes looking into TanStack Query to see how asynchronous API calls are made in modern React projects.

Moving onto the topic of DX and developer tooling, so many of Vue’s developer tooling problems stem from the decision to invent a file format for Vue components instead of using widely accepted standards like JSX and TSX. Of course, both of these can be used but does anyone? Hardly. You won’t find them mentioned in the docs without specifically searching for it.

Earlier when I referred to new “features” that are workarounds due to poor TypeScript support, the following screenshot of the docs is an example of exactly what I meant.

Seriously, it does not supported imported types? That is a completely normal thing to do with any framework that supports JSX/TSX such as React. Or, to phrase it more generally importing things is a normal thing to do in any language but Vue’s tooling once again breaks default semantics. This is something I could imagine being the case for an experimental beta feature. This warning has been there for at least a year and a half.

Although I could write an entire article diving deeply into more of these problems, I’ll finish off with one final point. The quality of most Vue codebase’s is firmly on the lower end. It’s so bad in fact that I suggest to you try and see for yourself. Find a library that solves a common problem, and then look for the React and Vue version of it. Assuming a Vue version exists, compare the code quality of the React and Vue versions.

• You’ll be lucky to find maintainable code in the Vue version
• You probably won’t see any unit tests and the code will be written in such a poor manner that retrospectively adding tests would be difficult
• If you tried to raise any of these concerns or create a PR to fix these issues it would probably be ignored indefinitely

I often opted to write my own version of a Vue library to ensure the code is not a complete shitshow and has tests. The downside of this is it’s more code to maintain, but at least I know it can be maintained, unlike whatever amateur hour code was in the original library.

I’ve been using React for a while now and I am much happier:

• React and TypeScript work so well together, I’ve never had a problem or had to make an issue on GitHub to fix something like the time I did for TSX support in Vue.
• The community is more vibrant, engaged, and welcoming. Welcoming is certainly not a word I would use to describe the Vue community.
• Hooks feel like a much more natural approach to declarative state compared to Vue’s copy and paste version of Hooks.