The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less.
But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; JavaScript was for sprinkles of functionality.
So no matter how you spin it—each framework is a workaround making the browser do something it wasn’t designed for.
When I say that I don’t mean “abandon all APIs”—I’m just stating why things are so complicated in the web space.
Moral of the story—give us more static content please. “Dynamic” means ads and wasted CPU cycles.
Things change. Just because it was originally made for documents doesn’t mean that it hasn’t undergone such huge changes that it can literally drive FPS games at 60fps without a sweat. And I say that as someone who really doesn’t like many of the underlying abstractions, imo CSS+HTML are just thoroughly badly designed, none of them would be whole without the other resulting in extreme close coupling (layouting for example cannot be done without the other).
Also, should I really download a random exe to order a pizza? Plus, especially because the protocol is stateless a web app makes so much more sense (then replicating the state at the backend side).
Ordering a pizza can be done with static pages and some forms.
You want to make photoshop or a CAD program? That is an app. You want to order a pizza? Just use html and forms, maybe javascript to reload the progress page once per minute. (You don't need websockets or SSE or anything to check pizza progress)
Not everyone is a fan of throwing away secure sandboxed environment easily accessible apps run on to native applications that might not even be built for your OS.
None of what you have outlined is actually a problem.
If your requirement is to deliver an application to users on multiple platforms then a web application is a great target.
People complain about HTML, mean while new platforms (Swift, MAUI, Flutter) still design tree like documents. It's insanely fast, optimised, accessible and the tools are fantastic.
Frameworks don't change browser behaviour, they allow you to go up a layer of abstraction. Static content is great for static content. It would be a terrible fit for a rich text editor, a dynamic chart or anything that requires interactivity.
The ecosystem is great. Native applications can get you a more optimised experience at a cost. That cost is not worth it for many solutions.
Ads are on native compiled apps too, it has nothing to do with HTTP/HTML.
I’ve always been in favor of an entirely different file type, specifically for applications. Imagine if we’d just had something like .aml (application markup language). Then html could have stayed as a document format and we could have avoided all this nonsense.
I liked that react/jsx was born out of the web, and then influenced swiftui, jetpack compose, and flutter for a new way of writing application markup. I wonder: if not for the web and its pain points, would we have landed on similar patterns? Maybe.
Yes! This is the core problem due to the historical trajectory (browser invented for static documents, now being used to build applications) -- one that's no longer possible to sidestep at this point.
I believe there is a phrase "path dependence" to describe such situations.
But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; JavaScript was for sprinkles of functionality.
So no matter how you spin it—each framework is a workaround making the browser do something it wasn’t designed for.
When I say that I don’t mean “abandon all APIs”—I’m just stating why things are so complicated in the web space.
Moral of the story—give us more static content please. “Dynamic” means ads and wasted CPU cycles.