caseyporn

Ajax: The Next Generation of Web Interfaces

In a neat bit of synchronicity, I've just read an excellent article that covers a lot of thoughts I've been having about the web recently. It's called Ajax: a New Approach to Web Applications, and I would consider it essential reading for any web developer. It's all completely true, for a start, and well written to boot.

Ajax is Asynchronous Javascript and XML. If none of those words scared you, read on for a discussion.

The article covers the basics, but here is a summary of what it's all about, and then my thoughts on the implications of Ajax.

A web page, built in HTML or XHTML, is structured data. This data is kept in the DOM (Document Object Model), a standard way for web browsers and clients in general to think about web page structure. DOM provides access to the various bits of a web page. It's a standard that has been around for a long time - at least seven years - and, while it's still evolving, is supported by every browser under the sun. Their reason for supporting it is mostly selfish: it's so the browser can render the page better.

Javascript is a programming language that runs inside a browser and works with web pages. Javascript is what makes those annoying ads pop up, but it also does things like form validation. Historically, it has been maligned as a terrible programming language (it really isn't very much fun to use), and has been relegated to either performing quirky show-off tricks or mundane trivialities like checking values in forms. The truth is, it's a real programming language, controlled by a standard, and very widely supported in browsers.

XML (eXtensible Markup Language) is a way of representing structured data. For all that's been said about XML, that's really all it is. It makes it easy to define a format for some type of structured data, and then exchange that data with other bits of software. It's a standard, which makes it easy for programmers to use the same tools to deal with any data that's stored as XML.

What happens when these technologies interact? Javascript has access to the DOM of its webpage, both to read information and also, more interestingly, to change the DOM interactively. This means that a web page can be built on the fly, and altered once it has been constructed. Build a page at load-time has always been possible in Javascript, but the effect of changing it later has historically been quite erratic. That's all pretty much sorted out now, which means that a DOM can be radically changed by Javascript, even after it's been built.

So a web page can embed (or link to) some Javascript, which can then change its appearance. This is still basically static, though: the entire behaviour of the Javascript+HTML is already determined. A page might be able to generate lots of pretty graphs or pictures or things, but it will do the same thing each time (pseudorandomness permitting).

To make it truly dynamic, Javascript requires some external source of input. Traditionally, this has come from the user, through forms. A user could click, or move the mouse, or fill in values in forms, and Javascript can take this and perform some calculations, then change the DOM as a result. In the graph-making example, different values from the user change the graph.

There's one other source of data available to a Javascript program: a network connection back to its web server. This is where XML comes in: both requests and information can be encoded as XML and sent to and from the program and the server. All of a sudden, a web page can be dynamically updated based on this XML data. In effect, web pages can be rebuilt on the fly.

XML-based network communication is nothing new. Indeed, both Flash and Java applets have had nice formalised models for bidirectional XML-based communication for some time. I've built a few web apps using Actionscript (Flash) clients that talk to a Python server (built using the Twisted web/network library) via XML, and it works very well. Now, these kinds of rich interactions are available to web pages, based on standard and widely available technologies. Welcome to Ajax.

In an Ajax page, an "Ajax engine" as Garrett calls them is loaded in the form of a Javascript program. This Ajax engine then builds and modifies the DOM of a web page based on XML interactions with its server. No new HTML pages are requested from the server.

This is a big shift from traditional web applications. Usually, the HTML is built on the web-server and pushed out to the browser. For most web sites, chances are that the new web page will be at least 90% the same as the last one: the structure and formatting is the same, and just some of the links and data will have changed. But the whole lot has to be built, by the server, each time, and then transmitted. If you're generating millions of pages a day, this is quite a lot of work, which is why there are all those server farms for big websites.

Under Ajax, the HTML (or the DOM, really) is being built on the client side, by the Ajax engine. Only the "interesting bits" - the things that have changed - need to be built by the server and sent over the network. This saves on a lot of resource usage, both CPU time and network bandwidth. Again, this is nothing new, but now it's available in normal, standards-compliant webpages, rather than through applets or plugins.

This has some big implications for web application development. It promotes a very clean separation between the interface and the application: while technically all web apps should already be neatly separated, my experience tells me that this is not always the case. Now, there is a very clear line: the server accepts requests and produces responses, all using XML. The emphasis moves from server farms producing lots of text (HTML) to heavily networked servers with connections to lots of Ajax clients.

At the other end, using Ajax requires building an Ajax engine - a reasonably complex Javascript application (in a language that is not easy to build large programs in) that replaces all the HTML-generation code that existed on the server. I predict that there will be a range of solutions that try and ease migration from current HTML-generation solutions such as PHP and ASP by building generic Ajax engines that are based on legacy code.

Providing cleaner interfaces between data and interface raises some other issues. Rather than rely on screen-scraping to extract data from web pages, it should be possible for interested parties to build their own Ajax engines to use various sources of XML-formatted data. Don't like the layout of a website? Given the correct licensing of their data (and this will be a big problem), you can build your own instead. This just goes further down the path that Amazon has been pushing, of open web services and easy data availability.

In addition to exposing the data, using Ajax also exposes the DOM-rendering Ajax engine to the client. Javascript is distributed as source code which, while it can be obfuscated, still contains all the details of how the web page is built. This isn't really a problem, but it might be seen as one by a lot of businesses. All the interesting stuff is still happening on the server - an Ajax engine should be seen as a courtesy by the company, available for free, so that the company's data (their webpage) can be viewed. It will be very interesting to see how this space - the better availability of data and code, combined with intellectual property issues - will play out.

Ajax places larger demands upon the web client, something that is usually seen as quite a thin client. Handheld and low-power devices may not be able to support Ajax engines well at the moment, but in the long term this type of approach has many benefits in this sector. Ajax makes for richer clients with more ability to leverage the specifics of the interface (such as small screens on phones), and also reduces the amount of bandwidth used. These are both issues that have plagues internet use on small-format devices so far.

I'm pleased to see this technology being used, especially by companies such as Google, who have obviously decided to pursue this avenue. Their motivation is two-fold, I think: both to provide a better user experience, and to offload a lot of computation onto the client. If you're generating billions of pages a day, it makes sense to try and minimise your resource requirements, and this is definitely a compelling way to do so.

Normal HTML pages aren't going away. One way to view them is as snapshots from an Ajax engine. Indeed, if you build your web app to be used by Ajax, then it is reasonably straightforward to run an Ajax engine locally (on the web server) and send the resulting HTML to the browser instead. This will aid application migration and will no doubt stay as a legacy alternative well into the future.

In reality, Ajax is nothing new. I've said it a couple of times, and it's worth repeating. It's just a combination of some existing technologies (Javascript, DOM, and XML) to produce a different way of looking at interactivity on the web. It moves clients away from thin HTML-viewers and back towards custom clients, and as a payoff it reduces bandwidth and server usage. In the long run, everybody wins. In the short term, it requires more client-side development and a rethink of current web application methodologies. It is a step away from the inefficiences of traditional web-servers, and towards the type of model alluded to by Microsoft's .NET framework.

To conclude, some predictions for what happens next in this space:

• new development tools for "Ajax engine" development: better libraries for XML and DOM support in Javascript, plus toolkits built on these that come closer to the server-side templating engines such as ASP and PHP.
  
• migration tools to help turn server-side templates into client-side templates
  
• faster scripting in browsers - this is already happening
  
• renewed interest in networking platforms like Twisted that are good at dealing with lots of little connections, perfect for Ajax servers.
  
• greater data-reuse from sites that feed XML: alternative interfaces and aggregation.
  
• a move away from the limitations of Javascript, towards a better language or set of languages: the .NET framework and CLR show what this direction could offer.
  

Posted by Casey at February 22, 2005 12:09 PM