5 ms·

There's a question I've had about htmx for some time, might as well ask it here. Why does it keep the history cache in localStorage and not sessionStorage or m

There's a question I've had about htmx for some time, might as well ask it here. Why does it keep the history cache in localStorage and not sessionStorage or memory? Some kind of a microoptimization? sessionStorage seems like it would be better to me if it's really a good default. I also think it should be publicized more, because it unexpectedly keeps stuff in a location that can be accessed more easily and beyond where the browser's back button cache can.

recursivedoubts 2y ago
memory wouldn't survive a page refresh sessionStorage wouldn't survive a tab close i'm not opposed to making the latter an option though
- benatkin 2y ago
  > memory wouldn't survive a page refresh That isn't very common. > sessionStorage wouldn't survive a tab close When a tab is restored, the browser typically restores sessionStorage. > i'm not opposed to making the latter an option though That isn't what I was getting at. If I'm going to buy into htmx, I want to understand the design. I wondered why this was the default, and why I hadn't seen it mentioned as a security concern.
  - esperent 2y ago
    > When a tab is restored, the browser typically restores sessionStorage Is it guaranteed to do this? Otherwise, if it just sometimes does it, or different browsers handle it differently/may change in the future, it seems like a recipe for problems.
    - hotpocket777 2y ago
      Not guaranteed, no. Thankfully. Chrome does, however, if the “resume where i left off” setting is enabled.
  - johnfn 2y ago
    A page refresh isn't common?
    - mrits 2y ago
      I'm wondering how they use this site
      - benatkin 2y ago
        I wasn't talking about Hacker News or lobste.rs :)
        gklitz 2y ago
        So you were only trying to say that page refreshed aren’t common on some subset of pages where it isn’t common? What’s the point of that argument. Also curious, why are you arguing so intensely for a “solution” that seems to only be worse and introduces issues as explained, without ever having stated any problem you are trying to solve with the change?
  - recursivedoubts 2y ago
    i don't know how common it is or isn't, but it's reasonably common for htmx to be sprinkled into a regular MPA with full page navs, etc. and memory wouldn't survive that no strong opinions on session vs local storage, i was trying to make htmx act as much like the browser as possible and the browser caches across tabs you can disable history on any page by using the hx-history attribute and you can force a server request on every history navigation by setting the htmx.config.historyCacheSize config option to 0: https://htmx.org/docs/#disabling-history-snapshots https://htmx.org/docs/#disabling-history-snapshots https://htmx.org/docs/#htmx-security-tools https://htmx.org/docs/#htmx-security-tools
    - benatkin 2y ago
      Memory would indeed be an issue for mixing MPA and SPA, but besides not being an issue for a full SPA it also wouldn't be an issue for sites that are all MPA except AJAX submissions that don't cause a SPA page change. Currently I think an all MPA would waste the localStorage space. SessionStorage by default with prominent placement in the docs would be better I think. It would automatically clean up the data from visitors' disk space at appropriate times, whereas the localStorage setting puts it in a place that gets persisted for quite some time. Thanks for those links, I've read them but it's good for others here to see them.
  - bdcravens 2y ago
    Maybe because I'm "old" and use browsers the way they were used when I first started using the Internet, but I refresh often enough that I'd quickly lose patience with an "app" that broke because I used a very basic feature of the web.
    - benatkin 2y ago
      If the site wasn't working it wouldn't break, it would download each page when you hit the back button. That would actually be a welcome result if I hit the refresh button wanting to make sure I was only looking at fresh data.
      - bdcravens 2y ago
        Any resource (ie page/URL) should function correctly with no regard to how that resource was loaded. That's the contract any server has with the client (browser), with no regard to what technology is being used to deliver the resource. If a website or application basically has to do the 2024 equivalent of "don't hold it that way", it's the result of a broken development model.
        benatkin 2y ago
        The correct function comes down to what the browser APIs say is valid in navigation. Both loading cached data and making the request again are valid. In the case of soft page navigation (onpushstate/onreplacestate) it's very clear that both are valid, as SPAs aren't expected to cache nothing, nor are they expected to cache everything.
        withinboredom 2y ago
        If I’m currently filtering some search data and hit refresh (or the browser tab went to sleep and wakes up, or restored after a reboot) I expect it to be in the same place without having to search and filter again.
        2y ago

recursivedoubts 2y ago

memory wouldn't survive a page refresh sessionStorage wouldn't survive a tab close i'm not opposed to making the latter an option though

benatkin 2y ago
> memory wouldn't survive a page refresh That isn't very common. > sessionStorage wouldn't survive a tab close When a tab is restored, the browser typically restores sessionStorage. > i'm not opposed to making the latter an option though That isn't what I was getting at. If I'm going to buy into htmx, I want to understand the design. I wondered why this was the default, and why I hadn't seen it mentioned as a security concern.
- esperent 2y ago
  > When a tab is restored, the browser typically restores sessionStorage Is it guaranteed to do this? Otherwise, if it just sometimes does it, or different browsers handle it differently/may change in the future, it seems like a recipe for problems.
  - hotpocket777 2y ago
    Not guaranteed, no. Thankfully. Chrome does, however, if the “resume where i left off” setting is enabled.
- johnfn 2y ago
  A page refresh isn't common?
  - mrits 2y ago
    I'm wondering how they use this site
    - benatkin 2y ago
      I wasn't talking about Hacker News or lobste.rs :)
      - gklitz 2y ago
        So you were only trying to say that page refreshed aren’t common on some subset of pages where it isn’t common? What’s the point of that argument. Also curious, why are you arguing so intensely for a “solution” that seems to only be worse and introduces issues as explained, without ever having stated any problem you are trying to solve with the change?
- recursivedoubts 2y ago
  i don't know how common it is or isn't, but it's reasonably common for htmx to be sprinkled into a regular MPA with full page navs, etc. and memory wouldn't survive that no strong opinions on session vs local storage, i was trying to make htmx act as much like the browser as possible and the browser caches across tabs you can disable history on any page by using the hx-history attribute and you can force a server request on every history navigation by setting the htmx.config.historyCacheSize config option to 0: https://htmx.org/docs/#disabling-history-snapshots https://htmx.org/docs/#disabling-history-snapshots https://htmx.org/docs/#htmx-security-tools https://htmx.org/docs/#htmx-security-tools
  - benatkin 2y ago
    Memory would indeed be an issue for mixing MPA and SPA, but besides not being an issue for a full SPA it also wouldn't be an issue for sites that are all MPA except AJAX submissions that don't cause a SPA page change. Currently I think an all MPA would waste the localStorage space. SessionStorage by default with prominent placement in the docs would be better I think. It would automatically clean up the data from visitors' disk space at appropriate times, whereas the localStorage setting puts it in a place that gets persisted for quite some time. Thanks for those links, I've read them but it's good for others here to see them.
- bdcravens 2y ago
  Maybe because I'm "old" and use browsers the way they were used when I first started using the Internet, but I refresh often enough that I'd quickly lose patience with an "app" that broke because I used a very basic feature of the web.
  - benatkin 2y ago
    If the site wasn't working it wouldn't break, it would download each page when you hit the back button. That would actually be a welcome result if I hit the refresh button wanting to make sure I was only looking at fresh data.
    - bdcravens 2y ago
      Any resource (ie page/URL) should function correctly with no regard to how that resource was loaded. That's the contract any server has with the client (browser), with no regard to what technology is being used to deliver the resource. If a website or application basically has to do the 2024 equivalent of "don't hold it that way", it's the result of a broken development model.
      - benatkin 2y ago
        The correct function comes down to what the browser APIs say is valid in navigation. Both loading cached data and making the request again are valid. In the case of soft page navigation (onpushstate/onreplacestate) it's very clear that both are valid, as SPAs aren't expected to cache nothing, nor are they expected to cache everything.
        withinboredom 2y ago
        If I’m currently filtering some search data and hit refresh (or the browser tab went to sleep and wakes up, or restored after a reboot) I expect it to be in the same place without having to search and filter again.
        2y ago