I seriously cannot wrap around my head how in 2022 people really like JSX and all that X-in-JS crap, it's like people doesn't know about separation of concerns or clean code at all.
For almost anything more interactive than a static document, modularizing UI code primarily based on component boundaries makes a lot more sense than modularizing primarily based on markup / interactivity / styling boundaries.
Exactly, it comes from a bygone era when there was a clear separation between frontend developers (i.e. people that wrote markup, CSS, and jquery style JS) and backend developers (people that wrote PHP, ASP, java, etc. to spit out markup that frontend devs wrote). Nowadays everyone is basically full stack with specializations or focus in specific parts.
One could argue the adoption of JSX actually allows for better seperation and cleaner code as you can group all the necessary pieces of your component together, and use components declaratively without introducing some DSL seen in some frameworks like Vue, Angular etc.
Vue's concepts in the v-* are more pleasant than the React way, imho. Learning a bit of DAL is not a blocker for me, given how many tools already require this
I'd rather just use JS syntax than learn a random v-* syntax.
You can just use the std lib to loop, filter, reduce, conditionally render, etc. rather than looking up how to loop in this specific framework with v-if, v-for, etc.
Angular 1 did that and it was limiting. Two-way data binding also failed.
I don’t particularly care one way or the other. I like Vue because it offers flexibility and some opinions. If I want to write a jsx render function, I can do that. If I have a simple functional component for an icon or whatever, I can use the DSL and it’s statically compiled for the final build.
I don’t agree with your point about copy cat frameworks generally, as we’ve reached the point where all the major players are adapting each other’s ideas constantly. I think any of the modern JS frameworks are more than capable of handling any use case.
There are quite a few motivations for this, but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.
True. I like keeping my knives, forks, and spoons separate.
Alternatively, try organising your cutlery by "implement" and "handle". Surely, separating what goes in your mouth from what your grubby hands touch is the right thing to do. The two concerns that should be kept separate!
To push this analogy over the edge, the former is how I see JSX. And my admittedly facetious proposal is how I view the "classical" approach of strict HTML|CSS|JS separation.
Which poses the question: after seven+ years of JSX and it having become the most prominent approach to building UIs, can the "classical"way even be called that anymore?