> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument
To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.
Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.
Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.
For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.
I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.
How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.
Yes and for those cases it’s kind of already solved decently like with htmx or just plain old forms and post requests. I think those old ways are underrated.
But, for a chat app it isn’t gonna cut it. Or a collaborative app, where changes need to be pushed to the client. Or maps, or similar. Or anything which needs offline working. (I’m working on a desktop app where majority of state is owned by and lives on the client.)
TLDR I agree for passive web pages but the web is often more than that, many times for good reason.
Not sure if its an unpopular opinion here, but in those kinds of cases I think browsers are just a bad deployment target for the problem.
Dealing with cross-platform issues and app store policies can be frustrating, but the web was fundamentally designed for documents and it just doesn't lend itself well to complex, mostly or entirely clients side apps.
It’s not unpopular, I see it as the majority opinion on HN. It’s based on skepticism against web in general, and outright hatred for electron (which is at least somewhat justified).
My app is 11MB bundle (most of which is an unrelated native extension) on most platforms, and has complex stateful business logic and views. It performs mediocre only on Linux due to lacking investment in webkitgtk.
> the web was fundamentally designed for documents
And yet it successfully penetrated the application server market, which it (JS) was never designed for. Stateful apps are much closer to the original design. The gap is essentially a few enumerable pain points that get smaller every year. Most importantly though, the only other toolkit supporting all 3 desktop, 2 mobile and web is Flutter, which is proprietary and entirely downstream the goodwill of a mega-corp.
To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.
Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.