[bcyn]

I think you should be using `replace` more judiciously. IMO its primary use is redirecting from some kind of invalid state/URL, i.e. when the user does not want to ever go back.

For all valid states/URLs, users expect that the browser's back and forward button work as expected, and that they can save or send that link to others.

[lwansbrough]

I think you should be using push more judiciously. If I visit a site, click 3 buttons and blow up my back button so I have to hit back 4 times to get back to HN/Google, I'm not returning.

Users expect the back button to work for page transitions, not state/UI transitions. And again, this doesn't impact the ability to send the current page state as a link whatsoever.

[vercadium]

Thanks for taking the time to comment! I disagree with you on the history though. By the same token, a large portion of users would press 'back' to expect to return to a previous view, only to exit the site. If I land on a site from Google and click on 'About us', I expect to need to click twice to return. I think it's intuitive as-is.

For what it's worth, pure state changes (that don't occupy a page within the router) do use history.replaceState though.

I understand that this wouldn't be the case if I approached the design as per the rest of your feedback; placing a lot of this content within a single view could be done. However, the UI/UX is designed to be shallow, minimal and mobile friendly.

For example, while I could put weapon selection in as a filter and add controls to toggle between data views - creating a single powerful view - this doesn't actually accomplish much other than trading valuable space for increased UI complexity to avoid moving views.

Admittedly, I see this through a different lens as I'm aware of the amount of controls I need to somehow fit further down the line to support upcoming features. A desktop only site would be very different!

I appreciate your feedback; it's great to see things from another perspective.