InfoXchange
The Newsletter of the ICCA Greater Boston Chapter

Building Web Applications with Ajax

By Stuart Jones, Berwick Heights Software, Inc.

How many of you remember building text-based, or what we used to call curses-based, user interfaces? Before we had the modern desktop application with menus, buttons, dialog boxes and other dynamic presentation widgets, the text-based interface was the best way to interact with the computer and was a step up from command-line interfaces. These days, text-based interfaces are considered rather passé and certainly would not gain entry into any user interface design competitions. Now that users have experienced advanced GUIs in their desktop applications, they do not want to use the simpler text-based interfaces of yore. In the same way, once users experience the dynamic features of Ajax-enabled web applications, with their continuous user interfaces and ease of work flow, they will consider today's classic web application (where they fill out a form, hit the submit button and wait for the server to respond with another web page) rather behind the times.

Ajax is an acronym for Asynchronous JavaScript and XML. It combines four different technologies to make the web-based user experience more dynamic: The term Ajax was coined in early 2005 by Jesse James Garrett in his article Ajax: A New Approach to Web Applications, http://tinyurl.com/7xzse. Mr. Garrett's coining the term did not mark the beginning of Ajax-enabled applications but was only a point in time when a class of web applications was codified. In fact, these types of web applications were being developed by myself and others as far back as the late 1990s.

Each of the technologies that make up an Ajax web application has been standardized so that all modern browsers support them in a unified fashion. This allows web designers to build Ajax-enabled applications that will support the universe of browsers currently being used, a major step up from the programming experience of even a few years ago when developing a web-based application meant dealing with wide differences in browser capabilities. JavaScript, the client-based logic running in the browser, allows the browser to take on more responsibility for application workflow, since logic traditionally performed server-side can now be accomplished within the browser without the need for posting information back to the web server. CSS and the web page DOM allow JavaScript to dynamically alter the presentation of the web page and provide further power for client-side logic.

The last core component of Ajax, the XMLHTTPRequest object, is what makes Ajax-enabled applications unique from traditional web applications. To see the benefit provided by XMLHTTPRequest, consider this comparative example. The on-line shopping experience at Amazon, http://www.amazon.com, is a traditional, non-Ajax, web-based user experience. To begin shopping, I bring up Amazon in my web browser and decide that today I want to buy a pair of socks. I enter "socks" in the search bar and hit the submit button. At this point, the browser posts my search request ("please show me products related to socks") to the Amazon web server and waits for the server to respond with a new web page displaying the search results. I then browse through the various socks offered by Amazon and decide to buy the nice argyle ones with the green and blue stripes. After I click on my selection, the browser once again posts my request ("I want to buy a pair of argyle socks") to the Amazon web server and waits for the web server to respond with a shopping cart page showing that I have placed a pair of socks in my shopping cart. This same paradigm of viewing a web page, deciding on an action, posting data to the web server and waiting for a resulting page continues on through my entire shopping experience (e.g., placing additional items in the cart, checking out, entering shipping and payment information). Note that each interaction with the web server requires that I wait for the web server to deliver a fresh screen of information and in no way provides a continuous user experience.

Compare the Amazon shopping experience to the viewing of a geographical map in Google Maps, http://maps.google.com. Google Maps has become the poster boy for Ajax-enabled applications for valid reasons. Say that I want to find a better route to one of my clients during rush hour. I begin by entering the address of my office into the Google Maps search bar. Like the Amazon application, this information is posted up to the Google web server and a map is displayed under the search bar. Unlike the Amazon application, however, my browser did not refresh with a new page of information. Instead, the only portion of the web page that refreshes is where the map is rendered (when entering the application, a map of the United States appears; after entering my office address, a map of the local area around my office appears). And this is where the fun begins. I can now click and drag the map to view streets beyond my local vicinity, and as I drag the map, new streets come into view without refreshing the entire page. Furthermore, I can zoom the map in or out and the map renders instantly. The entire user experience is seamless and matches very closely to using a real map; it certainly is a much more fluid experience than viewing a map in a classic web application, where every time I want to view something different on the map, the entire page is refreshed, killing the continuity of my user experience.

So what's behind the magic in the Google Maps application? Like all Ajax-enabled applications, Google Maps is relying on the four technologies outlined above. CSS and the web page DOM allow the client-side JavaScript to update various elements of the web page and control their presentation based on user input, all without the need for the web server to dictate the presentation as happens in a classic web application. The XMLHTTPRequest object allows the JavaScript to load new map information asynchronously into the client-side data model whenever the user wants to view beyond the current store of map information. Since this information is loaded asynchronously whenever the JavaScript needs to update its map information, the web page does not need to be refreshed as it would in the synchronous data transfer paradigm of a classic web application.

In a web application such as Amazon's, the browser has little to no sense of user work flow, relying heavily on the web server to dictate what the user sees and to persist the data model for the user interaction. In essence, in a classic web application, the browser acts as a dumb terminal whereby the entire user experience and work flow are dictated by the web server. Each interaction in the work flow brings a fresh page of information from the web server containing both the presentation and the data. As the browser receives a new page from the web server, it throws away the previous page and starts anew, thereby relegating the entire user experience to the web server (figure 1).


Figure 1: The Classic Web Application Paradigm


Ajax-enabled web applications, on the other hand, deliver entire applications down to the browser, not just content and data, and the browser becomes much more responsible for the user experience (figure 2). The application now stays resident within the browser for the entire user session, with the presentation and data model controlled in large part by the client-side JavaScript. The browser hosts an application, not just content and data delivered by the web server. The initially delivered application contains more JavaScript than a traditional web application (more client-side power naturally dictates that more logic be delivered), but subsequent communications with the web server consist of short bursts of data without presentation elements (i.e., each subsequent communication does not require the web server to dictate the content and presentation of a new web page). Obviously, long-term persistence of data and work flow that occurs server-side must still be enacted outside of the browser, but the logic running within the browser can instigate back-end processing by sending data up to the web server as needed in an asynchronous fashion without breaking the user experience.


Figure 2: The Ajax-Enabled Web Application Paradigm


So how would the Amazon user experience differ if it were Ajax-enabled? For starters, much more of the user experience would be controlled client-side by the JavaScript reacting to user interactions with the web page. After I enter my search for socks sold by Amazon, the JavaScript sends a message to the Amazon web server and after receiving the asynchronous search results renders them dynamically in some portion of the browser. As I look through the search results and select my argyle socks, they are placed in the shopping basket without the browser consulting the web server; the client-side JavaScript updates the web page to show that the socks are now in my shopping basket. Of course, when I want to purchase the socks, loads of back-end processing must be done by Amazon (e.g., credit card charging, warehouse shipment notification, inventory control), but the browser can notify the web server asynchronously of my purchase and be in control of the user presentation throughout the process. In this way, processing is being performed in the correct logical layers as the web server controls back-end processing and the web browser manages front-end presentation and user interaction.

Ajax-enabled applications provide a continuity of user experience and a level of dynamism that is far beyond the traditional web application and equivalent to that found in desktop applications. Of course, with the added power and flexibility comes a higher development cost. In my next article I'll introduce the various libraries and toolsets that help to reduce development cost and discuss more complex examples of Ajax-enabled applications. In the meantime, visit my blog, http://www.berwickheights.com/blog, for further reading on Ajax.

Stuart Jones is president of Berwick Heights Software, Inc. With nearly twenty-five years of software development experience, he offers in-depth expertise in service oriented architecture (SOA), web services (REST, SOAP, WS-*), web-enabled applications, object oriented design, message queuing, streaming media and database design. Dr. Jones also provides consulting services in the areas of business requirements gathering and product design. Before starting his consulting career, Dr. Jones worked on distributed systems technologies for Apollo Computer and was a key member in building Boston Technology into the world's leading provider of voicemail systems. He received his M.S. in Computer Science from SUNY-Stony Brook and a PhD in music composition from Columbia University. He is a member of the Association for Computing Machinery (ACM) and the Institute of Electrical and Electronics Engineers (IEEE).

Berwick Heights Software, http://www.berwickheights.com provides senior-level expertise for web services, enterprise systems, web-enabled applications and relational databases. Along with the architecture, design and implementation of a variety of software systems, the company provides services in project planning, requirements analysis and software feature rollout planning. Started in 1994 by founder Stuart Jones, the company has a long track record of finding the perfect match between business needs and software solutions. Berwick Heights Software is a member of the Independent Computer Consultants Association (ICCA) and the IEEE Consultants Network.