Comment by jdkoeck

It's good when someone advocates for what they believe to be progress on the web platform, but it's not necessarily clear that this would be progress. And that line in particularly is amusing because we absolutely don't know what good syntax for templating looks like — that's why there's so many different options.

JSX is certainly the most popular because it's used in the most popular framework, but it has some very clear weaknesses. In particular, it has very clear semantics for a React-like, VDOM-based framework, but those semantics do not work as well for other kinds of framework.

For example, you mention control flow via ternaries/`.map`. This works great in React, where the entire template will be reevaluated every time any input changes. However, frameworks like SolidJS or Vue in Vapor mode work very differently, and typically evaluate JSX only once at component mount (or at least, as seldom as possible). To support these, these frameworks need to use either special components like `For`/`Show`, or directives like `v-if`.

There's also the issue of how to evaluate JSX. In theory, JSX is flexible, in that `<Cpt prop={expr} />` can be converted to any call of the form `h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or Vapor mode Vue — in both of these frameworks, `expr` cannot be eagerly evaluated, so the traditional transforms just don't work. Both of these frameworks therefore have to include their own custom plugins for handling JSX correctly.

The author's suggestion to also use signals as a state mechanism suggests they're imagining something more along the lines of SolidJS. That's an odd choice (it's my personal go-to framework, but it's also very niche), but it also implies, as discussed, that JSX-in-the-browser wouldn't behave like JSX-in-React. From experience, that will cause problems! I've worked with React developers before who've really struggled to use SolidJS because of precisely this issue.

> yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).

This is not true. For instance:

Vue uses markup-based templates like this:

    <ul>
        <li v-for="item in items">
            {{ item.message }}
        </li>
    </ul>

Svelte uses text-based templates like this:

    <ul>
        {#each items as item}
            <li>{item.message}</li>
        {/each}
    </ul>

Angular uses markup-based templates like this:

    <ul>
        <li *ngFor="let item of items">
            {{ item.message }}
        </li>
    </ul>

And let’s not forget that the world doesn’t begin and end with JavaScript. Most other templating systems are either markup-based or text-based. For instance, Jinja2 is text-based:

    <ul>
        {% for item in items %}
            <li>{{ item.message }}</li>
        {% endfor %}
    </ul>

JSX really isn’t that great. Sometimes it feels like most React devs don’t know how to write a for loop or if statement because they mostly use map(), ternaries, and short-circuiting, which are not very ergonomic compared with markup-based approaches.

I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way.

And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.

JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.

Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.