My applications are part of a framework (LMS) that load a billion extra items on each page load.
To get around it I wanted to do that silly “twitter thing”. They’re the ones who get credited with it because for years normals were baffled by their url changing.
http://www.adequatelygood.com/2011/2/Tho…
Additionally, if you’re interested in why the bang(!) is necessary, it’s not. It’s just to tell google to index the page. Otherwise they assume it’s just an anchor link.
https://developers.google.com/webmasters…
So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.
This was especially annoying because our LMS forces changes with <a> tags.
What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.
In continuing research obviously I had to investigate why twitter moved away from hashbangs.
http://engineering.twitter.com/2012/05/i…
The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.
Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.
Very interesting post. I don’t think I completely understand the rationale for applying the hashbang URL style in order to avoid page reloads. You avoid page reloads by designing a client-side Javascript application that retrieves data from the server using AJAX. So if your application is part of an LMS that loads a billion extra items, you just incur that cost once by delivering the initial javascript necessary to bootstrap the client-side application, and then any additional resources that are needed by the application are loaded asynchronously. No page reloads are required for the lifetime of the application, but also no user/indexable references are exposed to the web as a result of this approach.
The hashbang URL, as I understand it, is about providing a reference to client-side application state that would not otherwise be directly accessible. The hashbang URL solves the problem of providing references or “save points” in a client-side JS app that are for the benefit of both users and JS-aware crawlers. The application is still delivered through the primary entry point, but using the reference in the hashbang, it can programmatically marshal the resources to represent that state.
Just out of curiosity, can you provide any small examples, maybe before/after snippets of how the links changed and what code you needed to write to get the hashbang URLs working?
You understand the rational of needing to get away from isites reloading for every link. And you can’t get into ajaxying everything without leaving in support for the back button.
I did not solve the problem of multiple applications using hashes. The solution would have to include a unique identifier with the localized url. Right now the hash looks like #/quiz/index#a_icb_pagecontent1143979 — because isites was already adding some hash data whenever you click on any link within a topic. Very annoyingly, but it made me have to parse the hash, so all I really need to do is add a topicid (because I don’t think the pagecontentid is unique to topic. So an easy implementation would be like #topicid1234#/quiz/index#a_icb_pagecontent1143979 and I’m already parsing out the link, I can just grab the topicid easy enough.