By Noah | March 8, 2011
Background: the #! fuss
I’ve been thinking about all this for quite some time, but the recent fuss over so-called “hash-bang” (#!) URIs raises the stakes considerably. As previously noted, Jeni Tennison has posted a terrific overview, with links to contributions from many others. If you’re not up on all that, please read those postings first.
- The résumé browser is similar in style to AJAX implementations of GMail or Yahoo mail, but its purpose is to let the user browse through collections of job application résumés. The initial screen provides a list with one line per applicant, but the user can request to see individual résumés as well. Under the covers, all the usual Ajax tricks are being used to pre-cache résumés, to provide fluid interactivity for the user, etc. Users require the ability to email and post links to the individual résumés.
- The final example is the full (as opposed to mobile) implementation of Google Maps. Like the others, this is an Ajax application. Users can retrieve maps for most any part of the world, zoom, pan, and annotate the maps with points of interest or driving directions. Crucially, an interface is provided that gives a URI (with no # in the syntax!) for the current location, zoom level, annotations, etc. As with the résumé application, these URIs can be emailed, linked from other Web pages, etc., and indeed this is a very valuable capability that is often exploited by users.
There are two main points I’m trying to make in this note. The first is:
Use of AJAX implementation technology is not a sufficient excuse for failing to provide first class URI identification for documents on the Web
Documents when possible
Now let’s consider the Google Maps example. What’s interesting about it is that the Google engineers could have easily made the claim that the maps application was like the simulator, provided a single URI for the entire application, and stopped there. They might, to go a bit further, have done some local kludging to enable FWD/BACK to work, while still not exposing URIs for the different views of the map (or if you prefer, for the different maps.)
So, using Google Maps as my poster child:
Where practical, model your application as a collection of documents, each with its own URI
Syntax: # or ? or neither
Note: this section was updated on 10 March 2010 based on the important observation from Jeni that the query component isn’t necessarily more important than the hierarchical path as an alternative to # fragment syntax.
I continue to have a general feeling that fragment syntax (#) has been over-emphasized in all this, and that identification using other parts of the URI, such as the path for hierarchical identification and/or the query string (with ?) for non-hierarchical may be preferable. Yes, for that to happen, we’ll have to get changes like
changeState() widely deployed, or maybe we’ll need other changes too. Still, from an architectural perspective, # seems somehow more fragile: until we ran unto address-bar update problems, fragments were used with documents to identify, well, fragments. Yes, with new media types we can do what we want, but in this case we don’t have a new media type, and the normative specifications make clear that for text/html, fragments refer to anchors within the document.
To be clear, I don’t think there’s any outright architectural barrier to server-side interpretation of fragment ids in cases where agents like crawlers happen to get hold of them, but of course, typical clients don’t send them to the server at all. Maybe we can find a way to use # that meets all the goals, and update the normative specs to support going that way. My guess is that, in the long term, avoiding fragments by using path and/or query is a better solution. Either way, we need to align the specs. with common practice.
Anyway, my main point is to model things as documents where possible, and to give each document a unique, crawlable URI that works consistently at client and server.
Finally, I hope it’s clear that I am in no way discouraging Ajax implementations, whether for résumés, simulators, or maps. I don’t want to let Ajax be an excuse for building a Web full of documents that can’t be properly linked.
Documents in applications by Noah Mendelsohn is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.