| > So the stale API response, with the original names Mary, Robert, John is returned. This seems like a bug -- if you click back, it should take you to the page you saw before, not an earlier version of it. AIUI the bfcache doesn't "remember and replay" API requests; it just caches the entire DOM and JS state. Do you have something that can demonstrate this behavior? > Because single-page apps control "back" when in the SPA, they do what most developers want. They return to a semantically correct page, showing Mary, Rob (just edited), John. Tons of apps do this. This is not what the browser does. This is not necessarily what users want (as evidenced by discussions on this post). Many people want the old page, especially if there's information there (form fields, or other state) that might have gotten lost by a misclick. As someone else noted here, the "back = reload page" behavior can be emulated in the bfcache world by back+reload, but if you don't have a bfcache you can't emulate the "don't lose state" behavior that the bfcache gets you. It seems like a new meaning is being shoehorned into the "back" button, and then you're complaining it doesn't work. |
Apologies for using the wrong term and causing confusion.
> This is not necessarily what users want (as evidenced by discussions on this post).
HN not being representative of an average user aside, I don't disagree. My point is that there are two different expectations of what should happen and they can conflict and cause errors.
> you're complaining it doesn't work
I'm really sad you got that impression. I'm fascinated and think this an architectural problem of the web. My post is an attempt to describe the issue and raise awareness.