[klabb3]

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.

[_heimdall]

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.

[klabb3]

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.