Breaking the Web with hash-bangs
isolani.co.uk
isolani.co.uk
It's really highly annoying that this good old thing is now associated with flaming javascript evil.
So you need to do this if you want the user to be able to bookmark pages whose appearance depends on Javascript running. Think of it as the equivalent of "GET", but on the client - when the page loads, the Javascript reads what is after the # and re-generates the content.
Of course, that then breaks search and so you need #! which is a convention that allows server side code to give search engines the same thing that you are showing your user. But that doesn't mean that every use of storing client side state using # is automatically crazy or stupid or trivial to avoid.
Having said that, making a system that displays a blank page when Javascript fails is pretty dumb.
I can understand the technical necessity for them but I have no idea why you would want to redirect from example.com/foo => example.com/#!/foo -- do it the other way around instead and then the #! becomes a implementation detail of your internal AJAX-based navigation of your site rather than a public URL change.
Actually, for a company whose mainstream success can be mainly attributed to citations in newspapers and the media at large, I find it surprising Twitter chose such an ugly URL scheme due to the obvious difficulties in typing URLs you've seen offline that include #!-like warts.
What was wrong with twitter.com/username that hash bangs somehow fix?
In terms of just loading the ones page I don't see any reason why you couldn't use the normal structure and have js get what it needs for an ajax request from that.
The hash is actually an outdated method now, it's important to note. HTML5 introduced replaceState and pushState which allow rewriting the parts of the URL after the domain with JavaScript. So no more hashes in the URL except for page anchors.
That means there's no fallback for when the JavaScript breaks (which just happened) or for crawlers (except Google), browsers without JavaScript, etc. The site has absolutely no content without working JavaScript.
The author asserts that this also breaks caching. (AFAICT, more analysis would be needed to support this, because the extra request the JavaScript makes may very well be correctly cacheable.)