As someone who switched from Vue 2 to React around when hooks were introduced, can someone explain to me why they like non-React frameworks? Based on my experience, they all have some drawbacks:
- Template languages instead of JS. If I want to perform some operation, I have to use their if and for constructs in their unique template language. In React I can just write JS.
- Due to the above, TypeScript support is often lacking or outright poor. IDE support also usually is less than React. The maintainers of the IDE plug-ins simply don't have as much bandwidth as those of React, likely due to lack of man power.
- Vue has a weird plugin architecture, I remember that I couldn't simply import a library as in regular JS or React, I had to register it as a plugin for some reason. Not sure if the situation changed since Vue 2.
- Vue also has a weird way of writing out the code, it had to be done inside an object in the script part of the single file component.
- Speaking of SFCs, cool concept but again depends on IDE support. I'd much rather have a folder for each component and colocate my CSS and JS files there as in React, or use a CSS in JS solution.
- Signals and two way data binding are not as good as people think. When you have a big enough project, you'll understand, as changing one thing can change something else completely separately and debugging is like untangling spaghetti. I actually had to do this for a big Vue 2 project and it just put me off from the concept. There's a reason why React has explicit one way binding, even if it's more code to write and wire up.
- Hooks are incredible. For people who don't get it, they should actually read this GitHub issue about adding something similar to Flutter, the author Remi Rousselet is a well known library author and shows the value of hooks in any declarative UI framework. He explains how, much as functions encapsulate state, hooks encapsulate life cycles, and how mixins fundamentally cannot work the same way in a class based architecture with component life cycle methods.
https://github.com/flutter/flutter/issues/51752
- Even if everything all else was equal, everything above was fixed, the main difference for switching is that library support is vastly, vastly lacking for non React libraries. The community assumes React first over anything else, and the quality of React libraries vs non React ones are night and day. Take react-three-fiber or Framer Motion for example, no way there's something of that quality in non React ecosystems
- I even got annoyed by the lack of library support and being treated like a second class user and switched to React. The network effect is real.
First, Jsx is also a templating language. Second, Vue & svelte templates are html super set. So you can leverage your existing html skills. Vue allows you to use pug (and any other html compilation language). Templates also enable performance optimisations while jsx don’t. Jsx is more powerful construct, hence Vue supports it.
- weird plugin architecture.
All plugin architecture are weird. You can choose to not use plugins or write one. But they exist so for convenience of users
- weird way of writing code. An object inside script of sfc. And SFCs
Your mileage may vary. I prefer vue sfc. Especially because it is html like syntax and makes sense to me. If you prefer separate files, you can split html/js/css to separate files and link via src attribute
- signals and two way data binding
Vue has unidirectional flow. And two way binding is just syntax sugar for form inputs. And it is very good, if you have used react form, then you know what I am talking about
I'm primarily a React user and would generally agree with you, but I understand why people like Vue/Svelte.
- Templating languages have been around for years, and for many, they feel like the right way to write markup. If someone has used Handlebars in the past, the templating constructs feel familiar. There is also the idea of keeping logic out of your views with the restricted feature set of your templating language. Finally, conditional logic is simply easier in a templating language vs JSX. This will be true until we get pattern matching or the do expression, ternaries, and boolean expressions are clunky. Solid added constructs for conditions and looping to JSX, mainly for performance, but it's much more ergonomic.
- People like the SFC pattern precisely because everything is separate. Your logic is separate from your markup, which is separate from your styling. For me, it feels like a throwback to the times of MVC when it was good and proper to separate your concerns that way. Some reject React out of hand because "there's no default solution for styling".
- The composition API in Vue 3 and Svelte's stores provide the same abstraction potential as hooks. Their reactive primitives aren't tied to the component lifecycle, which is a really nice benefit. It avoids a lot of the context performance pain that people can end up in.
Overall, I'm not really sold on SFCs. They inherently limit you to one component per file, a tradeoff I don't like. There are also the type and IDE support issues which will always be an uphill battle. Template languages are at least better than lashing everything in template strings which is becoming a thing now.
- Template languages instead of JS. If I want to perform some operation, I have to use their if and for constructs in their unique template language. In React I can just write JS.
- Due to the above, TypeScript support is often lacking or outright poor. IDE support also usually is less than React. The maintainers of the IDE plug-ins simply don't have as much bandwidth as those of React, likely due to lack of man power.
- Vue has a weird plugin architecture, I remember that I couldn't simply import a library as in regular JS or React, I had to register it as a plugin for some reason. Not sure if the situation changed since Vue 2.
- Vue also has a weird way of writing out the code, it had to be done inside an object in the script part of the single file component.
- Speaking of SFCs, cool concept but again depends on IDE support. I'd much rather have a folder for each component and colocate my CSS and JS files there as in React, or use a CSS in JS solution.
- Signals and two way data binding are not as good as people think. When you have a big enough project, you'll understand, as changing one thing can change something else completely separately and debugging is like untangling spaghetti. I actually had to do this for a big Vue 2 project and it just put me off from the concept. There's a reason why React has explicit one way binding, even if it's more code to write and wire up.
- Hooks are incredible. For people who don't get it, they should actually read this GitHub issue about adding something similar to Flutter, the author Remi Rousselet is a well known library author and shows the value of hooks in any declarative UI framework. He explains how, much as functions encapsulate state, hooks encapsulate life cycles, and how mixins fundamentally cannot work the same way in a class based architecture with component life cycle methods. https://github.com/flutter/flutter/issues/51752
- Even if everything all else was equal, everything above was fixed, the main difference for switching is that library support is vastly, vastly lacking for non React libraries. The community assumes React first over anything else, and the quality of React libraries vs non React ones are night and day. Take react-three-fiber or Framer Motion for example, no way there's something of that quality in non React ecosystems
- I even got annoyed by the lack of library support and being treated like a second class user and switched to React. The network effect is real.