Not to defend the author's bad idea, but actually, the apps I've built with hash-based navigation would still work fine in the case you describe.
The server needs to be smart enough to read that hashtag and display the initial page in the correct state. It's just laziness to always load the same app and then immediately swap everything out based on hashes.
I prefer to send the page to the index before loading dynamic content. Imagine two scenarios:
I send a link to a friend saying "check out the kittens": <example.com/product/pr0n#/product/kittens> My friend ends up on a completely different page and there is no explaination as to why the page is wrong. Secondly, the URL leaked information about my browsing history. Finally, Google page rank goes to /produces/pr0n rather than the cute kittens.
If the URL is <example.com/#/product/kittens> then my friend sees the homepage rather than the correct product page. At least they'll know they're on the right site and can easily search for the correct page manually. Google page rank goes to the homepage rather than some arbitrary page.
- user with JS enabled opens the website and navigates to some inner page
- user with JS copies the url for the inner page (e.g. http://example.org/#foo/bar)
- user with JS sends this url to a friend
- a friend with JS disabled opens the url and does not get the inner page.
Also -- what if a search engine "bookmarks" the page and a user with JS opens it? Do you:
a) redirect him from example.org/foo/bar to exmple.org/#foo/bar or...
b) do you leave the url untouched and wait until the user bookmarks another page as example.org/foo/bar#foo/baz ?
a) -- you waste processing power on visitors from search engines.
b) -- you waste processing power on the next opening of the bookmark. Also this looks like a bug waiting to happen.
Disclosure: I browse with JS turned off (Firefox NoScript extension) and websites that rely on JavaScript when a static page would do annoy me.