As you're typing in the Search field, an AJAX micro-request is sent back to the server to retrieve possible matches based on what you're typing. These are then displayed below the search field in a dynamic list. This is AJAX at its simplest.

User interactions on the Web page trigger background communications to the server and, when data is received, part of the Web page is updated. While these interactions take place in the context of the Web page, it's worth noting that the primary navigational experience of the site is from one page to another. After selecting an option from the AJAX-driven menu, the Web page refreshes. AJAX can be used very successfully in this way to enhance the experience of a Web page.

The average time a user spends on a Web page varies, but in general it's often less than 15 seconds. So the JavaScript that powers such Web page enhancements is necessarily lightweight because it needs to load, initialize, and do its job quickly before the user loses patience. For an enriched HTML page, the AJAX manipulations have to be able to dispel in that six seconds is that "is the page loaded yet" feeling that page-flipping Web surfers get before they leave your site because it's "too slow."

In contrast to the simple model of enriching the Web page experience, different AJAX techniques and architectures are applied to deliver full software-like productivity applications in a browser where users spend more time on a single page, doing a series of activities or tasks. An online e-mail client like Yahoo's might be used for 30 minutes - 60 times longer than a typical HTML page. A three-hour session using an online word processor would be 720 times longer. An online spreadsheet program such as Google Docs has myriad interactive controls that let you manipulate the contents of the spreadsheet.

A key difference between the two approaches is that AJAX-enriched pages are focused on direct manipulation of the HTML DOM's <DIV>, <SPAN>, and other HTML elements for highly custom behaviors, whereas AJAX applications tend to make heavier use of ready-made desktop-like application components such as dialogs, tab sets, buttons, accordions, toolbars, and menus. The JavaScript in the more broadly featured productivity-style applications usually take longer to initialize since they apply to the wider set of controls and the application logic itself. In addition, the combination of more controls, more information to display, and significantly longer sessions makes this solution inherently more demanding from a development, memory management, and architecture point-of-view.

The bottom line is that different models of AJAX fit different solution needs across a broad spectrum, but when approaching the software-like application experience, complexity ensues.

Warning: Do Not Try This At Home
Building a feature-rich productivity application using individual AJAX calls is somewhat comparable to writing an application with Visual Basic, Java, or C++ programming without using any windowing framework or toolkits. Or like building a server-side Web application using CGI programs without using any of the available tools/frameworks such as J2EE or ASP. Desktop frameworks like WinForms provide a framework for building desktop applications, and server-side tool sets provide a model to build high-performance Web applications.

Although it's certainly possible to use all these techniques to build a complex GUI in the browser, it's very difficult to put them all together in a single comprehensive Web application without a broader architectural strategy that avoids having to write 25,000 lines of procedural JavaScript with direct HTML DOM manipulations. That would be time-intensive to develop and difficult to maintain.

So what can be done to handle that complexity and drive increased performance while avoiding the pitfalls of memory management to assure stability over increasingly long page lifecycles? (See Figure 3)

    SHAPE \* MERGEFORMAT

A Compiler in the Browser?
Certainly, the browser has come a long way since its early days, adding not just JavaScript to its feature list, but also DHTML, DOM, CSS, XML, XSL, and the XHR (XML HTTP Request) object that facilitates background communications without causing page refreshes. Together, as the examples above have shown, it's a capable platform for creating sophisticated applications and not just Web pages with some useful incremental enhancements and features.

For the last two years, one of the top requests of AJAX developers has been for the browser vendors to put a compiler in the browser so that code sent to it can run substantially faster and so open up more possibilities while maintaining the ubiquity of the browser as an open client platform. While talk of such things has percolated repeatedly over at the Mozilla Foundation, evidence of Microsoft and others fulfilling this request is thin, so it will more than likely be a long time (possibly never) until a compiler is built into the leading browsers. So, without a true compiler what are other approaches to drive significant performance and better memory management for full-fledged AJAX applications?

It turns out that several processes in the browser, namely XML, XSL, and Regular Expression processes, run as compiled or native processes rather than the slower interpreted nature of JavaScript. Thus, tasks you can execute using them will run substantially faster then if you did the same in JavaScript.

As an example, let's look at how the TIBCO General Interface uses this "get out of JavaScript as soon as you can" strategy to boost performance and improve memory management for AJAX software applications.

MVC in the Browser
TIBCO's General Interface (GI) provides a high-performance AJAX application framework that's designed to provide rapid application development on top of XML and SOAP Web Services, although you can also use it with JSON or other formats. Architecturally, TIBCO GI leverages the popular Model-View-Controller (MVC) architecture typical of server-side Web applications, except that it uses the same MVC pattern concept for generating GUIs and maintaining application state on the client side. GI includes visual development tools, plus JavaScript objects and APIs for authoring ease against the application model, while using the faster processes of XML and XSL engines in the browser to process data and render GUIs and data to the screen faster than JavaScript can do alone. The MVC pattern is also helpful in separating data processes from view-generation processes. When that data is persisted as XML, more data can be stored, transformed, and rendered quickly.