AJAX Web Development Techniques

PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free

AJAX Web Development


by Faulkner Staff

Docid: 00011232

Publication Date: 1905

Report Type: TUTORIAL


Web applications have gained more functionality thanks to a collection of
comparatively old technologies applied in new ways. Ajax (Asynchronous JavaScript And XML) is a methodology that allows hitherto unheard-of interactivity in
browser-based applications. This report looks at the methodology, how it works,
and what it means to the enterprise developer.

Report Contents:

Executive Summary

[return to top of this report]

Asynchronous JavaScript and XML, also known as Ajax, is an
approach to Web development that combines several existing
technologies in a unique way.

Faulkner Reports
LAMP & WAMP Basics Tutorial
XML Development Tools

Instead of using server-based programming to dynamically manipulate
Web pages, it uses local scripting and XML to minimize the traffic
between client and server, creating applications that are more
responsive and versatile. For example, using Ajax, Google built Google
Maps, which allows users to drag and drop within a Web application,
functionality that had been previously unavailable.

Although the way they’re used is novel, Ajax technologies
themselves are not new. Rather, they are old technologies with known
pitfalls that have been reborn under the Ajax umbrella and put to
unexpected uses.


[return to top of this report]

Ajax is a set of programming techniques designed to
speed up the Web application experience for users. It was first named
and described in a paper by Adaptive Path’s Jesse James Garrett in
early 2005, but it has been in use for longer than that. It is the
foundation of Google’s Gmail, for example, and Yahoo’s photo sharing
service, Flickr, as well as the basis for many other interactive
Web-based applications.

In an ordinary Web browsing scenario,
the sequence of events is roughly as follows: an HTTP request from the
user is sent to the Web server, which receives and processes it. This
may entail interaction with several backend systems such as databases.
While the request in in progress, the user waits. The server then
sends HTML and CSS data back, generating the Web page in the user’s

Ajax adds a layer to this process. At
the beginning of the session, the browser loads an Ajax engine,
written in JavaScript and usually concealed in a hidden frame. The
engine acts as an intermediary, sending user requests to the server
and receiving and rendering the resulting pages. It also processes
requests that don’t require server data, such as validation or editing
data already in memory. If, for example, a list of items the user is
viewing needs sorting, the Ajax engine can do so on the local machine.
When server interaction is required, the
engine sends the request asynchronously, usually using XML, without
interrupting the user. This generates a seamless user experience,
relatively unpunctuated by the fits and starts of an ordinary browsing

There’s no magic. Ajax uses standard Web components:

  • XHTML and CSS – for presentation
  • DOM (Document Object Model) – for
    dynamic display and interaction
  • JSON or XML for data interchange and XSLT for data manipulation
  • XMLHttpRequest – for asynchronous
    data retrieval
  • JavaScript – to pull everything

What is new – or rather, old become new
– is the use of JavaScript for local processing where possible instead of exclusively using server-side scripting.

Server-side scripting has been in favor
recently for many strong reasons. It doesn’t run into browser
compatibility issues, where locally some browsers may not support
JavaScript. Some computers don’t have sufficient power to run any but
the simplest scripts without adverse effects on performance. Some
Internet connections (particularly dialup) do not offer sufficient
bandwidth for the necessary background downloads.

Despite these challenges, applications
such as Google Maps, which allows users to drag objects with a mouse,
just as they can in a desktop application, have convinced developers
to revisit the technology.

Current View

[return to top of this report]

Ajax-based applications are springing up all over the Web, and in internal
corporate applications. For example, Zimbra launched an enterprise
messaging and collaboration server with a tie-in to Google Maps so
users can mark the location of a meeting with a Google Maps image
within the calendar, Basecamp’s product is a Web-based project management
application leveraging the interactivity and drag and drop capabilities
enabled by Ajax programming. Microsoft Outlook.com is based on the technology, as is the Yahoo Mail client.

The technology does, however, generate some challenges for
developers. For example, unless specific coding compensates,
the browser "Back" button becomes useless because local
processing may have been the mechanism to alter the page, not a
request to the server. Developers must also provide alternate viewing
mechanisms for users of browsers that don’t support JavaScript.
Because XMLHttpRequest is tied to ActiveX in current versions of
Internet Explorer, users of that browser also need to enable ActiveX,
which presents its own security issues.

Google, whose use of Ajax has created a number of compelling applications,
has released the Google Web Toolkit (GWT), an open source Java development
software framework. Programmers can write an application front end in Java, and
the GWT compiler converts the Java classes into JavaScript and HTML. In
addition, Google indexes pages
built with Ajax, making the technology more attractive to sites relying on
search results for traffic.

There was, however, concern that there may be attempts to create
proprietary products, preventing the widespread use of the techniques
cross-platform. The Open Ajax Initiative, whose founding members
included Borland,
IBM, BEA, Zend, Google, Yahoo!, Red Hat, Eclipse, Zimbra, and Mozilla,
sought to ensure that there is a compelling Ajax platform that remains
independent of

  • Browser
  • Client operating system
  • Server container/language (Java, PHP, Ruby, C#, etc.)
  • Server operating system

In the spring of 2006, members of the Initiative decided to create the Open
Ajax Alliance, whose primary mission is to "accelerate customer success with
Ajax by improving the customer’s ability to mix and match solutions from Ajax
technology providers and helping to drive the future of the Ajax ecosystem."

The initial plan had given the group a fixed lifetime of two or three years. Six
years later, at the end of 2012, the group ceased formal operations, though the
Accessibility Committee has resources available to continue its work.
The website, wiki and mailing lists remain active, and the open
source projects at SourceForge are still maintained.


[return to top of this report]

Ajax applications hold great appeal because they
combine the convenience and easy access of Web applications with the richness
and functionality of locally installed programs. They are not tied to a
particular operating system, or even to a form factor; if a
mobile device’s browser supports JavaScript, the applications will run there
(although screen size is another, separate issue).

We can expect continued growth of applications using these techniques
for several reasons, the main one being that Web-based applications
are being promoted as the way of the future, and Ajax allows these
applications to more closely resemble the familiar locally-installed
desktop software. Users will not put up with less functionality as the
price for the supposed economies in Web-based applications; Ajax is
one method to satisfy their needs.

It can be especially effective
within controlled environments like corporate networks, since
potential issues around lack of bandwidth, incompatible browsers and
feeble desktop computers can be managed. Internet-based applications’
user bases are an entirely unknown and uncontrollable quantity, adding
to the application design complexity.

Opportunities for JavaScript developers
will increase, since the Ajax methodology requires a lot more code than some
other Web applications. And despite the promise of hardware cost savings from
Web-based applications, the additional local code will place an unexpected
burden on the desktop, requiring more computing power, not less. 


[return to top of this report]

is a technique worth exploring by companies looking to move their
application development to browser-based products. The interactivity
and richness of the resulting programs can make the applications both
more appealing to users and more functional.

Developers will need training and some new tools to take full
advantage of Ajax. They need to learn the pitfalls, and their
workarounds, as well as the exciting things that are possible. They
also need to learn restraint. As in the early days of desktop
publishing, when the novelty of using many fonts resulted in documents
resembling ransom notes, the risk with Ajax is that developers will
make indiscriminant use of interactivity, creating applications that
are distracting rather than functional.

As with any Web-based application, however, companies contemplating
subscribing to some of the vendor offerings must weigh the benefits of
using what is, essentially, software as a service, with the potential
impact on corporate security. A Web-based project management system that stores details of corporate projects on an external Web server,
however otherwise desirable,
can pose a major risk if that server is not properly secured, for

Ajax isn’t entirely new; although its name is over a decade old, the local
caching and manipulation of data using JavaScript has been around for some time.
It’s the application of a series of common technologies in a novel manner that
excited the industry. If the issues that pushed developers away from client-side
scripting are
overcome, Ajax applications will live up to the hype. Until then, Ajax
should be but one tool in a developer’s arsenal.

[return to top of this report]

[return to top of this report]