In many Scheme dialects there is SXML, which looks just the same as normal Scheme code and actually also is normal Scheme code. You simply nest HTML tag names like so: `(div (p "here is my text" (span ,(calling-my-own-function-for-some-text)))) This builds up a tree structure, which ultimately gets fed into some function, which transforms it into an HTML string, which is send to the client. Before the transformation you can treat the tree just like any other tree, avoiding to have to parse anything. You can for example recursively search for something to pattern match on and transform in arbitrary ways.
The thing is, that it requires the developer to have some disciplin to divide view from the logic behind it. Simply make a folder called "templates" and put your Scheme files containing SXML stuff in there. For disciplined developers, this works well. In Scheme this works well, compared to for example PHP outputting HTML, because Scheme code in general has a tree structure already and as such an expression can be transformed into an HTML document. No need for any additional language like a templating language, but also not making the mistake to treat HTML as mere string, like PHP does.
JSX kind of treats its HTML-look-alike as a string as well, kind of. In the code you have a backstring wrapped string, which is processed later. There needs to be an additional parser for that, which performs the magic behind the scenes and checks the nesting of elements, allowing JS blocks inside that "template string". No such additional parsing is needed in SXML. Given the mere string before processing it into some internal tree, which is hidden away in the machinery processing JSX, I cannot simply transform the tree it represents, because it is merely a string. I would need to make use of JSX processing tooling, to get an actual tree and work with that. That might be possible.
The only advantage JSX has over SXML is not one, which stems from JSX itself, but from the fact, that JS runs in the browser and as such can run on the client side. If that were not the case, JSX would simply be worse in every way, forcing people to learn another language. Another language, because what one types in JSX template strings is not actual HTML, but something else, which has new rules about what elements exist, how elements can be structured, what attributes exist ("class" ...) and how elements can be nested, without receiving a type error. All that could be avoided, if we had something as elegant as SXML in JS. However, I am not sure, whether it is even possible to have something like SXML in JS. How would one go about quasi-quoting and unquoting? I don't know.
I would actually prefer to simply use JS objects to express the HTML document, so that I can work with them like with any tree. There could be magical attributes, which you can assign some closure to, so that it gets the dynamic behavior like in JSX. Not sure any framework has gone that way. It would be cleaner than inventing an HTML-look-alike and it would allow for more efficient processing, since it does not have to be parsed again, before outputting HTML.