I understood it as “migrating to Vue 3 is no more painful than staying on Vue 2”.

Isn't the reasoning to migrate literally the first sentence in the blog post?

> After using Vue 2 as our front-end framework for almost two years, it was announced that this support would no longer be maintained,

Eg. some teams don't want their development to happen on a framework with no support from the devs that wrote it.

As someone working in a large Vue 2 app:

- Very poor typescript support.

- Poor performance (compared to Vue 3).

- Ecosystem has already started lagging behind (e.g. Vue Testing Library for v2 has out of date dependencies, and no one is actively maintaining it)

- Nuxt 2 hasn't made any releases in ages.

> - Very poor typescript support.

If you use class components and prop decorators, the TS support is actually pretty nice. Kinda boilerplate heavy, but nice.

I really enjoyed using these tools, it felt idiomatic to have a class per component with props and data as fields on the class - but it seems like there's now no upgrade path for us folks in Vue 3 land.

I used those too, but it makes the upgrade to Vue 3 quite a bit harder.

I've worked professionally in both Vue 2 and React. Even with class components and prop decorators you still have the annoying Vue template DSL where you don't get any TS support.

In comparison JSX will be checked by typescript, so in that regard JSX (and therefore React) is superior.

Composition API has the best Typescript support available in Vue 2. It's supported out of the box in 2.7, and a plugin in previous versions. The decorator syntax is unsupported in Vue 3 and shouldn't be used.

- Nuxt only matter if you want to use it, is not Vues problem, because you talking about another software which addresses a different problem. - Typescript support is only a problem if you want to use Typescript, imagine, there is also a world beyond TS. - Performance, often a matter of design and understanding your framework

> - Nuxt 2 hasn't made any releases in ages.

FWIW, Nuxt 3 was released in November. https://nuxt.com/v3

Note: used Vue 2 and 3 with JavaScript instead of TypeScript, so cannot comment on the latter.

Personally, I rather enjoy the <script setup> syntax in Vue 3 which makes using the Composition API more pleasant and makes it feel more like React, instead of something more boilerplate heavy: https://vuejs.org/api/sfc-script-setup.html

Of course, Composition API itself is also available in Vue 2 (at least the newer versions) as a plugin, but personally I didn't see anyone using it in the older version. Either way, it can make code easier to write!

Furthermore, starting out new projects, regardless of which version you use, Pinia is a great option, which you won't see in many of the older Vue 2 projects (but could use if you started a new one with Vue 2, although that's not a good option because of EOL): https://pinia.vuejs.org/

Aside from that, Vue 3 still lacks some component library support in some cases, last I checked so perhaps that's an argument in Vue 2's favor (until everything is updated): https://news.ycombinator.com/item?id=32916677

React feels good in some cases, for example thanks to new solutions like https://react-query-v3.tanstack.com/ but at the same time seems to be getting more overcomplicated as time goes on (Vue feels like it does hooks in a more clean way, you don't need to deal with the complexity of Redux either).

The last React + TypeScript codebase that I looked at felt like it's just going to slow down anyone who works with it, which seemed to be true, judging on how fast people iterated with it vs a Vue project. Note: that's an anecdote.

Then again, the only good front end technology with TypeScript that I've used was Angular, even though it crumbled under its weight otherwise sometimes (once again, in regards to iteration speed in particular).

> React + TypeScript [...] anecdote

I agree that that combination it is very ceremonial.

We now doing new projects in Elm as the JS/TS ecosystem simply does not cut it for me.

Wise choice, but it brings along with it the curse of Plato’s Cave.

To some a curse, to some enlightenment. :)

In my experience React + TypeScript is a match made in heaven. You are basically writing pure TypeScript in TSX.

It certainly isn't bad and is my first choice. But, do you have a deep understanding of how React's rendering model works in all edge cases? Because that part really isn't heaven for me. Feels more like trying to navigate a minefield.

I don't and can see how in edge case scenario's one can run into discrepancies between Reacts typings and advanced edge case workarounds. Especially since React itself isn't written in TypeScript.

> In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need.

I think others have offered sufficient/agreeable takes on this, but as the OP, I'll firstly point the pain finger at our own development and blame far too much state/ui/biz logic existing in the web in very tangled and inappropriate ways (part of the nightmare I inherited). Beyond that, the actual vue2-related pain points are typically ecosystem-related support (packages, etc.), and specifically being able to adapt to typescript (this project was initially done in early vue 2.x with just javascript, and attempting to reimplement in typescript to address some of our pain was not fun)