There’s been a lot of discussion this week about the “hashbang”, that ugly little bit you find in the middle of URLs like this one: http://twitter.com/#!/ded/status/18308450276. I wanted to provide a rebuttal to the arguments that the hashbang is bad for the Web, based on a lot of discussions we’ve been having inside Twitter since the #newtwitter project began last summer, and have continued right up until today.
It’s Not About the Hashbang
The hashbang is in the unfortunate position of being the messenger of a big change that’s been slowly occurring on the Web in the past few years, and will only continue to pick up steam: many Web domains are now serving desktop-class applications via HTTP, instead of traditional Web sites. For instance, twitter.com is no longer a collection of Web pages that represent a Web site, but is simply an application that you happen to launch by pointing a browser at http://twitter.com*. This has many wide-reaching implications, and the hashbang is merely a side-effect. In this way, the hashbang is an easy-to-hate straw-man, whereas the real debate to be had is about this shift towards applications.
Why Applications on the Web?
Services such as Twitter, Flickr, Facebook, and others have every reason to build rich applications. An application allows an experience that is faster, more seamless, and much better for users than traditional Web sites. However, we do not have to choose to host our apps on the Web, and could easily use other options, such as building a native OS application, or using another cross-platform platform such as Adobe AIR. We all choose Web applications however, because the Web is ubiquitous, well-understood, and mostly superior to other application delivery options.
We get URLs in our Web applications as a legacy of Web sites, and this feature is unique to this class of applications. The power of URLs bring benefits like bookmarks, sharing of application states for free, and search engine indexing. Unfortunately, supporting a standard URL structure for this type of application is not possible in current browsers, without using the URL hash. So, we use the URL hash to take advantage of this sort of thing, but not because we believe our application to be a traditional Web site. We do lose indexability and some other benefits of HTTP we may otherwise have, but these are not losses to our application, since we did not have to use a URL at all. Google has thankfully provided an implementation for crawling applications, based on the hashbang, which brings search engine indexing to the URL hash, and is easy enough to implement.
There is hope on the horizon, in the form of the HTML5 History API. This new browser feature will allow developers to change the entire URL path and query string without incurring a page refresh. By using this, we could drop the hash, and get all the benefits of traditional Web sites with all the benefits of a desktop-class application. Support for this has been in Chrome and Safari for some time (albeit with a bug we found (now fixed)), and will arrive in Firefox 4. Internet Explorer currently has no plans to implement this in IE9, which is a shame. Had it not been for the bug we found, we would have shipped #newtwitter with HTML5 History on day one (and in fact, the integration is already built).
The Hashbang is a Good Thing
It’s not perfect. It’s not pretty (despite what Google says). But the hashbang is useful. Users benefit from the trend towards full-fledged applications, with increased speed and functionality. URLs are not necessary in this context, but we provide them (via the hash) because they bring tangible benefits for applications. The hashbang also brings a tangible benefit. Someday, we will hopefully be rid of the thing, when HTML5 History (or something like it) is standard in all browsers. The Web application is not going anywhere, and the hash is a fact of life.* Technically, twitter.com does still host a Web site. For instance, twitter.com/jobs is a normal Web page, as is twitter.com/bcherry when viewed logged-out. We have, however, begun serving an application to logged-in visitors.