We've had hashbangs in Unix for 30 years, and while they were not entirely perfect (bit of a violation of the kernel/userspace boundry going on; issues with suid), they've been good to us.<p>It's really highly annoying that this good old thing is now associated with flaming javascript evil.
Maybe I'm explaining the obvious here, but there is a reason people do this. If you have built your site so that the content is generated by Javascript running on the client then you need some way of making the page's current state visible so that it can be bookmarked. Without full adoption of HTML 5 that means you need to modify the URL. And the only part of the URL you can change without forcing a pageload is the part after the #.<p>So you <i>need</i> 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.<p>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.<p>Having said that, making a system that displays a blank page when Javascript fails <i>is</i> pretty dumb.
The purpose and meaning of the hash-bang convention is that there is a "real" url that corresponds to this "javascript" url. That has a lot of advantages that the post does not mention.