I think maybe you're misunderstanding what I meant by fragment based navigation – that's probably my fault. I refer to the shebang style fragments, that was used to implement deep linking in primarily JS driven sites. This of course watered down the use of fragments in pages, and nearly made them useless frankly. Ironically, the history API – which of course as you say requires JS to work – is what probably saved fragments from being completely useless, since it meant everyone could return to using paths for deep linking and still implement their sites as JS blobs if they so chose. Moreover it opened up for hybrid approaches, where the server can actually serve a pre-rendered site that's then amended by JS (or not!) since the server would now see the full path that users were navigating to, as opposed to /my-catch-all-entry-point. Servers never get to see the fragment, after all.
the issue is that your server now needs to somehow understand which part of the path is the "fragment" without any distinguishing characters by which to parse it out of the url.
if the server now sees deep urls like `/products/patagonia/parkas`, how does it know which part is the fragment? is it /parkas or /patagonia/parkas? what if you have urls that are not completely uniform? or have different uniformity at different prefixes?
the router needs to be more complex. but i agree that the history API has advantages over shebangs for deep app links.
Point isn't so much that the server needs to do anything, you can still just serve up the same response no matter the path, and have the client render different results – just as you would with a shebang style navigation in the past. The difference is that you know have options, which you didn't before since the server never saw the fragment part of the url, only / or /entry-point or whatever. So you can have more complex logic server side (really, this was done in the past long before in-client routing was a thing) but you don't have to, it can still be deferred to the client to deal with. Using shebang style navigation you never even really had the option – the history API enabled this.
Lots of (mostly free) hosting just serves the files you upload, so that wouldn't work unless you copied the files to be served at every possible route.
“#” Fragments aren’t sent to the server at all. They are ONLY used to get to a specific anchor (old school) or processed by JavaScript to do something (often fake navigation by showing and hiding content). This article is adding a 3rd magic use for them.
Yeah, I know. Parent was saying that the History API doesn't need any server support, because you can just serve the same file no matter what the subpath, but my point is that lots of servers don't even have support for that. That's why the fragment is still more useful than the History API in some cases.
Fair point, thanks for adding this perspective! I of course assumed there was at least a modicum of control over this server side but as you correctly point out if there is no such control then shebang style navigation is your only option if indeed you must do client side routing. I once abused custom 404 pages (I think in GH pages, but it may have been some other free host with similar functionality) in order to achieve this kind of behaviour. It was just a demo so didn't matter much, but of course this is far from ideal for anything else.
