There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page. The same would be true for multi-page apps using HTMX or Turbo or something - if you change pages without doing a full page load, you need to push your new URL. The guiding principle is that the browser back button should work as the user expects - you should only mess with the browser history stack to fix any nonsense you did to it in the first place.

▲

phkahler 6 hours ago | parent [-]

>> There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page.

No, You SPA should have it's own back button within the app. My browser back button should get me out of there no matter what.

	▲	creatonez 6 hours ago \| parent \| next [-]
		Then you lose the benefit of having the current URL actually linking to the resource you are currently viewing. If the app is not properly making use of URL modification and the history API, getting back to where you were requires navigating the whole maze each time.
	▲	SoftTalker 2 hours ago \| parent \| prev \| next [-]
		I use a couple of web apps that have this. It's frustrating, because muscle memory has me clicking the browser back button instead of the back button in the app. So that probably takes me back to the front page of the app, or out of it entirely, which is not what I wanted at all.
	▲	bevr1337 4 hours ago \| parent \| prev [-]
		How could the user expect consistent behavior from the back button if web apps can no longer leverage it like web sites?