[spankalee]

You don't need diffing or reconciliation to turn a description of DOM into DOM. Lit works without a VDOM.

If all JSX does is return a DocumentFragment that you then need to imperatively add event listeners to and imperatively update, how is it much better than innerHTML?

[Izkata]

innerHTML loses all local state, such as which elements have focus or where the cursor is in a text field. Back when React first came out and people were getting used to the idea of VDOM diffing, they had demos front and center about how by using those diffs to only change what needed to change, such local state wouldn't be lost.

This in theory could do something to copy that local state over, or diff the two DOMs directly without a VDOM (though from the sound of it, it probably doesn't).

[esprehn]

I think the answer to that is probably "as good as soy, but with modern ergonomics". E4X was basically this and I think it's a much nicer way to build DOM trees than strings since you can't create invalid markup or concat partial tags. It also lets you reuse subtrees naturally where innerHTML makes that impossible.

[recursive]

You can have JSX that produces DOM nodes or "light-weight element descriptions".

You can have imperative event listeners and updates.

These are two independent dimensions. I made UI framework called mutraction that produces real DOM elements from JSX expressions. It also updates any contents or attributes of those DOM nodes based on their dependencies without requiring imperative DOM interaction from application code.

https://github.com/tomtheisen/mutraction

Here's a click counter. `track()`, as you might guess creates a proxy so that reads and writes can be converted into dependencies.

    const model = track({ clicks: 0});
    const app = (
        <button onclick={() => ++model.clicks }>
            { model.clicks } clicks
        </button>
    );

    document.body.append(app);

[lolinder]

1) Type safety for element props.

2) Autocomplete for element props.

3) IDE support such as refactors and jump to definition/jump to usages.

4) Proper syntax highlighting out of the box instead of the editor just saying "there's a string here".

5) A uniform pattern for defining custom components that work the same as primitives, rather than defining custom components as helper functions returning string fragments or something like that.

And so on. JSX has a lot going for it regardless of the semantics chosen. It's just a syntax that is very convenient for lots of kinds of tooling, and it's completely unopinated about the semantic context in which it is used.

[_heimdall]

These are definitely helpful, but what you are describing are all language tool features rather than features of JSX itself. 5 would be the exception, but that is just user preference of what kind of syntax one likes to write components with.

[lolinder]

Well, yes. But OP was asking about what makes this better than `innerHTML`, and the obvious answer is that support for HTML programming embedded in JavaScript strings is generally bad while support for JSX is very good across all editors.