7 ms·

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
      My time is currently divided between an Angular project and a "no framework" project, so it's been some time since I touched JSX but we are talking about the difference between: <MyThing><div class="thing--contents">"Hello"</div></MyThing> versus const div = document.createElement("div"); div.innerText = "Hello"; div.classList.add("thing-contents"); const wrapper = thingFactory(div); Aren't we? It just adds up very quickly is what I'm saying.
      - meiraleal 2y ago
        err... no? Example using Lit and Template Literals: html`<div class="thing-contents">Hello</div>`; Example using only web components: shadow.innerHTML = `<div class="thing-contents">Hello</div>`;
  - lelanthran 2y ago
    I'm doing a small project. I'm experimenting with a pure JS/HTML/CSS approach. 1. Doing "myElement.innerHTML = `...`" is sufficient for the low-hanging fruit that most jsx gets used for. 2. I also have a `Fluent()` function that returns an object with attrSet/attrRemove/classAdd/etc functions, which each also return the same object. It lets me do something like: var el = Fluent('div') .attrSet('disabled') .classAdd('waves btn btn-small') .idSet('MyNewElement') .push(Fluent('div') .attrSet('...')) .attachTo(document.querySelector('#SomeParent'); So far, I'm not liking the second one much, and the first one is really hard to compose, but they're both useful for when you don't want a build-step.
    - jampekka 2y ago
      With coffeescript you can easily do with a dead-simple createElement wrapper something like: el = @div disabled: true, class: 'waves btn btn-small', id: 'MyNewElement', @div ...
      - boredtofears 2y ago
        How is that better than jsx?
        jampekka 2y ago
        It doesn't need a new language and has a lot less noise. Loops and control structures work normally without extra syntax.
        boredtofears 2y ago
        Coffeescript is a new language though?
      - lelanthran 2y ago
        I think coffeescript requires a build step. If I already had a build-step, then sure, I can throw a few things at the wall and see what sticks. For stuff that doesn't have a build-step, adding a build-step just to get an alternative to using the backticks seems like overkill.
- 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...)

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
    My time is currently divided between an Angular project and a "no framework" project, so it's been some time since I touched JSX but we are talking about the difference between: <MyThing><div class="thing--contents">"Hello"</div></MyThing> versus const div = document.createElement("div"); div.innerText = "Hello"; div.classList.add("thing-contents"); const wrapper = thingFactory(div); Aren't we? It just adds up very quickly is what I'm saying.
    - meiraleal 2y ago
      err... no? Example using Lit and Template Literals: html`<div class="thing-contents">Hello</div>`; Example using only web components: shadow.innerHTML = `<div class="thing-contents">Hello</div>`;
- lelanthran 2y ago
  I'm doing a small project. I'm experimenting with a pure JS/HTML/CSS approach. 1. Doing "myElement.innerHTML = `...`" is sufficient for the low-hanging fruit that most jsx gets used for. 2. I also have a `Fluent()` function that returns an object with attrSet/attrRemove/classAdd/etc functions, which each also return the same object. It lets me do something like: var el = Fluent('div') .attrSet('disabled') .classAdd('waves btn btn-small') .idSet('MyNewElement') .push(Fluent('div') .attrSet('...')) .attachTo(document.querySelector('#SomeParent'); So far, I'm not liking the second one much, and the first one is really hard to compose, but they're both useful for when you don't want a build-step.
  - jampekka 2y ago
    With coffeescript you can easily do with a dead-simple createElement wrapper something like: el = @div disabled: true, class: 'waves btn btn-small', id: 'MyNewElement', @div ...
    - boredtofears 2y ago
      How is that better than jsx?
      - jampekka 2y ago
        It doesn't need a new language and has a lot less noise. Loops and control structures work normally without extra syntax.
        boredtofears 2y ago
        Coffeescript is a new language though?
    - lelanthran 2y ago
      I think coffeescript requires a build step. If I already had a build-step, then sure, I can throw a few things at the wall and see what sticks. For stuff that doesn't have a build-step, adding a build-step just to get an alternative to using the backticks seems like overkill.
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...)