Discussion on: [RELEASE] GlueDOM: JSX alternative to make non-trivial components easier to read and maintain

Let's maybe start by defining what separation of concern is. You seem to make the destiction based in what you consider JS and what you consider HTML. Strictly speaking, JSX is not HTML. It's a template engine. And a template has certain things it should "take care of" and things it shouldn't. And of course you can and should separate these concerns with React just like when using anything else. The only reason to argue for the "freedom" of mixing up business logic and templating is if you don't want to follow this separation.
What you consider "pseudo JS" in other frameworks is the binding between markup and JS. As a simple example:

...
const [val, setVal] = useState('')

return (
   <input value={val} onChange={ev =>setVal(ev.target.value)/>
)
...

Here our "HTML" binds to our state which is absolutely okay for templating and belongs there. The markup is a question of taste, of course, but nothing wrong with this.

...
return (
   <div className="some">
     {props.condition ? (
         const parseCondition = ()=>{
            // Let there be mess
            ....
         }
         ...
      ):null}
   </div>
)
...

In this extreme example we start mixing business logic and templating. And that will have issues with scope next to being a mess in itself. And I am sure you wouldn't write like that, bringing us back to the question: what freedom are you missing in alternative solutions?

JSX and other solutions need to be compiled. So wether or not business logic and template are in the same source file is again completely irrelevant from a functional perspective. It would just force clean code hence I would personally prefer it.
Linting is also completely irrelevant as all popular frameworks have a solution for popular IDEs (and only Vue when used as UMD would have valid markup without bundlers and IDEs taking care of things).

Lastly, being only concerned with one isolated UI component is not achievable in reality. At the end of the day, you will always have a page/route handling props, listening to events or passing down callbacks. Especially because we want to limit coupling separation of concern is so important.

Anyway, all if that doesn't mean that JSX isn't a nice solution. It just happens to be the worst when comparing it to Angular or Vue. And it is always hard to believe for me when people say they have spent extensive time as professionals with all these solutions and then say that JSX is most solid. In all honesty - and I really don't mean to offend - I tend to believe that either the complexity of the applications they built wasn't high enough or they are exaggerating the amount of time spent on different solutions.