> article just about to turn three years old
JavaScript community never beating the allegations lol
Basically every framework now has a concept of * State - change this and the framework automatically updates UI and triggers effects * Effects - functions that run when parts of state change (or triggered by signals)
And almost everyone solves this with signals except for React.
At this point, I think React and Lit are the only major frameworks not using signals. And I'm not 100% sure about Lit.
IMHO, React wins because you can just treat templates as variables. You don't need "slots" or other special stuff. It's simply more composable.
The real discussion would be between React's vdom and something like Solid's signals.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
Please explain React’s reactive data binding since it’s apparently much simpler than v-model=
;)
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
I'd take the former any day.
{enable && <Form />}
{collection.map(x => <Item x={x} /> }
Can you be sure that the value is present? How do you check for it? What does Vue need to do to enable this functionality with static type checking with TypeScript?
With `{x && <>{x.y.z}</>}`, it's almost vanilla TS, it's the same as `x && x.y.z` in normal TS. Type narrowings that work in TS are guaranteed to work in React, without the framework having to do anything.
Less framework/library code required to make the same thing work. To me, that's the sign of a better abstraction and implementation.
The words borrowed from someone else:
The react is more about view.
The vue is more about reactivity
It is a fairly painful process - I am using Codex and Claude as a first pass for converting things, but everything has to be checked manually and often fixed or rolled back to try again. Too often instead of "removing" piece of code that is not necessary anymore, AI would try to add a 100 line workaround for it because it would really rather add things than remove them.
It is, however still a faster process than doing manual rewrite. Smaller components are a breeze to convert from older Vue 2 to Vue 3 composition API.
Rewriting entry point app.ts with bunch of custom plugins was a horrendous experience that eventually was done manually. Move from Vuex to Pinia was also 50/50. Some things were easy, some things were not and had to be done manually.
Then there's a process of switching from unsupported packages which is a whole other can of worms.
Overall - if not for AI I'm not sure I'd have gone with an upgrade at this point. Yes it requires careful review and testing, but a ton of trivial stuff was done very quickly.
Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.