First, "standards"-compliant HTML was never that important because the browsers were all so tolerant of malformed HTML anyway, and continue to be. And these days, the standards matter even less when there's really just Webkit and Blink. Gecko is a rounding error. You can write strict HTML to your heart's delight, or just kinda half-ass it. It doesn't really matter either way, since most users will use the same renderer anyway.

Then, even if you DO adhere to strict standards, they are so low level as to be useless. HTML + CSS defines a barebones, ancient layout system for simple documents -- which most of the web isn't anymore. Want to do a simple nav bar? There is no simple "nav bar" standard. You hack it by overloading a list and repositioning the components using CSS, then sprinkle in ARIA args on top of these overloaded components to tell the screen reader exactly how you decided to abuse the markup. Want to do a responsive popup modal with a scrollable table inside? You create your own recipe for tag soup, with your own media queries and wraps and scrollbar hacks and hidden elements. And every dev ends up doing this. At the level of abstraction of an actual UI, there isn't a standard, just different hacks on top of HTML. "Semantic" HTML and JSON-LD etc. all came and went. In the end you have every webpage reinventing the wheel to create the simplest of UIs, because there wasn't really a "standard", just super low level rendering primitives. There is no real system for componentization or templatization, and every server side language invented their own.

Enter JSX, which primarily gives you a more useful system of abstraction: that of components, composition, and inheritance, rather than meaningless tags like "div" or "span". This system allowed the creation of an ecosystem (as opposed to snippets) where different packages from different teams (or companies, or OSS) can interact by passing parameters/properties back and forth, something that was pretty much impossible to do when you were just overlaying HTML on itself (early jQuery libs tried to do that and ran into constant problems with clashing event handlers, z-axis issues, CSS namespace conflicts, etc.). From there you can create style and component systems (like MUI or Chakra), or roll your company's own, from which downstream app and UI designers can actual compose business applications. This was all just basic functionality offered by the likes of WinForms and Visual Studio back in the 90s or before, but which HTML never really had until JSX took over. Then from there we got an extensive ecosystem of powerful typing, transpilation (including to native and Electron), linting, etc., all built on top of simple syntax and somewhat reusable components. There's a very simple reason React took over and became the real defacto standard: It was useful. JSX outside React also sees adoption from other frameworks because it is useful.

Purity is meaningless and pointless. Whatever standards are set today will be reinvented and ignored and superseded by the next big company or movement. From Netscape to Microsoft to Meta, every major company overloaded HTML because it was (and remains) uselessly low level. CSS and JS themselves took years to be adopted and fought long wars against ActiveX, Flash, and even Canvas -- again because HTML was so limited.

JSX frees you from the underlying rendering concerns (which users don't really care about, and frankly most devs and managers don't either) in favor of UI components and useful business logic. Even if the resulting output can still be tag soup (if you don't use a good UI framework), at least it's consistent tag soup because of component reusability and inheritance. And in the best cases, it can generate much cleaner output than HTML because you start from strictly typed and strictly linted XML-like syntax instead of overloaded HTML tags and CSS overrides, giving you a degree of intra-codebase consistency that's very difficult to achieve, and inter-package interoperability that was straight on impossible in the past.

I'd argue that JSX and React are the best things to have happened to the Web since, oh, I don't know... the image map?

> because the browsers were all so tolerant of malformed HTML anyway, and continue to be.

You must be young and not remember. IE, Firefox, and Safari were all tolerant of malformed HTML but in wildly different and sometimes utterly incompatible ways! HTML5 was like mana from heaven when it was released. It codified exactly how HTML should be parsed, especially in cases where the input was far from perfect. It is an error to handwave that away and does not validate JSX's behavior.

Speaking of which, HTML5 precedes JSX by several years. They CHOSE not to follow the HTML5 parsing standard. This means the imperfect markup you put in JSX gets a rendering offset from what is actually delivered to the browsers. Since browsers all render according to HTML5 parsing rules, JSX by definition misses the target.

To top it all off, JSX simply CAN'T fix this behavior. HTML5 parsing rules would break existing JSX-based apps.

You may love JSX, but it is unambiguously broken in this capacity. It's not about "purity". It's about consistency. And JSX fails this metric when applied to the actual web.

I do remember... have been doing web stuff since Netscape Navigator, before CSS and JS were invented. I remember that long after HTML5, CSS ACID tests continued to be a problem for years, not to mention JS incompatibilities despite ECMAScript. It wasn't the standards that actually made cross-browser rendering realistic, it was polyfills, CanIUse, and later, the dominance of Webkit + Blink.

Even these days, compatibility is done through transpilations and automatic polyfills. JSX DOES fix that behavior because it completely abstracts it away (together with webpack, esbuild, etc.) and renders it an afterthought. You can write and think in meaningful components, not HTML soup. The build step isn't just a meaningless cost but makes a lot of the problems of the old days less relevant.

Edit: What this ecosystem allows you to do is build on top of other people's work. So one team can spend days/months just publishing polyfills and builders, another team can build components, another team builds UIs, and together they can work together to build a cross-browser, cross-platform app -- something that is relatively doable now, but was a huge undertaking in the barebones HTML days. It's only a "de facto" standard, but it did more for app development than any HTML standards body ever did. I say that because I DO remember, and how businesses struggled year after year after year not despite but because of the fake "standards" that browsers never fully followed.

I think you’re way off here. The basic consistency of parsing between browsers is absolutely the result of the HTML 5 standard. Polyfills and transpilation are rarely necessary in modern web dev.

(Transpilation can improve your dev experience, but you can easily get by in a pinch with the JS features that modern browsers support natively.)

95% of what you said has nothing to do with JSX, and most of it would apply to any good framework, so its not even react-specific.

Why do you thing that a specific syntax for writing createElement gives all these positives?

What do you think all of this renders down to? That's right, html, js and css. So if those are not properly standardized and working then your house of cards falls no matter how well you have built it.

JSX is the first major JS component ecosystem, which spawned builders like webpack and with them easy polyfills and linters. The standards are thus enforced during dev and build, then polyfilled or transpiled to whatever you need, whether that's different browsers or even native, etc. The underlying HTML no longer matters except to the lib maintainers.

JSX is not a "component ecosystem". JSX is a way to embed HTML-like syntax in JS and convert that to function calls. It does not grant any additional capabilities besides letting you write `<div>` instead of `react.createElement('div')` or `div()` or `h('div')`. Are you actually meaning react when you say JSX?

Builders, polyfills, linters, components, frameworks, etc. existed before and exists independently of JSX and react.

> The underlying HTML no longer matters except to the lib maintainers.

Would you hire a frontend dev that didn't know the difference between a <head> and a <body>? A <input> and a <select>?

Even if you would (which IMO is a very bad idea), the only reason you can build anything is that there is a well standardized base, which consists of HTML, JS and CSS. If those where not as stable, standardized and consistent as they are you would not be able to build rich web apps on top.