Hacker News Reader

Comment by meiraleal | Hacker News Reader

JSX was unique while we didn't have native string interpolation in JS. With Template literals, JSX isn't that special anymore.

View on HN

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.

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.

These kinds of answers (and downvotes) typically stem from not having any substantive arguments for a held position.

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.

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.

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.

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.

Of course. Isn’t that the case with any code?

Of course. But I sometimes try to smell some fresh air to check what I've gotten used to.

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.

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>`;

Right, JSX is not the only way of accomplishing a better syntax for dynamic HTML.

I was just saying that I do occasionally do things entirely by hand in Javascript with createElement, and it works for a quick thing but it is actually definitely a thing that warrents bringing in some alternative.

I was referring to React's createElement-function (and assigning it to const e for ergonomics).

  const div = e("div", {className: "thing-contents"}, "Hello")

Or with coffeescript

  div = e "div", className: "thing-contents", "Hello"

Or with coffeescript and simple Proxy wrapper:

  div = @div class: "thing-contents", "Hello"

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.

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

How is that better than jsx?

It doesn't need a new language and has a lot less noise. Loops and control structures work normally without extra syntax.

Coffeescript is a new language though?

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.

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.

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.

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.

Does not have namespaces (in react), CDATA, schemas, and more. And none of this is "rendering".

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.

I legitimately don't understand what you're getting at.

Where did you get this idea? JSX doesn’t specify what markup it renders to, or even that it renders to any markup at all. The syntax most closely resembles XML (and therefore XHTML), in that it requires closing tags (which might be satisfied by self-closing with />). But this is an authoring constraint, it has no bearing at all on output.

So… you can use other markups seamlessly like SVG and MathML… just like XHTML. Walk like a duck, talk like a duck.

Huh? I didn’t say anything about what markup languages you can use.

Not exactly seamless. You have to change some of the attribute casing in svg.

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?

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.

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/cb9498354a7fb...

`for`: https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb...)

Reply on news.ycombinator.com