Comment by hunterb123

5 years ago

Repeating a blog post over and over doesn't make it true.

The author is wrong. Most of his statements are about React, not JSX.

It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props.

The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's a single expression.

Please go read the JSX spec instead of some random blog post.

https://github.com/facebook/jsx

Thank you for that definitive link. Note that first boldfaced sentence in that JSX specification is as follows: "It's NOT a proposal to incorporate JSX into the ECMAScript spec itself."

That should have been the end of this discussion and fight that you picked about your incorrect statement that "JSX is JavaScript". You just unwittingly undermined and terminated your own argument by linking to the JSX spec itself, which clearly and explicitly says you are wrong, in BIG BOLD WORDS.

As JimDabel said, "They wanted to be 100% clear about it." So stop repeating something that the JSX designers so insistent is not true that they put it in bold at the top of their design specification.

You already won this argument, for the "JSX is NOT JavaScript" side. It's over.

  • You're arguing the wrong thing. You're arguing a semantics debate about whether an extension is JS. I'm arguing that it allows you to use JS features instead of a custom template system.

    In the semantics debate you want to have I think it is JS because it all becomes JS bytecode and it's just nested function calls in the end, but that's subjective. If you want to be pedantic it's a JS extension, but in the future it could be JS if the spec is merged into engines not the compilers.

    JS is an umbrella term, you're arguing it's not Ecmascript, okay, I never said that. I said it's JS, and you want to have a tussle about it instead of comparing templating systems.

    Also you're very rude.

Right from the very top of your source:

> JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.

Further down:

> Why not just use that instead of inventing a syntax that's not part of ECMAScript?

It is not JavaScript.

  • We're splitting hairs now. It's an extension of the JS spec. Once a parser adds this grammar it is JS.

    It's syntactical sugar, unlike template syntax #if, ng-if, etc.

    Your argument is it's not part of the current Ecmascript spec, I never said it was, but if a parser or engine adds these two new PrimaryExpressions and attributes, it is JS.

    The entire point is JSX extends JS to allow templating via nested JS functions w/ pretty brackets instead of creating an entire templating system.

    Under your reasoning nothing that isn't in the current accepted Ecmascript spec implemented by browsers is JS. Does that mean decorators aren't JS? Were async functions not JS before they were in browsers?

    • We’re not splitting hairs. It is, quite literally, not JavaScript in a fundamental way.

      If you want to go around telling people it’s a non-standard extension to JavaScript or if you want to go around telling people it’s a superset of JavaScript, then by all means do that. But it is simply not JavaScript. Why do you insist on saying otherwise? All that does is start completely pointless arguments. What do you gain from insisting it is JavaScript when it isn’t?

      21 replies →

and if you really want to use statements, you can, using an IIFE for example. It’s not pretty but you can because… ehm… it‘s just javascript.

At this point the "is JSX just javascript" discussion has gone on a little to long imho. It feels like "is html a programming language". We all have strong convictions about the answer but it doesn‘t matter, really.

It‘s interesting that fans all of 3 frameworks constantly claim that it’s "just“ or "closer to vanilla" html or js. Should we really care anymore?