Comment by j-krieger
3 days ago
> The real question is, do we actually need "frameworks"?
Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
3 days ago
> The real question is, do we actually need "frameworks"?
Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
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.
It would be easier if "the browser" is just one target.
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.
The days of IE6 which justified jQuery are long gone.
All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.
3 replies →
> The discussion is whether or not we need a higher level API than that.
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.
> Try using DOM APIs to build anything remotely complex or interactive.
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.
1 reply →
„The browser“ doesn‘t exist. So no, we don‘t have one.
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
6 replies →
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).