It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:

So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

Mike goes into detail on the Gawker outage that was a direct result of its “sites” being little more than single pages that require JavaScript to access anything.

I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.

Though it may not seem like it at times, we’re actually in a pretty great position when it comes to front-end development on the web. As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible. There aren’t many other platforms that can offer such a robust level of loose coupling.

This is no accident. The web stack is rooted in Postel’s law. If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.

In fact, the most brittle part of the stack is JavaScript. While it’s far looser and more forgiving than many other programming languages, it’s still a programming language and that means that a simple typo could potentially cause an entire script to fail in a browser.

That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:

Responses

I’ve been doing a bunch of reading lately on hashbangs and why they’re terrible. For those not familiar, a hashbang is the “#!” you may have seen in URLs on sites like Twitter or the Gawker blogs. It looks fairly innocuous, if a little ugly and code-y, but in reality it’s a mess. See, what these two little characters represent is the destruction and destandardization of how web addresses should work.
I’m not going to go into the technical details about how a hashbang URL differs from a standard URL in terms of what happens behind the scenes, but suffice it to say there’s a lot more complication & things that can – and do – go wrong when those two symbols show up.
The thing that strikes me is the similarity between the arguments against hashbangs & the arguments against Flash. In both cases you have a technology for providing content to users that makes unreasonable assumptions about what their browser supports. Flash obviously requires a third party plugin which comes with its own set of problems, to include major security & performance flaws. Hashbangs aren’t in and of themselves the technology, but represent the heavy use of Javascript & AJAX which are not web standards, and have varying levels of support between browsers. It’s fundamentally bad practice for your site to require features your users may not have, and shouldn’t be required to.
Hashbangs go one step further in their damage-doing. Unlike Flash, which if it fails you can always fall back to HTML content, hashbangs prevent any ability to have a backup plan if the user can’t run the Javascript. Again, I refer you to the technical details on why this is, but the bottom line is it makes it impossible to do anything beyond scripting to load content. I have no problem with Javascript as a tool to create rich web applications & interfaces, but don’t make it such an integral part of the site’s structure that it can’t survive without the script. Again, it’s fundamentally bad practice.
Despite the fact that this is a horrible way to design a site to operate, we’re seeing some major companies implement it as a “feature” of their site. At least Twitter gives you to option to either use the site with hashbangs, or revert to the older version which uses real URLs. I’ll at least give them credit for not requiring it 100%. Gawker on the other hand doesn’t have any ability to browse their site in a non-hashbang method so far as I can tell, which really irks me. To compound the issue, they had a problem with their script which demonstrated exactly why this is such a flawed technique.
So, both Flash & hashbangs are not standards-compliant. Both have major weaknesses & make assumptions about the user’s capabilities. Both have serious stability & reliability problems. Both are also used in the name of a richer web experience which, with the advent of HTML5 and other technologies & best practices, can be accomplished in a more efficient & dependable fashion. I’m going to lump this issue into one term:
Flashbang Web Syndrome, the practice of a developer getting over zealous in their use of non-standard practices in the name of user experience, at the expense of long-term dependability and usability.
So, the next time you’re building a web product, make sure you build it on a solid foundation of standards & best practices, and don’t start throwing flashbangs at your users.
Share this postLike this:Like Loading…