My perspective is that JSX is all that React has to offer. And lots of developers - myself included - were doing "JSX" a decade before React arrived. Because it, like, super obviously a good idea.
Angular doesn't separate concerns at all, it just ties it all together with an entirely new and un-intuitive DSL that you have to now write in the HTML.
Just look at your DSL here: https://angular.io/guide/binding-syntax#types-of-data-bindin...
You abso-fucking-lutely are writing code in your html, you're just writing a crippled version of their custom DSL instead of plain old javascript.
Frankly - I much prefer to write plain old javascript instead of learning a new bastard language that isn't useful anywhere else.
JSX achieves that relatively well. It's not entirely plain old javascript. But it's about as close as I've seen anyone get for a template language complete with data binding.
EJS https://ejs.co/ was my pick before JSX. For similar reasons - I don't want to have to learn a dsl which is just a shoddy wrapper for the JS anyways. Just let me write the damn javascript.
I’m very fricking close to this with web components and default Vite build. The only gotcha is having to bring along a few utility classes I wrote that glued it all together. Fewer than 40 lines.
Why is this important to maintain? People have been complaining about this since the beginning, but I've never seen anyone actually articulate what the problem is.
It seems to me that progressive enhancement was a genuinely great idea, but somehow the true concept got lost. Nowadays some insist it's ok to have a site that won't begin to do anything without JS, but at the same time it's not OK to mix JS into the HTML code. That somehow we're preserving the purity of HTML as a display layer just by putting it in a separate file.
Do not show me a UI if it doesn't work when I press/touch it. More, if I visit your site and your UI doesn't present itself within 1-3s, there should be some alternative UI presented that explains why (rather than just a white page).
So PHP?
Mixing html and code is a pretty old paradigm.
> 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.
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.
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.
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.
I disagree. I believe you're referring to the paradigm of mixing markup and code, which I never did.
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>);
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>That seems like arguing you don't need functions in your programming language and can simplify it by inlining everything.