I don’t know about “easily.” replaceState() is actually intended to make single-page apps easier to use, by allowing you to use your back button as expected even when you’re staying on the same URL the entire time.
Likewise, single-page apps are intended to be faster and more efficient than downloading a new static page that’s 99.9% identical to the old one every time you change something.
Fixing this bad experience would eliminate the legitimate uses of replaceState().
Now, what they could do is track your browser history “canonically” and fork it off whenever Javascript alters its state, and then allow you to use a keyboard shortcut (Alt + Back, perhaps?) to go to the “canonical” previous item in history instead of to the “forked” previous item.
That would absolutely make everything worse, no question; the web should be more integrated, not less. We shouldn’t incentivize even more companies to silo off their content into apps.
Yes, I think you’re correct, but using browsers to coerce the web back into static documents will result in companies creating their own apps so that they can continue to deliver experiences. And the past 10+ years has shown that users will absolutely follow them.
Sorry, this comment was mainly just providing the previous user with a correction because they seemed to think that the other person that they were replying to was talking about forcing people to use phone apps, which I assume we all agree is bad and would likely work if there were a concentrated push for it.
Concerning your points after “using the browser”: I want websites to use replaceState and manage their own intra-page navigation with a cookie. They can still intercept the back button as they do now, but they should only get the single history entry until they switch to a new page, if they ever do.
I don’t know about “easily.” replaceState() is actually intended to make single-page apps easier to use, by allowing you to use your back button as expected even when you’re staying on the same URL the entire time.
Likewise, single-page apps are intended to be faster and more efficient than downloading a new static page that’s 99.9% identical to the old one every time you change something.
Fixing this bad experience would eliminate the legitimate uses of replaceState().
Now, what they could do is track your browser history “canonically” and fork it off whenever Javascript alters its state, and then allow you to use a keyboard shortcut (Alt + Back, perhaps?) to go to the “canonical” previous item in history instead of to the “forked” previous item.
Pop a window open with a your app in it (with the user’s permission) without a back button if you want that.
A web page should be a document, not an experience.
That would absolutely make everything worse, no question; the web should be more integrated, not less. We shouldn’t incentivize even more companies to silo off their content into apps.
I think the word ‘app’ was being used in place of ‘webapp’ there, which is the general target audience for this feature.
Yes, I think you’re correct, but using browsers to coerce the web back into static documents will result in companies creating their own apps so that they can continue to deliver experiences. And the past 10+ years has shown that users will absolutely follow them.
Sorry, this comment was mainly just providing the previous user with a correction because they seemed to think that the other person that they were replying to was talking about forcing people to use phone apps, which I assume we all agree is bad and would likely work if there were a concentrated push for it.
Concerning your points after “using the browser”: I want websites to use replaceState and manage their own intra-page navigation with a cookie. They can still intercept the back button as they do now, but they should only get the single history entry until they switch to a new page, if they ever do.