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.
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.
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.
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.
- The URL looks ugly.
Here’s a Gawker URL under the new design:
And here is that same URL under the old design:
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 Google1?
- Caching is now broken.
- 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
The Switch to Web Apps
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 W3C2 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.
2. The World Wide Web Consortium, responsible for the standards on which the web is built.