Whoops and hashbangs

Three people in the last week have told me I should be blogging more. Flattered, and probably more helpfully than leaving nuggets of half-baked comments on everyone else’s, I’ll do my best.

I dust off the cobwebs by apologizing for a tweet in which I misattributed Scott Jehl. No thanks to strange avatar positioning, I thought he’d made a provocative comment about the destiny of URLs on a post about everyone’s favorite topic, the hashbang.

(Hopefully I’m not the only one who can barely see #1e1e1e on #141414)

It did sound out-of-character from a champion of jQuery projects, and perhaps I was tempted to acknowledge the comment because it seemed such an extreme position from him. Sorry Scott!

But onto the comment itself. Why did I take a shine to it? It certainly takes a provocative stance.

“We are long past the point where URLs have any utility” is strong language. I of course enjoy the benefits of links and URLs myself every day, and I’m sure the commenter does too: bookmarks, links, emailed or tweeted, the ability to return through a browser’s history, open new browser tabs with target content and so on. All very useful. All very cool.

But does this mean that the URL is so sacred we can’t discuss its role and relevance in the real world? Think about whether it’s actually doing its job? Wonder whether it’s productive to shield it from the creative ways in which the web is evolving? And, as this commenter did, consider whether search engines are in fact coping with these changes effectively?

(Heretical to most people… but the sort of thing I like to think about – probably for that reason, actually. And what else are blogs for, anyway?)

So, yes, yes; URLs are used as a key for locating documents and resources across the web. That is all well and good. But I’m thinking; what happens when the web hosts things other than documents and resources? Like applications? Like games? Like physical objects? What happens when we need to serve humans based on other signals, such as their location, the time of day, their context, their intent?

It might just be possible, as the commenter asserts, that a single string-based identifier is not, in fact, sufficient to describe the infinite things that a 21st century, multi-dimensional web can do, offer, and represent.

I’m not completely sure. But I am convinced (and excited) that the web is evolving in these sorts of ways. Client-side applications, for example, seem to be a perfectly valid and compelling architectural way to use web technologies. And yet what role does the URL play there? Obviously as an entry point to the app as a whole, but then what? Does Tim Berners Lee’s plea require me to use a URL to describe every possible state, every view and every data point within it?

Documentistas would have it so. I can’t possibly build anything for the web without every piece of it being addressable like a document. Users must be able to deep-link into any docu state of my application. These URLs must return content to robots too – because where would we be without web crawlers? – and of course it all needs to degrade nicely for legacy browsers and screen readers. In fact, I may as well just fake the whole thing with server-side markup and progressive enhancement anyway. Many do.

But if I’m an applicationista, I create true client-side web applications, probably programmatically. I use little, if any, content-bearing markup, and I provide a suite of complex functionality to users, and pull in content from server- or cloud-based APIs in my own particular way. I acknowledge that my application needs to be accessible somehow, but in the corresponding state machine, the concept of a linkable document can quickly become tenuous, if not entirely inappropriate. Yes, I could conceivably use URLs to describe the finite states of a game of tic-tac-toe. But is there a http://angrybirds.com/level4 ? Or a http://angrybirds.com/level4/just-before-the-red-bird-hits-the-big-block ? Not that I know of.

If this web of applications is our new operating system, I see URLs as our command line switches. They can open apps, and sometimes drop you into well-understood states within that app. But by no means is the developer obliged to let any user reproduce any arbitrary state within it. A desktop developer can choose to let users launch a classic native application with certain pre-defined states – start this tool with a particular file open, for example – but does so in a very controlled and discoverable way. No native OS I know mandates that an application’s command line switches must be capable of describing all of its possible states. So why should the web?

In reality, certain web apps will benefit from deep-linkability, but many do not at all. And just because a large part of the web (the documenty bit) holds URLs self-evident and axiomatic might not mean that a different, growing part of the web (the applicationy bit) must do so too. Nick Morgan, admittedly opining on a subtly different topic, states:

The problem is that because everyone building stuff online is using the same technologies, there can be a tendency to think that there is one true way of using those technologies, independent of what they’re being used for.

And this is the crux. We might all be using web technologies (HTML, JavaScript, CSS and the like), but in radically different architectural configurations, and best practices for some may not be good rules for others. What this touches on might be the primary root cause of the hashbang debate (if not also others): the web is being used in challenging and unexpected ways and we’re finding it hard to re-examine practices and principles that were intended for a different age.

Yes, hashbangs are ugly. A hack. Sometimes they’ll need to be replaced with judicious use of the HTML5 History API. But other times they’ll need to be removed altogether: “it depends“.

But I believe that their usage – and the debate that has raged over that usage – tells us more about the culture of the web and those who create things for it than it does about syntactic purity or semantic elegance. It has shown us that we still find it hard not to think about the web in terms of documents, and that a web of applications can seem strange and opaque. And maybe that we are in a tighter symbiosis with search engine crawlers than we’d like to admit. Is that really what is meant when we’re told we risk breaking the web?

(It might be no co-incidence that our greatest cognitive dissonance occurs when we see something that probably should have remained document-based turned into an application, such as Gawker’s blogs. I notice that the vehemence of this debate never erupted over the non-linkability to arbitrary internal state of my GMail inbox, or to my high score on Entanglement for example. But I’m trying not to miss the wood of the web’s ambition for the trees of one particular implementation.)

Probably drawing ire, or confusion, from most at this point, I guess I leave it there. Please file under ‘verbose trolling’, and yes, for a developer, I’m veering dangerously close to amateur anthropology.

But let me finish with the commenter’s radical assertion that search engines ‘have long given up on indexing the web’ – crazy, surely: they still seem to do a great job with documents.

But applications? I’m not so sure. He might be on to something here. We’ve clearly got a long way to go in terms of describing and indexing application state, purpose and functionality on the web – without resorting to human curation. I’ve heard of these things called app stores, for example…