On Gawker and Hashbangs

Gawker recently finished a transition of all their websites to a new design, and some of the technical decisions they made have upset web standardistas, the most prominent missive being this one by Mike Isolani, a Yahoo employee (all quotes in this post come from his essay). The complaints center around Gawker’s reliance on JavaScript to render the page and their accompanying use of the “hashbang” (#!) in the URL. There are a lot of valid concerns with the hashbang design, and specifically with the way Gawker has implemented it, but the complaints all miss or ignore one key fact: there is no other way to get the behavior enabled by Gawker’s new design.

The Bottom Line

The only way to achieve what Gawker’s new design does, cross-browser, is the way they’ve done it. There are ways to improve the design for newer browsers, but the foundation would still be what Gawker has implemented.

And despite what some are claiming, the design does more than just “look cool”; it actually enables behavior that many find useful and can be achieved no other way.

So why use a hash-bang?

Out of all the reasons, the strongest one is “Because it’s cool”. I said strongest not strong.

It’s an insult to the tech community that an article with this claim gained so much traction. Any web developer that truly knows his stuff will tell you what a hashbang-based, JavaScript-based site enables. In the case of Gawker’s two-pane design, it allows the reader to not lose his place in the article list as he reads through multiple posts. It also increases the perceived speed of the site, because jumping to a different article doesn’t refresh the whole page.

Let me give an example of a real world benefit. If you are anything like me, you visit the front page of a Gawker site (for me, it would be Kotaku) and you scroll through the list of articles, opening any you want to read in a new tab. Why? Because I don’t want to lose my place in the article list by clicking into the story, and I don’t want to have to hit the back button once I’m done reading that particular article. So after a few minutes I’ve got 10 tabs open, which starts to bog down my browser and eventually my whole computer. With Gawker’s new design I can scroll through the list, click on each article as I go, confident that I won’t lose my place in the article list. My tab bar stays sane and my computer’s fans stay off.

The Details

But what are the complaints of the web standardistas? Even if Gawker’s finds success with their “non-standard” redesign, should others avoid going down a similar path? Let’s evaluate.

• The site won’t work with JavaScript turned off.

Although it’s hard to find truly authoritative numbers, most reports indicate that over 98 percent of users have JavaScript enabled.

• The site won’t work if the JavaScript fails to load, or if there is a syntax error (such as an extra comma) in the code.

This is the biggest red herring of the bunch. Guess what? ANY website won’t work if parts that it relies on fail. Relying on the JavaScript to load is no more dangerous than relying on HTML to load. In writing about this, Mike and others make it sound like building a website that depends on JavaScript is akin to rubbing your lucky rabbit foot and putting on a blindfold before starting to code.

Every URL references the LifeHacker homepage. If you are lucky enough to have the JavaScript running successfully, the homepage then triggers off several Ajax requests to render the page, hopefully with the desired content showing up at some point.

He’s purposefully making it sound far brittler than it really is. This is like saying that when you visit a traditional URL, “If you are lucky enough that the server is running successfully, the request triggers several function calls, hopefully with the desired content being returned at some point.” The reality is that all web services are dependent on their constituent parts working.

I think part of the reason for this perception of JavaScript as brittle is that for a long time JavaScript was an “extra”, and so was coded by people who were not overly familiar with the language and was then either tested poorly or not tested at all, resulting in broken implementations. This led to the perception that the language itself was the problem.

• The URL looks ugly.

Here’s a Gawker URL under the new design:
http://gawker.com/#!5781440/the-latest-news-from-japan

And here is that same URL under the old design:
http://gawker.com/5781440/the-latest-news-from-japan

That’s all I have to say about that.

• HTTP/1.1 and RFC-2396 compliant crawlers now cannot see anything but an empty homepage shell.

This is a business concern. How important is it for your business to show up in search results? More specifically, how important is it for your business to show up in search results besides Google^[1]?

• Caching is now broken.

Another business concern. If your infrastructure can handle the requests without caching, then there is no issue. If it can’t and you want to have a more JavaScript-based approach, modify your infrastructure to support it.

• The potential use of Microformats (and upper-case Semantic Web tools) has now dropped substantially.

A real travesty.

• Facebook Like widgets that use page identifiers now need extra work to allow articles to be liked.

So you’re saying they still work? So what’s the issue here?

• Using cURL to retrieve one of the new Gawker URLs will not return the correct content.

Good thing I’ve got this here browser, then.

• The new URLs “don’t map to actual content”.

So, requesting the URL assigned to a piece of content doesn’t result in the requestor receiving that content

Actually, each URL does map to content. It just requires JavaScript to complete the mapping.

The Switch to Web Apps

Despite my flippant responses, the last two points bear further discussion. What’s happening here is that the web is evolving. Many sites are migrating towards a “web app” model, where the site operates like a self-contained application rather than a network of interrelated links. Along with that the browser and all its functionality, including JavaScript, are elevating from a GUI wrapper around cURL commands to an element of the web stack itself.

This change is making some developers uncomfortable. In their effort to explain their discomfort they are coming up with all sorts of rationales for sticking with older methods of web site design. Although there will surely be some bumps along the way, the reality is JavaScript is going to find its place as a standard, accepted part of the web stack. Other methods of retrieving web content will either have to adjust (such as Google’s efforts to index JavaScript-loaded content) or be relegated to secondary or special-purpose status, such as cURL.

Business on the Web

One last point I want to make. Even if Gawker’s new design truly was a catastrophe on the code side it could still be the right decision for them, because ultimately they are a business and their infrastructure and code choices should all be made in support of their business goals.

I think Gawker understands that they have to serve their users. From the user’s perspective a lot of these questions don’t matter. Who cares if the server parses the URL or the client does? Who cares if the parsing is done client side, or if the browser has to retrieve the content based on a URL fragment that it stored? That’s all implementation.

As much as web standardistas wish it wasn’t so, all these technical decisions (in a smart organization) are ultimately business decisions. Who cares if the design doesn’t conform to the W3C^[2] URL standard? The real questions are: How is the end user affected? Does it deliver a superior experience? Does it work for the audience Gawker cares about? Does it increase engagement? And of course the only question that really matters – will the design lead to increased profits? I can easily imagine that Gawker did an analysis and came away with the conclusion that this change would deliver where it really mattered.