2012 Will Be The Year Page Refreshing Dies & Realtime Lives
2012 is going to be the year that page refreshing in a lot of websites well and truly dies. Page refreshing feels so benign and old, the next logical step and something that should have been more common place but hasn’t is realtime web interfaces.
But we already have AJAX Dwayne, that’s hardly anything new, we’ve been able to load pages asynchronously for ages now. While that might be the case, most implementations of AJAX make a request in the background and most of the time are loading full web pages complete with titles, styles, headers and whatnot (especially when it comes to loading a page via AJAX for example).
2012 will be the year that developers start utilising things like Websockets as support grows, loading in pieces of content as needed instead of loading a new page which in turn creates multiple connections for each piece of static content you load – why load the same things twice when you only want to replace a small section of text or dynamically load in a new title or image?
As you may have seen recently I redesigned Kill Hipsters, but what I have planned next will probably seem crazy and inaccessible to a lot of developers, everything is going to be ajaxed and loaded in as needed. It will be accessible in that the single pages of content are still there, links to everything are still there but every piece of content loaded like a link will have an event binded to it and hijacked loading only what’s needed and shuffling the current page around by using a simple technique of changing class names to change the layout.
If it’s successful and I know it will be, then that is how all of my future sites and applications will work. I’ll probably open source the code as well if it’s good enough so others can create dynamic sites and blogs.
What about the SEO and search engines bots? Can they see the entire site and all the content?
Yasen makes a good point. I was thinking about implementing this on a future site idea of mine, but then I read his comment about SEO compatibility.
Perhaps since more and more sites are using AJAX, Search Engines should find a way to dig through this content? Though, they probably haven’t done it yet because content loaded dynamically is generally content that probably wouldn’t be relevant for a search engine to crawl through anyway, such as user feeds.
Maybe some creative method could be devised, for say a blog environment, to redirect crawlers to the specific blog posts instead of only the index page where it’s just entirely AJAX.
Google can interpret Javascript. The Google indexer has been able to interpret it for a while now.
Oh wow, that’s crazy. Didn’t know that. Well, it appears Google’s ahead of the game.
The accessibility concerns are valid, but as Code Junkie pointed out above me (strangely enough a few minutes for this comment) the Google indexer has been able to interpret JavaScript for a while now. Not only has it been able to parse JavaScript, but even if it couldn’t parse it, I’m not talking about breaking site functionality completely.
As I pointed out in the article towards the end, all links to the original content are there and if you were to manually enter the link into your browser URL bar you’d be taken to the page like you would else-wise manually so bookmarks and Google search result links would still work.
The solution I propose does what jQuery Mobile already does for mobile sites. It merely binds an event to all links, then makes it do an AJAX call in the background instead of a page fresh. Your backend then merely detects if it’s an AJAX request (very easy to do) and then returns content only, with support for definable parameters to return specific pieces of content (a div with a particular ID for example) and returns it.
I’m hoping to make it as smart and easy as possible to use. I think it’s a rather ambitious goal to make it plugin and play, but we’ll see.