> If you need to persist past a reload then a few lines can save to localstorage.
Sure, and pretty soon you've got a dozen random little copies of bits and pieces of your state, all out of sync with each other.
> Anything more requires server-side calls anyway.
The issue isn't whether you need server-side calls (ultimately every webapp needs server-side calls, otherwise why would it be a webapp at all?), the issue is whether your framework can manage client-side state between those server-side calls. In theory you could create a server-side-rendering framework that was good at this. In practice, none of the big names has succeeded, and certainly not without significant costs. (I'd argue that Wicket does this well to a certain extent, but it comes at the cost of both relatively heavy server-side session state and significantly more network roundtrips than SPA style).
> This magical state that can only be managed on the client-side with a heavy SPA is a myth for 99.9% of sites.
On the contrary, 99.9% of sites have or could benefit from having some amount of client-side state. Any time you have a stateful UI, there's a usability benefit from persisting that. Any time you have so much as a form field - like the text box I'm typing in right now - there's a usability benefit from having that as managed state (I've lost comments because I closed the wrong tab or accidentally pasted over with something else), and in cases like this there would actually be a privacy concern with doing that on the server side.
In theory you don't need an SPA framework to do that. But in practice SPA frameworks are the only ones that do it well.
There's usability benefit in reloading to reset state and it's the common expectation when browsing. Regardless, if you do decide to add it then its a few lines of code to persist all forms on the page.
SPAs don't automatically provide any state management, and often the complexity requires even more work to manage forms. This is the complaint here, taking a simple requirement and forcing a webapp into it. It's completely unnecessary.
Many SPA frameworks do provide state management. If you start from the idea that you want structured client-side state management for your webpages, you'll probably land on an "SPA framework". And if you're using such a framework, while I'll always advocate things like proper URLs and history (which the framework should handle for you), forcing a page reload when it's not needed seems pretty wasteful.
Sure, and pretty soon you've got a dozen random little copies of bits and pieces of your state, all out of sync with each other.
> Anything more requires server-side calls anyway.
The issue isn't whether you need server-side calls (ultimately every webapp needs server-side calls, otherwise why would it be a webapp at all?), the issue is whether your framework can manage client-side state between those server-side calls. In theory you could create a server-side-rendering framework that was good at this. In practice, none of the big names has succeeded, and certainly not without significant costs. (I'd argue that Wicket does this well to a certain extent, but it comes at the cost of both relatively heavy server-side session state and significantly more network roundtrips than SPA style).
> This magical state that can only be managed on the client-side with a heavy SPA is a myth for 99.9% of sites.
On the contrary, 99.9% of sites have or could benefit from having some amount of client-side state. Any time you have a stateful UI, there's a usability benefit from persisting that. Any time you have so much as a form field - like the text box I'm typing in right now - there's a usability benefit from having that as managed state (I've lost comments because I closed the wrong tab or accidentally pasted over with something else), and in cases like this there would actually be a privacy concern with doing that on the server side.
In theory you don't need an SPA framework to do that. But in practice SPA frameworks are the only ones that do it well.