Why 100% AJAX?

Geojoey is, for lack of a better phrase, 100% AJAX. In other words, the whole application is built as a single web page and never does a full page reload.

After 7 months of development and 1 week after launch, I thought I'd share my thoughts on the advantages and disadvantages of going 100% AJAX.

For the uninitiated, AJAX isn't a new type of drain cleaner. It's short for Asynchronous Javascript and XML. If you'd like some background, visit this page on Wikipedia.

First the down side
Hardware and bandwidth efficiency
Enter Mod_deflate
The User Experience - the real reason we use AJAX
Turning Javascript into .Javascript
Website visitors as a giant Beowulf cluster
The potential for real-time web applications
Would I do it next time?

First the down side

AJAX is a relatively new technology and has some advantages and disadvantages. There aren't any major roadblocks to using it, but here are some things to be aware of:

• It's not supported in older browsers
• It's not supported in many mobile browsers (thanks Eugenia)
• Back button support is not built in. If you want the back button to take your users to the previous view, you need to code it explicitly and there's no standard way to do it.
• It requires more work to implement and you usually end up jumping between two languages - Javascript and your server-side language.
• Much of your code ends up exposed to the outside world in the source of your HTML
• When debugging a problem, you're dealing with a flow of execution that jumps from browser to server and back again, sometimes several times.
• Your web application does not get to reload every time the user clicks a link and loads a fresh page. Instead it stays in memory and you need to make sure that it's stable enough to run long-term without the user hitting reload.

I have to admit I really enjoyed venting there for a moment. AJAX can be taxing on the psyche. However, if you can get past all that bad stuff, it does have some distinct advantages:

Hardware and bandwidth efficiency

On a traditional website, every time you click a link the whole page reloads. Browsers cache images, so I'll ignore those for a moment. The average HTML page without images is around 20K. So every time you click a link you're downloading another 20 Kilobytes of data. With AJAX your browser only fetches the data it needs. So if the only thing the browser needs to create a new view is a data structure containing a few paragraphs of text, then the amount of data transferred becomes more like 4K.

If you're serving a lot of pages, this makes a real difference. Anyone who's run a high traffic website knows that your two biggest expenses are bandwidth, and the hardware to support the number of requests being served. Without AJAX, a users browser is downloading much more data. In addition, each time a browser hits a web page it opens up many different connections to a server which require memory and CPU time.

What's the direct financial benefit? If you're running a high traffic consumer web application, your hosting costs are going to be one of your biggest expenses. Reduce your bandwidth use and hardware load to a quarter and you reduce your hosting fees to a quarter of what they were.

I'll admit I'm oversimplifying somewhat - CPU and memory are consumed by things like complex database queries too. But reducing the number of concurrent connections you have to handle and reducing your bandwidth needs does lead to huge cost savings.

Enter Mod_deflate

I use mod_deflate, a compression module available for Apache 2.0, to compress the content we serve down to roughtly 37% of its original size on average.

Mod_deflate uses a property called Accept-Encoding which is part of the HTTP 1.1 specification. When a users browser sends an HTTP request it can tell the server it accepts compressed data. Mod_deflate will zip up the data, send it to the browser compressed and it's then decompressed by the client.

The additional server CPU load generated by mod_deflate is negligible. Provided your users have machines with a CPU that's less than around 10 years old, they won't notice the difference in performance when they have to decompress your content.

I arrived at the figure of 37% by using a packet sniffer to analyze traffic sent from Geojoey.com to browsers with and without compression using several different sessions with the same activity. I also cleared the browser cache between each session and I used both Firefox 1.5 and IE 6 for testing.

The User Experience - the real reason we use AJAX

Cost savings on a website are great, but none if it matters if your user experience is awful. Geojoey is an application built on Google Maps. If we didn't use AJAX then every time a user took some kind of action, the whole page would reload, including the map. That takes time, even if your browser caches most of the content. The browser has to load the javascript into memory, compile it, execute it, render the page, and so on.

As a user uses Geojoey, they might zoom in 5 times, drag the map across a little, zoom in some more, click an experience and then click the back button to go back to the list. All that happens in about 5 seconds, but it's very fast because the application is only fetching the data it needs and only rendering the content it has to.

The need to not reload the map every time a user changes their map view is the initial reason I chose AJAX. But once I'd made that decision, I decided to make the whole application AJAX including the registration, login, about us page - even the terms and conditions load in an AJAX generated panel. The advantage of this is that it doesn't interfere with your map view. I created a floating glass panel to contain these elements and once you've finished interacting with any of them you can close it and you're back doing whatever it was you were doing on the map.

Turning Javascript into .Javascript

Javascript is a fun language but it doesn't have the same pedigree that, for example, Sun's Java language has. It's not built from the ground up as an enterprise ready fully object oriented language with things like Inheritance and truly private members. To be useful for creating complex client-side applications it needs a little sugar.

Prototype.js is an amazing little piece of code created by Sam Stephenson and is part of the Ruby on Rails project. I chose Prototype as the backbone of Geojoey because it provides just enough cross-browser compatibility, useful functions and syntactical sugar without preventing you from getting into the guts of Javascript if you need to. Almost every line of object oriented Javascript code that is Geojoey uses Prototype in some way and I really can't thank Sam enough for creating this awesome little library. One of my favorites is:

var myVar = function(){ this._doSomethingElse(); }.bind(this);

It's a way to instantly create an anonymous function which has 'this' set to the containing object. Another favorite is the $ operator which replaces document.getElementById():

$('someElementId').style.display = 'block';

And the $F operator to access form values in any form element type - selects, text inputs, checkboxes, etc:

var myVar = $F('formElementId');

While it was very tempting to use Ruby on Rails to code Geojoey, I chose to stick with Mod_Perl because it's the language I know. It also has CPAN with thousands of modules and is slightly faster than Rails. Please don't let this turn you off using Rails for your next project. Ruby has much of what Perl lacks, particularly in the OO world. Perl is OO by hack, Ruby is OO by design without giving you that claustrophobic feeling you get when writing Java code. Ruby is also evolving extremely quickly and the friends I have who use Ruby usually have smiles on their faces when talking about their jobs.

Website visitors as a giant Beowulf cluster

Creating a web application that does a lot of its processing within the browser has the simple advantage that you're not doing that same processing on your web servers. Things like validating forms, rendering HTML templates and ordering lists of items all consume CPU and memory. Being able to use your users CPU and memory can save your server hardware for other processor or memory intensive tasks.

You could take a really exploitative approach and think of your users as a large Beowulf cluster of machines who's CPU and memory you have access to. But don't get too greedy. If my machine slowed to a crawl every time I used your website, I'd probably stop visiting it.

The potential for real-time web applications

One of the lesser known features of Geojoey is that as you're using the application, you get message alerts that look a little like Instant Message pop-ups if you have a new vote for an experience, if you're received a message from another user, if someone's commented on an experience, that sort of thing.

If your application is 100% AJAX you can do things like set up an event loop that checks a server every few seconds for new activity and does things on the client side based on that new activity. So creating things like an instant message application or other types of 'push' applications become quite feasible. [And you thought push technology died in the late 90's ;-) ]

In a traditional web application this becomes a little harder to implement because your event loop is constantly interrupted by the user reloading your whole client-side application.

Would I do it next time?

I try as often as possible to objectively assess our application and our technology choices as if it were Monday morning and I just walked through the door at this new company and I'm looking at what we have for the first time. So, it's Monday, and right now I'm very happy with our user experience (although we're continually working to improve it) and our technology choices. I'll definitely go the same route next time around.

Comments

[Eugenia]

Don't forget that AJAX web sites don't really work on 98% of the mobile web browsers.

[Mark]

Very true. Something to keep in mind when assessing your target market.

[MarksHilary21]

It is great that people are able to receive the personal loans moreover, this opens up completely new possibilities.