Switching pages with ajax vs. the conventional way of loading page

Question

I was wondering if it's good idea to intercept all internal links and load the target page with ajax.

The new history api from Html5 makes it possible to also change the url in the address bar.

are there any disadvantages between this way and the old traditional way that let's the browser load a new page (besides the increased complexity of the code)?

Answer 1

Many frameworks use the HTML5 History API to have client side routing. I don't think you mean that you should load the target page with ajax, but rather change the DOM without requesting the page from the server. There's a whole debate going on (and has been for the past several years) about which architecture is better and honestly it's all down to what you're trying to achieve.

Angular and Ember are client side frameworks that help build rich javascript applications (rather than the traditional website). Since JavaScript has gotten faster and more powerful in all the browsers, it has been possible to build more and more complex applications in the browser (opposed to desktop applications written in C++ or .NET/Java). The advantages of using this way of routing is that you get nice clean URLs, and you don't waste time going to the server for each request. However, you lose authentication (so if you want to protect content you'll need to go to the server anyway), and not all browsers are up and running with the History API yet (look at IE7,8,9). Consider your target audience and ask yourself if they will use these browsers or not. The frameworks I mentioned use fallback methods and implement the hashbang system instead. This has arguable problems with SEO however.

On the other side you have your server side frameworks like Rails (for Ruby) and Express (for NodeJS) that will serve the pages to the client using clean URLs. If we go further back you get into the realms of ASP.NET, PHP and plain old HTML that use the 'unclean' URL way of routing. The advantages of using the server to give you your content should be obvious - if you have protected content and the user should be authenticated then you can easily check this.

One final thing to note is the question of JavaScript. Ask yourself if your users are going to have JavaScript enabled and what will happen to your application if they have it disabled. Does this matter? How complicated is your application going to be? Do you need to use a big framework for your app, or will simply using a modern technology that gives you clean URLs be enough? Loading every bit of JavaScript takes time, and that time can be eliminated if the server is only giving the client the bare minimum of what it needs.