The completely made up "@click" makes no sense outside of Vue. "count++" is a string that stands for real programming code? So we're making up pseudo code now. And the {{}} interpolation isn't real either, so it's not actually an HTML <template>
Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI.
React component is not the UI it's a JS function that yields the UI.
I've been involved in teaching React and FE for more than 10 years (many hundreds of students), and let's be clear here: Students don't understand that JSX is JavaScript either (and let's be clear here as well; it isn't - it's something that can be transpiled to JS). Rather, people believe it's HTML (since it looks like it), and very much confuses all the differences them in-between - in particularly when mixing with JS (eg conditionals).
Not saying that it's bad necessarily, but there are pros and cons to the JSX approach and the template approach (a lá Vue, or actually Mustache that Vue's template syntax partly comes from).
I think what's easiest/best comes down to:
1. Your background (ppl coming from BE tend to prefer to stay in a more full-blown programming language, people with a HTML/CSS background tend to prefer the template approach.
2. How junior you are. Generally people tend to say that React has more of a learning curve then Vue.
3. What your needs are. Full-blown web apps? Simple small enhancements of static websites? How much detailed/special control do you need or your components HTML output, etc.
PS. @click is actually very similar to the native click attribute. Furthermore, React has className as a special attribute that's definitely on a similar level same-but-not-really.
> React has className as a special attribute that's definitely on a similar level same-but-not-really.
The special React-ism that bugs me the most in this area is that React elements map the "change" event to "input". There's no way to handle "change" without getting a ref and wiring it up yourself. As a consequence, most developers don't seem to remember or ever knew what "change" actually is.
Despite Vue having this separate template syntax it felt very easy to learn and natural as opposed to the boilerplate that you get with React. It is not like JSX is understandable out of the gate if you know JS.
I have done html templating syntax in many different languages and frameworks starting with Laravel Blade and it always felt much better than the native syntax of doing that e.g. with PHP.
I don't think it ks a worthwhile feature to have everything strictly JS. Use different tools as they are appropriate, why hinder yourself.
Ultimately there are some very frequent and limited patterns in defining interactive html elements so best to use the syntax that has the highest meaning to noise ratio.
The combination of useState, stateValue, setStateValue are simply unnecessary boilerplate that makes important things like the state variable itself hidden in a sea of noise.
> React component is not the UI it's a JS function that yields the UI
I don't think that is a good philosophy at all. The code should be about clarity not around an odd dogma about having to be a JS function that yields the UI. It in my view is a misplaced enthusiasm for something that really doesn't matter, but will hinder things since you have to constantly work and hack around those self posed arbitrary restrictions.
JS function that yields the UI is not about dogma or JS enthusiasm, to be clear, I would prefer NOT to use JS. And I concede that frontend ecosystem really seems to see "everything in one language" as some kind of benefit and virtue. It's not!
The "everything is JS" and "JS yields the UI" is 100% based on the constraints of the runtime.
Modern UIs need browser APIs, events, DOM management, and stying. We MUST use HTML/CSS/JS. My take is "everything in JS" _in this context_ is more reasonable, more integrated, and ultimately more intuitive, not that it's simple or easy, but that we're stuck with the runtime, we're going to need these all to integrate with one another, let's be clear on in the integration interfaces.
In contrast, I can't understand how magic attributes on html nodes is more clear. What's your take on that?
For example in Vue's introduction:
The completely made up "@click" makes no sense outside of Vue. "count++" is a string that stands for real programming code? So we're making up pseudo code now. And the {{}} interpolation isn't real either, so it's not actually an HTML <template>Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI.
React component is not the UI it's a JS function that yields the UI.