As someone who worked with both, vue 3 is miles ahead imho. Scoped css, well working two-ways data binding (now being mimicked again with signals after mobx demise) and reactivity, easier to get performance out of the box without the hook madness.
In many ways I do agree with you, but by now all these front-end frameworks and libraries, including their server-side rendered counterparts (like Nuxt, Next, etc.) just keep borrowing things from each other.
Regarding performance, I remember having blocking sluggishness with v-model that shouldn’t have been there back in Vue 2 days.
Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.
Vue 2's transition to Vue 3 (if you want to use the new CLI tools and the Composition API) had to, by definition, fragment the ecosystem in unpleasant ways no matter how carefully and sensibly it was managed by the core teams in charge.
You can see that Vue went down slightly in recent developer surveys, and I suspect this to be among the main reasons. As if Evan himself would be suddenly more focused on his build tool Vite as opposed to Vue itself (of course it's just an illusion).
But I still love Vue because of their amazing docs, and the fact that they let me enter the world of web-development in a relatively accessible manner (this may not have been possible with React, for me personally). Lack of something like scoped styles alone baffles me in React to this day, but it makes kinda sense in the ecosystem it's operating in...
Oh, nice for reminding me, SSR is also better imho on Vue with Nuxt than anything in react world. Next.js has the tendency of monkey patching plenty of APIs, even broke native fetch when uploading anything bigger than 14 kbs.
Remix is the gold standard of SSR to be honest. I worked with both, Nuxt and Next.js, but Remix with is heavy usage of web standards just makes the most sense to me.
To clarify: there's no "native" fetch to patch. Both Nuxt and Next have been adding it to the runtime to normalize it across Node.js versions and environments, and to add critical capabilities that the Web standard lacked (like being able to read the `set-cookie` header or customize `Host`).
Worth noting: we've been enabling SSR for React since 2016[1], and some of the largest websites on the internet SSR with Next.js: Twitch, Hulu, Nike, and even parts of Amazon[2]
> Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.
I had a look at the component libraries that are compatible with Vue 3 a while back and concluded that either PrimeVue or Quasar are some of the better choices for my web dev needs.
Surprisingly, many of the formerly popular options are stuck with just Vue 2 support.
I never really got why people LOVE two-way binding to the point that they add things like mobx to projects. IMHO the one way data flow makes things so much easier to reason about.
MobX is fantastic! But you do have to change your philosophy quite a bit compared to what you would do in vanilla React - namely you need to displace most of your state management to the outside of the components.
Once you do that, React becomes purely functional (and quite "uni-directional", if that's the right term). Just update the state (in an event handler or when a Promise resolves after a fetch or another part of the UI finishes) and UI auto-magically reflects that on the screen.
Arguably, MobX + React is closer to the React's original ideal of `UI = f(state)` than the vanilla React itself.
Two-way data binding trades a slightly more complex and less transparent rendering model for more efficient rendering. You don't re-render the entire component and diff the two components you have to understand changes, you simply change the leaf.
I'd say in Vue it rarely causes troubles, in React world it leads to few non-obvious edge cases where React's one way data flow is indeed easier to reason about (but less performant).
I think typescript support was a priority aspect to be addressed for Vue 3 making it sort of a first-class citizen. The whole new composition aspect of it was to address large codebases and large-scale applications. So I understood that V3 makes all the difference if TS support and working on larger project is important for you. In fact, I think if you are coming from React and try it out, you are highly likely to feel right at home there.
