Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX."

I think the general distaste for JMX is that it "feels" backwards initially: it mixes in HTML snippets within code, while many people are used to template files, which are mainly markup with small bits of "presentational" code injected.

But once you realize and really understand that JSX is just shorthand for javascript calls (and the article does a good job of explaining this), you hopefully eventually reach an "Aha!" moment of thinking of JSX in terms of underlying component creation. That's what happened to me, anyway,.

You’re right that none of these alternative ways of writing JSX syntax are better than JSX. But I think you miss why people don’t like JSX in the first place;

Having to compile your javascript sucks.

If your framework requires me to have a build system in place just to write some javascript, I’m either not going to use it or, if forced, I’ll find whatever way I need to to get the code written without having to stand up a giant build system.

Naturally, the true solution for people like me is to use Vue or Angular or another library that’s not as intrusive as React. But sometimes we’re forced, so we use that terrible createElement syntax. And come away disliking React even more.

Using Angular or Vue without a module system sounds awful. How do you organise your code? Manual namespacing on the global object?

So I'm coming from a perspective where I will definitely be compiling my JavaScript regardless, and adding JSX doesn't make much difference complexity wise (and provides a much nicer syntax).

ES modules with relative URLs have shipped in browsers, and when import maps [1] land, it could become viable to not bundle or transpile for local development and only do so for production builds.

1: https://github.com/WICG/import-maps