5 ms·

That's an extremely difficult problem for browser makers to solve in a generic way: the state of client-side scripts might not lend itself to such a snapshot, a

That's an extremely difficult problem for browser makers to solve in a generic way: the state of client-side scripts might not lend itself to such a snapshot, and the browser has no way to account for changes that have been made server-side in the meantime (including new versions of the page content, scripts, stylesheets, API endpoints, etc.). Your proposal reminds me of Java object serialization, which I've rarely seen used in an effective way (and only when the code and runtime environment are tightly controlled). Webpage makers already have the tools they need to do this: the page URI can be manipulated client-side to store state. And they can specify which content should be cached for use in the future without a trip to the server—including full client-side app functionality.

julianlam 7y ago
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
- TeMPOraL 7y ago
  > 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.
- pierrebai 7y ago
  I'ts not hard to do because it's already done. Firefox will show the previous contents of tabs in place when you update firefox live. So it must already have that ability.
Mirioron 7y ago
If the server side has changed then I can simply refresh the page if I want the newest page. I'd like the page to be exactly what it was when I closed the browser. I've left computers running for days just to save the state of a single browser tab. I suppose a better way of doing it is to only use browsers inside a VM and them just save the state of the VM. About websites: I don't want to have to rely on website makers, because they invariably won't do it and it won't work.
Shorel 7y ago
> and the browser has no way to account for changes that have been made server-side in the meantime It doesn't matter. Store and index what I read. Content could be destroyed and altered in the server.
- organsnyder 7y ago
  That only works if the page is relatively static. Add in any functionality that requires a round-trip to a server, and things get immensely more complex.
  - TeMPOraL 7y ago
    No, they don't. There's a benefit in being able to snapshot the current state of a dynamic application.
    - organsnyder 7y ago
      But what happens when you want to meaningfully interact with it? It seems kind of useless to me if things are broken the instant I try to do anything.
      - TeMPOraL 7y ago
        You can press the Refresh button and suddenly things fix themselves. The utility is in having a snapshot of the site looking exactly as when you left it, with all the benefits of it not being rendered to a image, and with a high probability that at least some interactions still work.

julianlam 7y ago

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

TeMPOraL 7y ago
> 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.
pierrebai 7y ago
I'ts not hard to do because it's already done. Firefox will show the previous contents of tabs in place when you update firefox live. So it must already have that ability.

Mirioron 7y ago

If the server side has changed then I can simply refresh the page if I want the newest page. I'd like the page to be exactly what it was when I closed the browser. I've left computers running for days just to save the state of a single browser tab. I suppose a better way of doing it is to only use browsers inside a VM and them just save the state of the VM. About websites: I don't want to have to rely on website makers, because they invariably won't do it and it won't work.

Shorel 7y ago

> and the browser has no way to account for changes that have been made server-side in the meantime It doesn't matter. Store and index what I read. Content could be destroyed and altered in the server.

organsnyder 7y ago
That only works if the page is relatively static. Add in any functionality that requires a round-trip to a server, and things get immensely more complex.
- TeMPOraL 7y ago
  No, they don't. There's a benefit in being able to snapshot the current state of a dynamic application.
  - organsnyder 7y ago
    But what happens when you want to meaningfully interact with it? It seems kind of useless to me if things are broken the instant I try to do anything.
    - TeMPOraL 7y ago
      You can press the Refresh button and suddenly things fix themselves. The utility is in having a snapshot of the site looking exactly as when you left it, with all the benefits of it not being rendered to a image, and with a high probability that at least some interactions still work.