Server side changes are moot (1), because in order to properly do state saving, you have to save more than the assets in a simple cache, but also the entirety of the DOM as of that particular moment and the state of the js engine.
I couldn't even imagine supporting that in an app I wrote, much less in a way that works for every website everywhere!!
(1) moot in the sense that it ought to act to server side changes much like any static pages would become out of date when backend updates are made. If the api endpoint goes away, then it errors, it's not the responsibility of the browser to keep the app evergreen, imho
> because in order to properly do state saving, you have to save more than the assets in a simple cache, but also the entirety of the DOM as of that particular moment and the state of the js engine.
Sure, it should do precisely that, IMO. Serialize it and dump it. All of this is in browser cache AFAIK anyway, so it's not like it's some completely novel programming exercise.
As for keeping up with the server side - I don't care. The "sync to the server state" button exists, and is called "Refresh" button. Nothing needs to be implemented by website author. In fact, I'd prefer if websites didn't have a say in this at all - or else someone will find a reason to screw with the mechanism.
I couldn't even imagine supporting that in an app I wrote, much less in a way that works for every website everywhere!!
(1) moot in the sense that it ought to act to server side changes much like any static pages would become out of date when backend updates are made. If the api endpoint goes away, then it errors, it's not the responsibility of the browser to keep the app evergreen, imho