Anatomy of an Ajax Application
- The Need for Ajax
- Introducing Ajax
- The Constituent Parts of Ajax
- Putting It All Together
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
What You'll Learn in This Chapter:
- The Need for Ajax
- Introducing Ajax
- The Constituent Parts of Ajax
- Putting It All Together
In this chapter you will learn about the individual building blocks of Ajax and how they fit together to form the architecture of an Ajax application. Subsequent chapters will examine these components in more detail, finally assembling them into a working Ajax application.
The Need for Ajax
In the following parts of the book, we shall discuss each of the core components in detail.
Before discussing the individual components, though, let's look in more detail at what we want from our Ajax application.
Traditional Versus Ajax Client-Server Interactions
Chapter 1 discussed the traditional page-based model of a website user interface. When you interact with such a website, individual pages containing text, images, data entry forms, and so forth are presented one at a time. Each page must be dealt with individually before navigating to the next.
For instance, you may complete the data entry fields of a form, editing and re-editing your entries as much as you want, knowing that the data will not be sent to the server until the form is finally submitted.
Figure 3.1 illustrates this interaction.
)
Figure 3.1 Traditional client–server interactions.
After you submit a form or follow a navigation link, you then must wait while the browser screen refreshes to display the new or revised page that has been delivered by the server.
As your experience as an Internet user grows, using this interface becomes almost second nature. You learn certain rules of thumb that help to keep you out of trouble, such as "don't click the Submit button a second time," and "don't click the Back button after submitting a form."
Unfortunately, interfaces built using this model have a few drawbacks. First, there is a significant delay while each new or revised page is loaded. This interrupts what we, as users, perceive as the "flow" of the application.
Furthermore, a whole page must be loaded on each occasion, even when most of its content is identical to that of the previous page. Items common to many pages on a website, such as header, footer, and navigation sections, can amount to a significant proportion of the data contained in the page.
Figure 3.2 illustrates a website displaying pages before and after the submission of a form, showing how much identical content has been reloaded and how relatively little of the display has actually changed.
)
Figure 3.2 Many page items are reloaded unnecessarily.
This unnecessary download of data wastes bandwidth and further exacerbates the delay in loading each new page.
The Rich User Experience
The combined effect of the issues just described is to offer a much inferior user experience compared to that provided by the vast majority of desktop applications.
On the desktop, you expect the display contents of a program to remain visible and the interface elements to respond to commands while the computing processes occur quietly in the background. As I write this chapter using a word processor, for example, I can save the document to disk, scroll or page up and down, and alter font faces and sizes without having to wait on each occasion for the entire display to be refreshed.
Ajax allows you to add to your web application interfaces some of this functionality more commonly seen in desktop applications and often referred to as a rich user experience.