Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.
As it is, there multiple browsers supporting different levels of features.
That's the whole reason why frameworks are made in the first place dating back to jQuery.
All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.
All it takes is one of those non majority use cases and you're going to need some kind of dependency to get things consistent
With React, you can make it work with older browsers using Polyfill etc.
Try using DOM APIs to build anything remotely complex or interactive. There's a reason everyone who only uses browser APIs ends up just dumping strings into the DOM via innerHtml.
I think the core question is: Are we building something complex or interactive. I don't see the need for React or other frameworks unless you're storing a lot of mutable states client-side. But more often than not, all I see is replicating the database through API endpoints.
More abstraction != easier to use.
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
> 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 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.
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.
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.
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.
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.
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.
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).
The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.
I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?
If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.
I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?
I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.
I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.
Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.
Guess what happened to development productivity and product quality? They went up dramatically.
I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.
Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.