That exists in every react app today so what’s your point? Are you arguing against it? If so, other than what I described (web components) how would you build a view? Web components or react components are supposed to be self-encapsulated so you can just add them to your view. Code and all. We are talking about view model code or presentation code.

I'm just saying that

> were doing "JSX" a decade before React arrived

is another instance of "rediscovering old paradigms". What I'm not saying is that this method of building a view is unnecessary, or wrong.

> If so, other than what I described (web components) how would you build a view?

There are many ways to create a view. Programming history is littered with them anywhere there's a UI to be created. Will they interact nicely with React? Probably not most of them, but it doesn't mean they do not exist.

More specifically, for the web. <script type="text/template"> arrived over a decade ago and it's taken us this long to get a <template> standard, let alone a document.createDocumentFragment(). These things take time. I know we are quick to adopt the good and then be shocked it takes so long for the rest of the world to standardize on, but it only reinforces what paradigms "work", and which ones don't by which paradigms become standards. Time will tell.

I don't think OP is arguing against "self-contained components" (with template and code), but about "presentation and business code mixed". I really like Vue's solution compared to React - the template is strictly separate from the logic driving the template. Same file, but seperate areas.

I've previously updated some components in a design system to Vue 3, where I followed the HTML results set by the React implementation. Reading the Vue 2 components worked almost immediately. The React components were so over-complicated that I sometimes literally had to follow the browser inspector instead of understanding every twist and turn in the code. I have never seen a Vue codebase that is as unreadable as the average React codebase with mixed business and presentation.

PHP? That's back-end (and fortunately I've never had to use)

I'm taking about HTML/JavaScript front-ends. The ideas behind JSX go back to at least 2004 when I first began using that paradigm.

Regardless of where it runs, the paradigm is very similar.

On a separate note, the attitude of "That's back-end" that permeates HTML/Javascript development is probably one of my biggest pet peeves; the disdain for what programming languages and GUI implementations have offered in the past hinders learning lessons from those implementations.

And that only holds us back.

"That's back-end" is how you can tell a good javascript dev from a bad one. A bad one doesn't know where the express/bun line ends and the browser begins. Be glad.

Also, GUI development has traditionally been a shit show. From Qt/WinForms to WPF to now using Web tech because the whole industry threw up their hands. There's MVC, MVVM, MVP, you name it to describe a proper UI->data relationship and all have failed to breach the boundary of their domain. Components, like ECS in game dev, are one way of solving this issue. Because we have to separate our markup from our logic we have JSX. I really wish I could do something like:

    this.view.set(<div></div>);

but the reality is this. If you're developing a UI using code, you don't need markup at all except for the specific element/display you are representing. Almost all of my webcomponents are just a div in a document.createElement and the rest is built up using the same. document.createElement. It's tedious, it's error prone, which is the argument for JSX. I don't need to create a Nav component and a Nav Bar component and a Nav Item component and a Nav Menu component, etc. I can just create a Nav Component and handle it all from there, simplifying my UI view code.

In the end, all of these work arounds are simply because we have to deal with the final product, html and we (myself included) get stuck behind the default tags because thats what we know. We don't need any of it. Define your own. Treat the page like it's one giant empty xml document and everything's derived from a div and see if the browser treats it any different. It doesn't. So your entire body could be made of:

    <article>
       <post>
           <post-title/>
           <post-author/>
           <post-body/>
       </post>
    </article>

> I don't need to create a Nav component and a Nav Bar component and a Nav Item component and a Nav Menu component, etc. I can just create a Nav Component and handle it all from there, simplifying my UI view code.

That seems like arguing you don't need functions in your programming language and can simplify it by inlining everything.

IYKYK, some cough frameworks cough have this idea of nesting nests of nests in order to have proper look and feel. I won't name names, but it became something people got used to and it's horrid. One or two parent->child stylings is one thing, but the aforementioned framework had up to 8 in this Nav functionality.

> the paradigm is very similar

I disagree. I believe you're referring to the paradigm of mixing markup and code, which I never did.

PHP is how I'd describe Astro.