Gmail was probably the first very-widely-used app that used the fragment for navigation, and Google drove the whole #! thing.

That technique is now considered obsolete, with the History API (history.pushState and all that lot) having supplanted it. IE9 is the most popular browser currently in use that doesn’t support it; there are still definitely some systems out there that will use the History API if it’s available, or fall back to using the hash if it’s not, but I find that using the hash for navigation in deployed apps is surprisingly dead, given that it’s shy of six and a half years since IE10 came out, and Firefox and Chrome only had a year and two’s lead (and Chrome’s implementation especially was unreliable for quite some time).

Using the hash for navigation is still very common in development workflows. But that can be ignored for a feature like this.

pushState is bad for many use cases because it completely breaks linking.

It doesn't have to, if you also provide routes on the backend so that pushState URLs actually resolve to a real URL that serves the same content. Or just provide a wildcard route and use JS to detect the URL like you would with hash-based navigation.

It does require more coordination between the front and back-end though.

I meant using pushState using the state object for something other than caching. If I click on "About us" and this results in pushState({page:"about-us"}, "", "#") then linking just doesn't work any more. It's a regression back to the days of Flash.

Ah, gotcha. Yes, that's a truly awful way to use it.

You can go back even further. GWT (formerly Google Web Toolkit) uses the fragment to store navigation tokens. I actively maintain a GWT SPA in my day job.