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.