JavaScript and URLs

28 Feb 2011

I like the Web. It's simple, open, and accessible. It's robust. It's also inherently altruistic; every link gives, and links are what ties it all together.

People have always used the Web in their own way, and this is partly what makes it great, but sometimes people don't seem to appreciate the Web for what it is — and what it isn't. Some people just don't get it.

For years, one of the telltale signs of not getting it has been using Flash as a substitute for the Web. By delivering Flash over HTTP and extending browsers to run it, it's easy to overlook the fact that Flash is a competitor to the Web, not a proprietary part of it. (Being a competitor isn't a bad thing, but it is what it is.) Flash sites are dying, partly thanks to Apple, but a new bad practice is emerging.

Except it's not new. It's as if a bunch of people got together and decided that the problem with Flash sites is the technology, not the use of it. Everything I used to hate about Flash is back, this time in the form of JavaScript. Like Flash sites, there is a new breed of web apps that don't feel quite right. Maybe it's because they scroll like a supertanker. Maybe it's because the back button doesn't work right. Maybe it's because the browser tells you it's done, but you don't see any content. (I'm looking at you, Twitter.)

I think all of these things are just symptoms. Some solutions already exist. Remy Sharp teaches us how to enable the back button. Ben Cherry gives us a saner HTML5 history solution. Mozilla explains how to manipulate the browser history. Google provides a solution for making your Ajax apps crawlable.

I think Simon Willison comes closest to describing the fundamental problem:

The Web for me is still URLs and HTML. I don't want a Web that can only be understood by running a JavaScript interpreter against it.

Many others have weighed in on this conversation. Here are a few posts that have caught my eye:

Thoughts on the Hashbang
Ben Cherry makes the case for web apps versus web sites, arguing that the former deserves some leniency, because URLs are a legacy of web sites. He also makes the case for web apps being faster, more seamless, and much better. Using his distinction between a web app and a web site, I have a hard time agreeing with web apps being better. I do agree with his assertion that the debate should focus on the merits of these types of web apps and not just the use of the hashbang in URLs. (It's still a relevant talking point, but it shouldn't be the focus.)
Breaking the Web with Hashbangs
Mike Davies points out many problems of this new breed of web apps, with a focus on fragility, using Lifehacker's outage as a timely example. The caching of web content is a bit more nuanced than he suggests, but I agree with the thrust of his argument.
Going Postel
Jeremy Keith focuses on the Web's history of adhering to Postel's Law, which says to be conservative in what you give and liberal in what you accept. This is one of the reasons the Web is so robust, and it's one of the fundamental principles being abandoned in this new breed of web apps.
Broken Links
Tim Bray breaks down the technical details of hashbang URLs for anyone who would like to know what all the fuss is about. He also asks a good question: "What is the next great Web app that nobody's built yet that depends on the simple link-identifies-a-resource paradigm, but that now we won't be seeing?"
Hash, Bang, Wallop
Ben Ward gave us the excellent rule of thumb that if site content doesn't load through curl, it's broken, and this post offers a much more complete viewpoint. I like his description of hashbang URLs as a client-side routing pattern. (That's exactly what they are.) Because of his careful dissection of some of the arguments being made, this is probably my favorite post on the topic. If you read nothing else, read this.

What do you think? Is this just an awkward phase during a period of necessary evolution for the Web? If so, it sure is a bumpy ride.