I like to create the HTML and CSS as I'd like it with test data, then just wrap that with <template> tags. Easy to preview without triggering function calls or pasting it into code.

Probably not important, but as I recall I think there was some minor overhead in translating from a JS String to an Element.

I wish this were available natively.

There are a few things missing but jsx is sugar that complicates things for me.

Just teach people function composition. It's easier.

And that's irrespectively of my view on jsx, the latter which I find non ergonomic and confusing. That many people are being force fed it to the point of familiarity does not mean that it is the best DX.

we went from (html + js> to html in js and js in html. Quite very confusing to me. Knotty (naughty) complexity pun intended.

It's more akin to stockolm syndrom to not improve on the statu quo at this point.

  if (condition) {
    // new scope
    const jsx = // ...
    return <foo/>
  }

The main problem with this is that it's non-trivial to make sure variables are in scope before/while loading a file, and they should be loaded on an as-needed basis instead of always, which is what inevitably ends up happening when you need React classic, you import React at the top of every HTML file. These problems seem to be what led to auto-imports.

I admit that my solution still does require you do something like import interpretJsx from 'something', and even further it requires you to manually call interpretJsx(<foo/>) which can be tedious and verbose.

The main benefit is that at least it becomes a standard. And besides, we probably won't need to call those functions everywhere, just at the top of a tree, like the same place you call React.render(root)

The main downside is lack of monomorphism, especially if you're passing an entire tree to interpretJsx(). I admit this is not solved by my proposal. But I still wanted to put the proposal out before smarter eyes than mine anyway.