Also that's why single page applications are no longer technically single page.

    https://example.com/#!/
    https://example.com/#!/about/
    https://example.com/#!/users/

Are all the same page as far as the browser concerns, and if you move from `/#!/` to `/#!/users/`, and reload the page, you still load the same page (i.e. `/`).

But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like:

    https://example.com/
    https://example.com/about/
    https://example.com/users/

Sure, if you load `/` and move to `/about/` you don't load a new page because of browser history APIs; but if you then refresh, now you load a different, uncached page (`/about/`, instead of `/`) even if the HTML in the response is exactly the same as in `/`.

Sure, the difference is not much, but to me it still seems like a waste when the response could have been cached already like in the first example.

> But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like

Would back/forward buttons continue to work if we decided not use browser history APIs?

Yes, and a quick test with Mithril.js confirms it.

I could try with something like React, but that's too much for a quick test.

Mithril.js also probably uses the history API?

.replaceState() will replace current url without putting it in the history, so back won't work, while .pushState() does.

The other poster is wrong, the entire reason the history API exists is specifically because when these SPA frameworks first came onto the scene one of the things that was broken was history.

So they invented the history API's so SPA's could stop breaking some of the user expectations they were breaking.

The first one always requests / from the server when landed on/refreshed. The other one does not. This fact can be acted upon.

What does the ! symbol do in url fragments?

It was part of a scheme to make SPAs indexable by search engines. Google deprecated it back in 2015, as Googlebot can now execute JS.

https://developers.google.com/search/blog/2009/10/proposal-f...

That issue can be solved with service workers.

The real reason for moving (back) from fragment URLs to real URLs is because the latter can serve different content on the initial load - specifically, they can act as actual webpages that use javascipt for progressive enhancement but work immediately whereas your / needs to display a spinner while you send of additional network requests to retrieve the content and build the page.