Lately there has been a flurry of discussion in the blog world about Web applications that use JavaScript asynchronously, generally with XML, to create a different style of Web application. A few notable examples (such as Gmail, Google Suggest, and Snaptax), and others use this model to create very rich and often faster user experience as compared to standard, click-and-wait Web applications.
A few folks have dubbed this Web development model, Ajax -- as tempted as we are to go on a rant on why we need a new acronym for something that has been around for quite a while (especially one that reminds us of a cleaning product) -- we abstain, courteously. Instead, let's consider if an Ajax model will affect Web administrators and performance.
At first, the answer would seem to be that Ajax will make everybody happier -- users and administrators alike. Consider that in most sites, as users move from page to page, many of the requests are redundant. For example, from one page to the next, the framing HTML is often very similar, but yet you have to retransmit since you can't just send the content down (or can you? -- every here of delta encoding?). Of course, you also will often reuse images, CSS, and scripts from page to page. This won't be too problematic if you are using proper cache control, but if you don't there could be tremendous waste with retransmissions or needless 304 responses. An Ajax-based application would theoretically get rid of some of this.
The basic idea would be the primary files of the Web app would get downloaded in the beginning and only needed data or logic would be fetched later on. If properly coded, one could expect a significant reduction of bandwidth over the visit. However, you will find that request activity will likely shift to be less spread out, potentially causing more bursts of requests on servers. In some sense, Ajax does reduce some requests, but it also just shifts others around.
Now, save the potential for bursts, it would seem that Ajax makes life much better for overtaxed severs… but wait just a second. Once empowered with Ajax thinking, we are noticing that many Web applications built want to have more two-way communication. Since the server can initiate connections to browsers, the only way to accomplish this is through polling. So, in many Ajax applications, you see timers firing every 60 seconds (or much less) requesting status reports from a server to see if updates are required. Houston, we have a problem here. If you think RSS readers cause problems, try hundreds of users polling regularly, keeping the server busy with uncacheable requests because they left their window on your page when they went to lunch. Speaking from experience, we have an application that has 30 some-odd people polling all day long for status updates on their screens, and the server isn't too happy. Oh, and your logs are practically useless and quite massive with this going on... Hmmmm... Product need here? So folks, when you use your new Ajax power -- remember you might make some users happy, and you might make some admins mad and require them to put in much more $$$ equipment to deal with your fancy, whiz-bang app.
Oh, and before closing, I can't help myself... Rant mode on: Ajax is not new; it has been called inner browsing, remote scripting, and a slew of other things -- so please people, stop with the acronym invention.
Signed,
Pat from the Port80 Web Team