Web applications are sometimes considered inferior to conventional applications—that is, applications that run natively on your chosen operating system. That mindset is easy to develop. Imagine a conventional application that has a form that users can use to input data and have it stored in a database. A host of features are common in such conventional applications, such as real-time validation, seamlessly fast response times, and real-time error reporting.
Compare all that to a comparable web application. Users input data into the form and submit it. There is some real-time validation that you can do with JavaScript, but often with such web applications the server is responsible for comprehensive validation. The experience is disjointed when users click the form's submit button: The page has to reload with new data from the server, so not only does the page flicker, but it has to be downloaded again. If an error occurs, users don't know it until the page is completely loaded in the browser.
There are a variety of factors that contribute to the differences between conventional and web applications, but perhaps the largest hurdle web developers face is the HyperText Transfer Protocol (HTTP). The Internet relies upon several components in order to function, and probably the most important component is HTTP, a request-response protocol. When you open a browser and go to any website, your browser sends an HTTP request to the website's server to retrieve an HTML page. The server processes your request and sends an HTTP response back to your browser. If the server is able to fill your request, the response contains the HTML of the page you requested. As the browser finds images, CSS, and JavaScript files referenced in the HTML, it has to make additional HTTP requests for those resources. If, for some reason, the server is not able to fill your request, its response is a simple error code.
It is the request-response nature of HTTP that results in web applications that feel disconnected and disjointed. Every time users click a link or a button in a form, the browser sends a request and waits for a response from the server. While the browser waits, users typically see a blank web page. Users with a broadband connection usually see a flicker of white before the browser loads the requested HTML. Regardless, web applications, by default, still lack the seamless, real-time feel of conventional applications.
Because of this, web developers in the early 2000s began to develop new techniques to make their web applications behave more like conventional applications. These techniques enhanced the applications' performance and usability by enabling them to send and receive data behind the scenes without reloading the entire page.
At the very heart of these techniques was JavaScript and its capability to use hidden frames and a component developed by Microsoft called XMLHttpRequest to make HTTP requests transparent to users. Way back then, the techniques for making transparent HTTP requests were simply referred to as remote scripting. Today they're referred to as Ajax.
The simplest definition of Ajax is the use of JavaScript to send and receive data using HTTP without reloading the page. The term originates from an article written by Jesse James Garrett in February 2005 entitled "Ajax: A New Approach to Web Applications" (http://www.adaptivepath.com/ideas/essays/archives/000385.php). In his article, Garrett stated that the gap between conventional desktop applications and web applications was closing. He pointed to Google's Suggest and Maps as groundbreaking web applications because of their rich experiences and responsiveness.
In his article, Garrett also coined the term Ajax. It originally stood for Asynchronous JavaScript + XML because, at the time, XML was the accepted format for client/server communication. XML is still used, although other formats have proven more efficient. However, the term Ajax is now defined as the use of JavaScript to request and receive data from the server without refreshing the page, regardless of what format the data is in. It allows developers to create applications that behave like rich and responsive conventional desktop applications.
A textual representation of Ajax is insufficient, so let's look at some actual uses on the Web. Garrett's examples of Google's Suggest and Maps are still relevant, so let's look at them.
Google Suggest is an application that stayed in Google Labs for quite some time before being pushed into full-time service on the main search page. It offers suggestions for search terms as users type. With each keystroke, Google Suggest uses Ajax by sending an HTTP request to the server to get search suggestions based on the text contained within the search box. Figure 31-1 shows Suggest in action.
It's fast and responsive, and it gives users a better experience when they're using Google's search—all without reloading the page.
After Google purchased Keyhole and rebranded it as Google Earth, it quickly released a web-based version called Google Maps (http://maps.google.com). Google Maps incorporates the use of Ajax, as well as DHTML, to provide an experience rarely found in web applications. Look at Figure 31-2 for the default page of Google Maps.
Entering a location in the textbox and clicking the Search Maps button does not reload the page. Instead, Maps uses Ajax to send and receive data based on the search criteria and dynamically loads the map images in the main area of the page.
The map area is completely interactive. You can drag the map around and zoom in and out using the mouse's scroll wheel. The responsiveness and interactivity rival those of the desktop-based Google Earth. While DHTML techniques are used extensively, Google Maps' success is due to Ajax.
So you've seen some remarkable web applications that are remarkable because of Ajax. What do you need to get started with it?
First, you need a web browser that can make transparent HTTP requests and do something with the response. The old techniques of using hidden frames (which is not covered in this book) can be used in IE4+, but the most popular Ajax technique, using the XMLHttpRequest object, can be used only in browsers that support XMLHttp. These browsers are:
Internet Explorer 5+
Firefox 1+
Opera 9+
Safari 2+
Chrome 1+
Second, you need a webserver because Ajax relies on HTTP communication. The pages in which you want to use Ajax must be served from an actual webserver; otherwise the HTTP requests will fail.
There are several webservers freely available to you, but two stand out and will suit your needs:
The Apache HTTP Server is the most popular webserver in the world. The majority of the websites found on the Internet are served by Apache, and you can find a version for just about every operating system. Apache isn't for the faint of heart, however. Configuring the server beyond the default settings requires editing one or more text files. That being said, the default settings are generally fine for developing applications on your computer.
Microsoft's IIS has been freely available to users since Windows 2000, but only users of the Professional/Business or higher versions of XP, Vista, and Windows 7 were able to install it and use it on their machines. IIS is configured through a graphical user interface.
There is a version of IIS that runs on all major Windows operating systems (XP, Vista, and 7) called IIS Express. At the time of this writing, it is only included in Microsoft's WebMatrix beta; no stand-alone version of IIS Express is available to download.
The choice is yours; either server will enable you to learn Ajax in the upcoming lessons.
To get the sample code files, download Lesson 31 from the book's website at www.wrox.com.
Note
Please check the DVD for Lesson 31: It walks you through the installation of Apache on OS X and Windows and the installation of IIS.
