Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.
The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.
By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?
I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.
SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.
I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.
Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.
> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
I know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.
