AJAX offers benefits to both end users and developers. For end users, it reduces the “rich or reach” conflict; for developers, it helps in overcoming the constraints raised by HTTP.
Users tend to view desktop applications as a sort of commitment. They install a program, usually from a disk pulled from a costly shrink-wrapped box. The program consumes hard disk space as well as a position in the program menu. The user may need to update the program periodically or perform an upgrade later on to get new features. If the program is proactive about updating itself, the user is confronted regularly with dialogs about accepting patches or downloads. In exchange for this investment of time, money, and energy, the user gets repaid by an application that is able to leverage the operating system and machine resources. It is a rich application. It has local storage capabilities, offers quick response times, and can present a compelling and intuitive graphical user interface.
More and more applications are accessible from the web browser, where the full resources of the hardware and OS are not available, but the user commitment of a desktop application is not required. Over the years, interacting with a web application has meant a predictable pattern for users. They click a link in the page and the browser flashes while the user waits until the screen is repainted (the dreaded post back). This cycle is repeated again and again. The user looks at what is presented on the page, interacts with it, and clicks somewhere. The browser produces an audible click for feedback and begins to post back to the server. The screen of the web browser flashes blank and some icon spins or flashes while the user waits for a new version of the page to be returned from the server. Many times, the new version of the page is almost exactly the same as the previous version, with only part of the page being updated. And then the cycle begins all over again. This has a sluggish feeling even when the user has a high-speed network connection.
Often, the first question to arise when starting a new development project is what type of application it will be. Should it be a desktop application or a web application? This is a key decision because it has historically dictated a lot about the nature of the application and the development problem space. Many developers are now choosing to build web applications by default unless something about the application dictates that it must be a desktop install. If it must run offline or if it requires a user interface that is complex to achieve in HTML, targeting the web browser may be ruled out, and the choice to write a standalone application is forced.
Developers have a difficult job writing modern web applications due to the inherent worldwide-web functionality constraints imposed by the use of the Hypertext Transfer Protocol (HTTP) and the way browsers use it. HTTP is a stateless protocol. The web browser requests a page, possibly carrying some querystring or form input parameters, and the server processes the request and sends a response that includes HTML-rendered content. The server can only react to the information supplied in the current request and doesn’t know, based on the information in the request itself, details about the path the user took to get to the current view. When the response is rendered, the connection may be broken and the server won’t have any information to preserve for the next request. From the server’s perspective, it is simply listening for requests to come in from any browser anywhere and then reacting. The browser issues a request to the page and receives an HTML page in response. It uses the HTML it receives to render the user interface. The user interacts with the page, and, in response, the browser clears the screen and submits a new request to the server, carrying some information about user input or actions. Again, a complete HTML page is returned. The browser then presents the new version of HTML. Fundamentally, the HTTP protocol is stateless. The server gets a request and responds to it. The request carries limited information about the ongoing conversation that is happening between client and server.
AJAX makes this much better. AJAX breaks this pattern by updating portions of the page separately, via partial page rendering. Figure 1-1 shows a typical non-AJAX series of browser and server interactions. Each request results in a full page rendering, and, in response, the browser updates the user’s entire view.