2 ms·
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 JS
by mewpmewp2 2y ago
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.
- apsurd 2y agoJS 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.