JSX isn't really an abstraction over HTML, it's an abstraction over document.createElement and the other related DOM APIs. I always liked it because that's really what is happening, JS is causing HTML elements to be created via those APIs. We aren't feeding the browser html files for it to parse.

The only bizarre thing is the HTML was ever separate from JavaScript in the first place.

How is that bizarre? Trying to enforce MVC is done even when it is a lost cause.. But you properly separate html, css and (arbitrary Code language to be replaced by transpiling) and all you hear is "I wish my graphic artist had to understand all of this and what a compiler does before he could fix my poor UX ideas.. and my copywriter should have to find my spelling mistakes using an IDE too."

If my graphic artist expected me to go into Adobe every time I needed a new background, I would ask him what his job was.

It sounds like you're coming from a landing page/blog/Wordpress background. I'm primarily building data-driven apps, like financial data or dashboards. My UX/UI people don't come near my code, and I wouldn't want them to.

For me, every time I need a new button, I'm not going to my designer, I'm just copying over the last button. So I need to be able to quickly edit styles, and state functionality, like dropdowns and date pickers. For these types of components, your life will be a living hell if every time you needed to add a style, you were going to a CSS/HTML file. This was how we first worked with Backbone and Handlebars, and it absolutely sucked.

I see just enough of landingpages and corporate customers and multilingual to see why most of these frameworks ship with toy features when it comes to the lifecycle of the overall site. Then you end up with two parts (a site in so.e kind of CMS and a compiled SPA) that have to look kind of alike where they can only sort of edit one..

Handlebars is just a general text template language so it was naturaly quite rough. From there one can move to dressing components in the angular style and keep the templates all in one folder and the custom CSS in one file.

My designer and I share the templates folder, I usually add enough attributes for bootstrap to do something or other and then the custom CSS is his and the code is mine.

If we were writing our SPAs for consulting clients it would be essential that the templates and CSS were not compiled so they could go on with them without us and without either paying us to keep a bunch of unstable node tooling able to compile and up to date or feeling like we intentionally snuck a time bomb into the project and are underhanded in seeking hours.

That's probably because HTML came first, and the web was meant to be a document sharing platform, not an app environment for everything under the sun. Anyway, people were mixing the PHP with their HTML long before everything got rewritten in JS. The whole argument over what constitutes proper separation of concerns probably proceeds Smalltalk and MVC.

> the various debates around web components and shadow DOM isolation get sorted out.

They won’t. jQuery was a much simpler concept and basically a fluent wrapper around a lot of existing APIs.

11 years later none of the browser APIs are not nearly as easy to use or powerful as jQuery. (Did you know that querySelectorAll returns an object that, unlike jQuery, isn’t an array and doesn’t have the same APIs? They added frigging .forEach to it only a few years ago).

Components are a more complex concept. You need data binding, and virtual DOMs (to prevent out-of-order janky updates to the DOM), and templating, and a solution for both global and isolated CSS, and..., and..., and...

These issues won’t be solved in the next 50 years. And that’s the reason no one uses (or talks about) vanilla WebComponents. Everyone is using any of the dozens of wrappers or frameworks on top of them.

Edit: added missing not in not nearly as easy