9 ms·

Slightly tangential question: Where is jsx defined, as a language? are there multiple transpiler implementations? is it standardized at all?

• Waterluvian 2y ago
  https://facebook.github.io/jsx/ https://facebook.github.io/jsx/ answers some of that.
• mmis1000 2y ago
  JSX only have syntax defined but not semantics. The equivalent runtime js code is up to the compiler of the framework you are using (And even react itself have two compile modes now).
• meiraleal 2y ago
  JSX was unique while we didn't have native string interpolation in JS. With Template literals, JSX isn't that special anymore.
  • jampekka 2y ago
    Don't know why you are downvoted (Stockholm syndrome, sunken cost fallacy?), but JSX is a bizarre hack, and there are many less hacky alternatives, like template literal based HTM, function based hyperscript and even const e = createElement.
    • a_wild_dandan 2y ago
      My guess: It's probably downvoted for being so hilariously wrong that's not worth engaging with. One of those dismissive hot takes commensurately worth dismissing too.
      • jampekka 2y ago
        These kinds of answers (and downvotes) typically stem from not having any substantive arguments for a held position.
    • rvense 2y ago
      IME "I'll just use createElement" leads to "Oh dear, I have to add another createElement" which leads to "I really don't like reading this code". But of course it's a trade off.
      • jampekka 2y ago
        How is that different from adding yet another JSX tag which leads to another JSX tag which leads to even worse "I don't like reading this code."? I admit that the parens and braces mess causes significant readability issues (though less than the tag soup). E.g. coffeescript gets rid of this problem very elegantly. But, when coffeescript is discussed, it's "syntax doesn't matter, just use ES6" but when it's JSX, syntax is crucial. It's sunken cost fallacy, Stockholm syndrome and FUD.
        • boredtofears 2y ago
          Personally I think "tag soup" (or, what I'd call a well structured XML document) is much easier to read than a deeply nested or scattered set of function calls.
          • jampekka 2y ago
            Or you're just used to it. We get quickly used to e.g. our own body odor or halitosis so well that we can't smell it at all.
            • boredtofears 2y ago
              Of course. Isn’t that the case with any code?
              • jampekka 2y ago
                Of course. But I sometimes try to smell some fresh air to check what I've gotten used to.
        • rvense 2y ago
    • ttfkam 2y ago
      I'm still laughing about the fact that JSX renders to XHTML, not the HTML5 that browsers actually use. 99% of the time they're the same and parsing occurs as expected. That last 1%, things get weird quick.
      • recursive 2y ago
        Jsx doesn't "render to xhtml". Its syntax is similar to XML, but not the same. It's similar to HTML, but not the same. It's similar to XHTML, but not the same. In most react apps it renders to function calls like createElement or _jsx. The reconcile will turn these into DOM objects without any markup representation at all.
        • ttfkam 2y ago
          Do you have to close all of your tags? Yes. Is the markup based on HTML with XML rules like closing tags? Yes. Do you even have to close the tags of your custom components? Yes. When generating your createElement sequence from JSX, does it create or close tags in a different order/hierarchy than what you specified in the JSX? No. Does it emit markup or element creation calls that match the parsing behavior of HTML5? No. Walks like an XHTML duck. Talks like an XHTML duck. It's an XHTML duck despite the JS interop and the lack of DTD preamble.
          • recursive 2y ago
            Does not have namespaces (in react), CDATA, schemas, and more. And none of this is "rendering".
            • deleted 2y ago
              [deleted]
            • ttfkam 2y ago
              The "reconcile" (my God do geeks love making what they do sound fancier than it is) does not match the HTML5 parser "reconciliation" spec. The DOM element API "emissions" match the order triggered by the markup parsers. Y'all are tiresome sometimes.
    • BalinKing 2y ago
      I must make a confession: I've honestly never understood why JSX is considered hackier than, say, template literal based HTM (or especially the bespoke pseudo-HTML you find in frameworks like Vue, which has always felt to me like the worst of all worlds). Is there a concrete reason I'm missing, or is it just a matter of taste?
      • jampekka 2y ago
        I think it's having to extend the syntax so dramatically and bring new semantics to the language (actually a new language) and necessicating an extra complilation step for dubious payoff. It makes the language substantially more complicated, with additional corner cases (e.g. className and htmlFor). For what I see as solely matter of (bad) taste (being used to XML syntax for defining elements, and abhorring extra backticks?). The pseudo-HTML is not far from JSX in the hackiness, but at least it's embedded in HTML.
        • WorldMaker 2y ago
          JSX as a syntax itself doesn't require `className` and `htmlFor`, it can support `<div class="example"><label for="someInput">Hello World</label></div>` just fine syntactically, that React API choice is a leak from the standard DOM API which use `className` and `htmlFor` for historic reasons (of bad parsers and stricter keyword parsing in earlier JS standards). In theory by using the DOM names React has less work to do when diffing DOM elements (though how much React actually benefits from it today is an interesting discussion). (Possibly relevant source/proof: my TSX-based library supports the HTML shortcut names just fine, like: `class`: https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb5954993086877e5bb9cfe781811/static-dom.test.tsx#L23 https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb... `for`: https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb5954993086877e5bb9cfe781811/static-dom.test.tsx#L59 https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb...)
• WorldMaker 2y ago
  > Where is jsx defined, as a language? https://facebook.github.io/jsx/ https://facebook.github.io/jsx/ is the primary home. > are there multiple transpiler implementations? Yes. Off the top of my head: Babel: https://babeljs.io/docs/babel-plugin-transform-react-jsx https://babeljs.io/docs/babel-plugin-transform-react-jsx Typescript: https://www.typescriptlang.org/docs/handbook/jsx.html https://www.typescriptlang.org/docs/handbook/jsx.html esbuild: https://esbuild.github.io/content-types/#jsx https://esbuild.github.io/content-types/#jsx > is it standardized at all? In terms of well documented, yes. In terms of a TC-39 standard accepted as a part of JS and intended for browsers to consume? No. Unless you count how much it borrows from E4X [0] which was an optional part of the "lost version" of JS that was EcmaScript 4, then "sort of". [0] https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML