Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.
More abstraction != easier to use.
Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.
> HTML, JS, and CSS deliver a clean separation of concerns
There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.
> For apps,
For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952
>> HTML, JS, and CSS deliver a clean separation of concerns
> There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.
It's very clean and something repeated by almost every UI framework and document system. The separation is between structure, style, and interactivity. Most web apps actually fits the document models where you have content pages and forms. But people wants to bring desktop and game UI patterns into that. And make it a mess.
> It's very clean
It's not
> something repeated by almost every UI framework and document system.
That is, hardly any UI framework separates these things. From Windows APIs to SwiftUI there's rarely a system which tries to separate these concepts. Because however hard you pretend they are separated, they never are.
> Most web apps actually fits the document models where you have content pages and forms.
Even in a document your styles are linked to the structure of your document.
> Because however hard you pretend they are separated, they never are.
That would hold true for whatever systems. The pretention is just for making it easier to do the job without extraneous effort. Cascading is a nice pattern for applying properties in the case of a document. JS was originally intended for scripting (not for full-blown application) and the DOM API works fine for that. Without that, we would have to put everything in HTML or have something like Flash.
> That would hold true for whatever systems.
Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
And now it's "they are never separated, and this holds true for whatever systems"
> The pretention is just for making it easier to do the job without extraneous effort.
In reality there's a lot of extraneous effort especially when systems become more complex. BEM was invented not because CSS was great and amazing at reducing effort, but because it was adding a great amount of effort for a very large number of designs.
CSS Scoping was finally, thankfully, added not because cascading nature of CSS reduces a lot of effort.
The rest of your comment has nothing to do with what I said.
> And now it's "they are never separated, and this holds true for whatever systems"
What I described as separation is a a decomposition into modules which are linked together through a contract. CSS has cascading and selectors, while JS has the DOM API. Otherwise, it would still be attributes on tags.
BEM is just a development technique, not a technical requirement or capability. Without cascading, we would probably have components and inheritance.
> Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
On Android and iOS, you have XML for layout. QT and GTK have support for CSS like styles. I remember at least one of the have supported XML for layout definition. They're not required, but they make it easier to build the UI as it almost always have a tree structure.
> What I described as separation is a a decomposition into modules which are linked together through a contract.
wat
> Without cascading, we would probably have components and inheritance.
indeed. That is why I wrote what I wrote about BEM and CSS Scoping
> They're not required, but they make it easier to build the UI as it almost always have a tree structure.
Those systems have support, but there's rarely, if ever, a true separation of styling and structure. There's a reason for that, illustrated here: https://x.com/simonswiss/status/1664736786671869952
The separation between CSS and HTML is a good idea in a very theoretical abstract academic sense. It never ever worked in practice.
Your comment shows that you don‘t have a lot of experience in that matter. „Pure JS“ (there is no such thing) has perhaps the tiniest standard library of anything out there. The rest is browser vendor code, of which a lot depends on browsers and versions. Hell, they didn‘t even get date parsing right.
"Pure" JS exists as a concept, not a project.
Having a tiny standard library is also a good thing, not a bad one... I'm not saying its an ideal API but in general, smaller==better (within reason).