So, we've been hearing a lot about AJAX recently (but if you haven't, Wikipedia is always a great place to get up to speed) - another addition to the arsenal of strategies for creating Rich Internet Applications (there are plenty of others - Flash Remoting, Java Applets, XUL and XAML to name a few). A lot has been toted recently about AJAX, and RIAs in general as a phenomenon that will transform the way we work and even ultimately kill the desktop. Although this vision is perhaps a bit optimistic (at least for the time being), there are a number of other cool things this approach can offer in the meantime. In particular, in addition to the much-debated improvements in user interaction there may be some real architectural benefits to developing with AJAX.
1. It separates presentation logic and business logic in a way that few other technologies can. In a nutshell the way AJAX works is to have a server spitting out raw XML, which is then formatted and adjusted by a HTML page in real-time. This means that those who like to focus on data can deliver the former, and those who perfer to build goregous apps without caring where the information comes from can work on the latter - no more mishmashing of HTML and PHP (or JSP, or PERL, or whatever your poison is). Also anyone who's been thinking about service oriented architecture recently should also be pricking up their ears at the idea of the idea of having lots of XML-driven data sources floating around.
Because of this separation of concerns, the ability to build end-user functionality is put in the hands of designers (provided they get comfortable with JavaScript, and can convince their programmers to give them some useful XML to work off). They don't need to worry too much about what's serving up the data or or where it is - as long as they can get at it with their JavaScript code.
2. If a few different services on the same domain use AJAX, and therefore have XML feeds in the background serving up all the core data, the gateway is open to build some really cool services that combine all those feeds together. Imagine a search engine where you pull up not only an academic's phone number, but also their web page, their current publications and last 5 blog posts. All without any server-side code. Not that I'm pre-empting anything here...
3. By using client side Javascript to offload all your presentation logic to the client, and reducing the data sent between requests to a small amount of XML, you're freeing up precious CPU cycles on the server for more important things, like more customers.
So quite apart from any benefits to user interface design, there are some quite significant architectural benefits from an AJAX approach. But before we get too excited about this nirvana of stateless web applications all harnessing interoperable data sources, it has to be asked - can we actually use this yet? Confidence is growing as high profile sites like Google Maps and GMail push AJAX into the mainstream, but even these sites still offer non-AJAX equivalents. The standards around several components of AJAX (notably, the XMLHttpRequest object) are yet to be defined - IE and Mozilla of course implement it in entirely different ways, while the WC3 is proposing (and is yet to accept) something different again. Not all browsers support it, and users who turn off JavaScript, or who are using a PDA or mobile to view the page will almost certainly be prevented from acessing the service as well. And don't forget, there are plenty of competing technologies that may win out instead.
Personally, I think the debate is still wide open as to the extent developers should embrace AJAX. There's a strong argument in my mind, that if it works now, on the majortity of browsers now, then it should be used now, even if you can't make everyone happy. But maybe I'm missing something? Is there anyone around the Uni who has already had a crack at it (even better, if they've done it within CMS)? We'd love to hear from you.
Comments
All sounds nice in theory, but when you start relying on client-side coding/processing things can start to go horribly wrong. So long as we have more than one operating system, more than one company making web browsers, and browsers which let users select which technologies they want to enable (JavaScript/CSS/ActiveX etc) then you can plan for problems.
Posted by: Dave | November 8, 2005 12:11 PM