Let’s take a little trip down memory lane, shall we? My first interaction with the ‘#’ as a method for getting at specific content (not as an anchor tag) was working in the ad/interactive space and with a lot of Flash developers. On every proposal or statement of work was a line about ‘Deep Linking’. In this case it meant plugging in swfaddress and wiring it up to your fancy Flash slideshow or fashion showcase. The point of this all was that when you clicked on the 8pt text in the menu that said ‘MENS BLOUSES’ you would be taken to the photo of a puffy shirt and the url would change to ‘#/items/puffy-shirt’. When you refreshed the page, or sent the link to your friend you would be taken immediately to the puffy shirt and be able to bask in its frilly glory without navigating through the 8pt menu again.
This was a big thing! Big, as in exciting and awesome, because it meant you could build relatively complex Flash applications, felt ‘stateful’ somehow. You would navigate somewhere and you’d be there, not in the middle of nowhere.
An important thing to note here is that this was not for Google. It was Flash. Google can’t crawl Flash. The point was allowing people to ‘Skip intro’ and have them feeling that this crazy interactive experience wasn’t all that different from there normal browsing. For crawling and SEO there were a host of other strategies – META tags, ‘ghost’ static HTML sites, etc. – and these were deployed alongside ‘Deep Linking’ as two different strategies trying to accomplish different things.
AJAX FOR THE PEOPLE
This is the part where I want to shake everyone. Like physically shake and be like “YOU! YOU’RE MISSING THE POINT”.
There are two different things. Crawlability and Deep Linking are two different things. For different reasons and different goals, and conflating them not only makes it hard on users, but also makes it hard on developers. You end up doing neither of them right.
How to do this right
I’m not going to go into detail about what framework you should use or how to lay out your app. Those are fairly complicated and my opinions could take up a couple blog posts. However, the basics are straightforward.
First, you need to determine some things about the structure of what you’re building and what your content is. Are you building an ‘application’ or a site? Does your content need to be searchable and reachable by the entire web? Do your links require true permanance and will changing them in the future “break” traffic to your site?
Twitter is an interesting example here because they took what was at its core really an information site, not all that different from a blog and turned it into an application. The questions of URL permanence are really gray here but I dont find myself hating it at all.
Web standards are at the core of this debate. Many make a strong argument that concept of the URL and HTTP is here for a reason, that URLs have worked and continue to work. I think instead of fueling FUD, we should get back to the work of building a better standard and a better web.
A brief epilogue on pushState/HTML5 History
A lot of people are pointing to the new HTML5 History API as a much better solution to this problem. I agree with reservations. First, the browser support for this currently isn’t very wide, and certain browsers that do support it have buggy/broken implementations. The bottom line is that it will work in some places, but not most, and this will probably be the case for years to come. That said, it is really exciting and I’m working on built in support for it in the next version of Sammy.js. I have other reservations, too – namely I think that not all hashes are created equal and in some cases the state you want to represent is really the state of a specific page not a seperate page that really requires a fully seperate URL.