> 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.)
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.