> It is still a string, even if a template string or whatever it is called, no?

No.

> That still leaves the door open for XSS.

The door for that in React is called `dangerouslySetInnerHTML`, but it's extremely rarely used.

> jsx needs to rename HTML attributes, because of overlap with JS keywords like "class"

That's not really inherent to JSX, just React's use of it. SolidJS, for example, uses `class` instead. But in any case – JSX didn't make up those names. Those are the property names on JavaScript's DOM classes. The fact that there's confusion between "attributes" and "properties" is pretty baked-in to the Web platform, even causing confusion in standard Web Components. Every DOM library and framework (even jQuery) has needed to decide whether it's operating on properties or attributes.

    const div = document.createElement('div');
    div.className = 'foo';

> It also comes with hacks like "<>" or fragment.

The DOM has the same concept, DocumentFragment. How else would you represent e.g. "two sibling nodes with no parent node"?

> It lacks the awareness of context and therefore is not truly like HTML.

On the contrary, I'd argue it has way more context. It knows, and will warn you, if you try to do any DOM element nesting that the HTML spec forbids, for example.

> can be structurally pattern matched upon and iterated through, like a proper tree structure.

You are literally describing the output of JSX. Glad you like it ;)

Ah, seems a few things either changed in the meantime, while I have not dealt with JSX, or I remembered it wrongly. I thought the syntax was something like the following, which would be a special kind of string:

    return `
        <p>here some stuff <CustomComponent>looking</CustomComponent> almost like HTML, but not really</p>
    `

> On the contrary, I'd argue it has way more context. It knows, and will warn you, if you try to do any DOM element nesting that the HTML spec forbids, for example.

I was relating to naming it "className" instead of "class". If it was aware, it would know, that "class" is safe to use here, because it is inside some JSX syntax, not a class definition.

> You are literally describing the output of JSX. Glad you like it ;)

But that's the thing: I don't want to pattern match on the _output_ of JSX. I want to pattern match on the stuff while I am constructing it, shaping it, before I generate any HTML output. But perhaps, if you can show an example, I would know better what you mean. What I mean is something along the lines of:

    expr = <div><h1>heading</h1><p>foo</p></div>
    return match expr {
        <div>...any<p>...word</p></div>: word;
        _: "no word";
    }

The fragment "element" seems unnecessary in general. Just make

    return (
        <p></p>
        <p></p>
        <p></p>
    )

return a list of 3 items, ready to be spliced into another template with some syntax:

    const my_result_list = that_other_function();
    return <div>@my_result_list</div>;

which results in a div with 3 paragraphs. Here I am using "@" as example, but probably in JS land one would use "...". At no point do I need some <> or so.