I think you have forgotten another of the main points why react should not be the first option. I'm talking about one of the ugliest and most aberrant things that have been done related to the web lately. Of course I'm talking about JSX
Regarding the code sample above: there is no such thing as "React ul loop syntax". It's just plain old mapping any JS dev already knows, with JSX output. With Angular etc. you need to learn a framework-specific syntax, which is fairly easy with loops but gets messy as you go deeper.
I don't buy the "logic coupled with syntax" argument, either. It's perfectly fine to couple UI-related logic (animations, accordion states, focus trapping in modal windows, you name it) with the UI itself.
Now, if by "logic" you mean sending network requests or managing application-wide state, then just don't do this in UI components, what's so difficult about that?
I completely agree, also that code example shown is something I never encountered in 15+ react projects I worked on. It is not just the way you could write code then show the worst example you could think of, it also goes down to how you compose code and separate logic, data and ui also coupled with understanding how components work and how deep down the rabbit hole you want to go!
Comparing the ugly spaghetti code that forces you to produce JSX with the clean, comfortable and easy template engine of frameworks like Angular, Vue or Svelte??. Analyzing one of the most basic examples:
As I've said, to each their own. I might have been burned by AngularJS that I don't really like HTML template strings or whatever. JSX feels really good to me and tooling for it is phenomenal since it's "mostly JavaScript". Although I do admit it can get a bit complicated at times if you have lot of conditional rendering or stuff like that.
One small flaw with this example is that you show React component rendering, but for Vue you just show the syntax for that component so these examples cannot really be compared. If this example didn't have ReactDOM.render call, it would then be apples to apples comparison in this case.
Completely contrived example. You are comparing apples to oranges by including extraneous stuff in the React section. Once you strip that away, you are left with just a few lines of what is essentially HTML + JS.
One can certainly argue that the mixing of HTML and JS in JSX is strange/unconventional. But I'd rather think in terms of JS logic that can spit out HTML than deal with some random template syntax. To each their own.
I have never said that it is not useful or powerful. I just think it's pretty ugly at the code level. In any case, HTML came before Javascript and although a tag language may not be very attractive for modern programmers, for a reason of hierarchy and how the web works, I see more sense to put JS in HTML than the opposite
Comment hidden by post author - thread only visible in this permalink
For gods sake, if you write it like that, you would never be hired as a react developer in the first place.
React has no attribute based syntax with the exception of modified attribute names like className and onClick. I guess there’s key as well, but looping is never done in the attributes. It’s done like it would be done everywhere else in javascript, in a for loop, functional iteration, or using while. This enables backend js and front js to look similar.
I found out that spaghetti code comes from either devs who are trying to learn/understand something new or from seasoned spaghetti dev who doesn't bother to stick to good practices and is often lazy to read the documentation/guides before actually using something.
That also determines if someone would like to work with you or not if you are that second kind of dev.
I think you have forgotten another of the main points why react should not be the first option. I'm talking about one of the ugliest and most aberrant things that have been done related to the web lately. Of course I'm talking about JSX
Then use htm instead. :)
github.com/developit/htm
To each their own, I really like JSX. Prefer it way more than HTML templating for sure.
Regarding the code sample above: there is no such thing as "React ul loop syntax". It's just plain old mapping any JS dev already knows, with JSX output. With Angular etc. you need to learn a framework-specific syntax, which is fairly easy with loops but gets messy as you go deeper.
I don't buy the "logic coupled with syntax" argument, either. It's perfectly fine to couple UI-related logic (animations, accordion states, focus trapping in modal windows, you name it) with the UI itself.
Now, if by "logic" you mean sending network requests or managing application-wide state, then just don't do this in UI components, what's so difficult about that?
I completely agree, also that code example shown is something I never encountered in 15+ react projects I worked on. It is not just the way you could write code then show the worst example you could think of, it also goes down to how you compose code and separate logic, data and ui also coupled with understanding how components work and how deep down the rabbit hole you want to go!
Comparing the ugly spaghetti code that forces you to produce JSX with the clean, comfortable and easy template engine of frameworks like Angular, Vue or Svelte??. Analyzing one of the most basic examples:
I'm really trying to understand your position my friend, but I just can't ...
As I've said, to each their own. I might have been burned by AngularJS that I don't really like HTML template strings or whatever. JSX feels really good to me and tooling for it is phenomenal since it's "mostly JavaScript". Although I do admit it can get a bit complicated at times if you have lot of conditional rendering or stuff like that.
One small flaw with this example is that you show React component rendering, but for Vue you just show the syntax for that component so these examples cannot really be compared. If this example didn't have ReactDOM.render call, it would then be apples to apples comparison in this case.
You can't decouple view from the logic in react, no matter how hard you try, so it's a perfect example
Completely contrived example. You are comparing apples to oranges by including extraneous stuff in the React section. Once you strip that away, you are left with just a few lines of what is essentially HTML + JS.
One can certainly argue that the mixing of HTML and JS in JSX is strange/unconventional. But I'd rather think in terms of JS logic that can spit out HTML than deal with some random template syntax. To each their own.
I have never said that it is not useful or powerful. I just think it's pretty ugly at the code level. In any case, HTML came before Javascript and although a tag language may not be very attractive for modern programmers, for a reason of hierarchy and how the web works, I see more sense to put JS in HTML than the opposite
For gods sake, if you write it like that, you would never be hired as a react developer in the first place.
React has no attribute based syntax with the exception of modified attribute names like className and onClick. I guess there’s key as well, but looping is never done in the attributes. It’s done like it would be done everywhere else in javascript, in a for loop, functional iteration, or using while. This enables backend js and front js to look similar.
It’s lovely
Garbage In, Garbage Out. Don't blame the tool.
As a contrast, I really love JSX. I love how we use javascript's 'map' to render list. I don't know, maybe it's just me.
One thing I know... I don't want to maintain the templates that you wrote,
but you will find my typed JSX easy to maintain yourself
Although I don't really like JSX in the past, I have changed my mind.
JSX is the best way for your template engine to be smart with IDE, being a mere JavaScript function, that is.
Spaghetti or not is something you have to learn to manage your code.
I found out that spaghetti code comes from either devs who are trying to learn/understand something new or from seasoned spaghetti dev who doesn't bother to stick to good practices and is often lazy to read the documentation/guides before actually using something.
That also determines if someone would like to work with you or not if you are that second kind of dev.
Mmm seasoned spaghetti dev, my favorite 🤤🍝