[Touche]

> Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.

I don't understand your point, to be honest. A lot of language features are just syntactic sugar for lower-level language functionality. ES6 getter/setters are just syntactic sugar for Object.defineProperty. Does this mean that ES6 and ES5 are the "same"?

No, of course not, but ES6 getter/setters are specified in ECMA-262 and JSX is not, so ES6 gets to be called JavaScript and JSX doesn't. It's really as simple as that.

My point is that because JSX is not JavaScript it then requires a ton of complexity to use it. Whether that complexity is justified is up to each person, but we can't ignore that complexity exists when arguing it vs. alternatives.

[kentor]

It's literally as complex as transpiling ES6 to ES5.

And although JSX is not in the ECMA-262 spec, it does have a spec, so there's that.

[Touche]

Transpiling is complexity. You don't have to transpile if you just use web technologies (JavaScript, HTML, CSS).

[kentor]

Of course it is, but saying it's "a ton of complexity" to use JSX, while not saying the same for transpiling current and future ECMA-262 syntax into what browsers support right now is disingenuous.

[Touche]

No it's not, transpiling future ECMA-262 is not within the scope of this discussion. We are compared browser-native language features JS (non transpiled), HTML, CSS, to non-native features, namely JSX.