alt Hacker NewsJSX is a huge conceptual mistake, IMO.
Sure, it gives you expressiveness, flexibility, and templating for "free", but this comes at the expense of the separation of concerns principle, which is a bad tradeoff.
HTML is concerned with the content and structure of the page. JS is concerned with behaviour and interactivity. Using JS, or any programming language for that matter, to control how HTML is rendered introduces reasoning problems about the content and structure that just wouldn't exist if you wrote plain HTML. Yes, modern web pages are almost always dynamic, but the correct way of implementing this is via the data model, or an intermediate controller layer.
That is, JSX enables the programmer to violate the MVC/MVVM model, which is a far superior approach of building applications.
I can't count the number of times where I've stared at a JSX file and had no idea what the "component" was actually doing. Reviewing any changes to it is practically impossible because you need to keep all the layers in mind, and essentially interpret the logic and rendering in your head.
This just doesn't happen with the MVC/MVVM approach. Every layer has a specific concern, and you can clearly trace the data flow, from when the data is read, to how it's used and manipulated, to how it's finally rendered. This is a major win for building maintainable applications, and disregarding this has made frontend web development an absolute hell.
It gets even worse when CSS can be written in JS as well... This "everything in JS" trend is an abomination.
Svelte does the right thing here and at least conceptually separates the layers, but at the end of the day, you're still writing in a DSL that gets compiled into JS, which has its own quirks and issues.
The frontend industry needs a hard reset that takes us away from this gigantic pile of abstractions and back to using native web technologies, which are quite capable on their own by now. Recently I've found Nue and Datastar to be the much needed steps in the right direction.
Replies
Well, I guess personal preference is also a thing. But I would say that the "market" doesn't agree with your thoughts on the matter (and I don't also, but my opinion matters way less).
You can write MVVM as an unmaintainable mess also. From my experience as a freelancer, I have had much harder time fixing badly written Angular projects (all versions) than such written in React. It seems that people as a whole tend to produce much better React than any other UI code that I have encountered ever. (and I have done my share of Desktop/Mobile too). Flutter is great, but it's also practically React in a proper language.
I totally agree about Svelte and the benefits of layer separation. I would say that philosophically, Svelte not only separates the layers, but gives HTML a special place among them, calling it "The Mother Language". [0]
Will check out Nue and Datastar.
I agree that JSX is a mistake, but I disagree with the "separation of concerns" part. The "separation" is useful when we know that separate people are going to be editing and changing the presentation versus the UI code. A bit like the .obc vs .h vs .nib files of older MacOS versions - you can carefully edit the .nib, and with any luck you don't want to touch the "actual" code.
But for most modern SPA UIs, this is actually less useful - because what you output into the DOM and the behavior are so intertwined. With setups like HTMX, for example, easily half of your HTML attributes can be interactivity-related. Yes, someone may be editing those separately - but they hardly will be able to edit them without any care for preserving the attributes, preserving the correct nesting the template needs to support the UI code, and on and on.
Hosting a "component" together with everything it needs to render inside one file is actually very handy, 90% of the time.
Where JSX is an issue is in the language department. The single reason we were forced onto the Webpack bandwagon - with all the years of endless tweaking, debugging and suffering that followed - was JSX, as you would have to jump through hoops to use React without the foreign syntax. A default React component was not valid JS, point.
So - expressing the DOM imperatively inside the component is fine. Shoehorning a syntax (which also requires workarounds like `className`) into another syntax and then requiring a preprocessor just for your code to work is... meh.
> practically impossible because you need to keep all the layers in mind…
> …with the MVC/MVVM approach. Every layer has a specific concern…
Do we need to keep all the layers in mind, or not?
Separation-of-concerns is not a virtue. It’s a trade off between separation-of-concerns and locality-of-behavior. SoC can be a benefit, if it matches your team structure. But also, any abstraction has a cost of increased cognitive load (and even worse is premature, wrong abstractions).
If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way (and in a small team, there’s almost no room for that to happen).
I can’t prove this obviously, but if I were betting, I’d expect more businesses have failed due to lack of velocity from over-engineered SoC apps, while the LoB monolith that’s easy for a small team to reason about found the right abstractions and won the market share (and later got rewritten as a SoC app, e.g. Instagram).