Ajax, SEO, hash-bangs and breaking the web
Recently, there was some controversy on the adoption by gawker.com of Google’s hash-bang workaround for indexing Ajax websites. This prompted discussion on whether this is breaking the core principle of the web : that URLs provide consistent access to resources.
Implementing the hash-bang workaround (or like Wt does, a plain HTML page with exactly the same contents so that it works for any search engine or browser without JavaScript, not just Google bot) in a traditional web framework, using RESTful APIs, is no small technical feat:
-
You need to use a cross-browser API for reacting to URL fragment changes, and update the DOM accordingly using JavaScript, pulling in the necessary contents from the server using Ajax. In a RESTful implementation, your servers expose a model using RESTful APIs and the View rendering is implemented in client-side JavaScript.
-
At the same time, you need to make sure that the server generates on its own (exactly!) the same web page when a google indexing robot asks for the same contents, directly from the server, requiring at least a duplication of the View logic.
It is then not a surprise that only the most sophisticated web applications (like Facebook and GMail) take the effort to properly implement this (and others fail).
Note
|
Now then, here’s an opinion: if you separate your Model (at the server) and your View (with JavaScript in the browser) and glue them together using a RESTful API and Ajax, you cannot degrade gracefully without painful code duplication, or an equally embarassing page that says "Sorry, not implemented". |
HTML5 History API: nothing but goodness
With the advent of the new HTML5 History API, there is no need anymore to use a hash-bang workaround, and you can have the same URLs in Ajax and plain HTML sessions. That eliminates the only draw-back of the hash trick, namely that a user could not pass on a URL from a Ajax-enabled session to a plain HTML session and have it work. Clearly, there is nothing about this that breaks the web, to a user (and search engines), URLs work in a predictable way.
Staying in the same page does not only give you performance benefits, it also allows you to include new functionality like a chat widget or anything else that requires a stateful presence in your page. You can open a WebSocket connection once for the entire stay of your use on your page. You can do things that are simply not possible otherwise. It is not a coincidence that Facebook moved to Ajax + fragments at the same time that they launched their chat functionality.
Wt and JWt implemented the hash-bang trick already for some time, and we have now added HTML5 History API support. There is no need for duplication of code since the library can render any update either as HTML or JavaScript, depending on what is needed.