8.1. Traditional Versus Ajax Websites

Before we go any further, this is a good time to review how the average website works, if only to see the contrast between it and Ajax websites. With a traditional website, it isn't unusual for the same page to go through the unload/reload cycle several times before progressing to the next logical page. A number of valid reasons explain why these unload/reload cycles occur, ranging from HTML select objects whose contents are based on other select objects to simply bad input caught on the server side. In the end, the result looks quite a lot like Figure 8-1.

Even in the early days, when the paint wasn't yet fully dry on the World Wide Web, the unload/reload cycle got old pretty quick, especially at dial-up speeds. Now with the improved bandwidth available, things are different; it is old right from the start. For example, several years ago, I worked as a consultant for a company that was trying to get a handle on the whole "web thing," as they referred to it. Their approach was to wave a magic wand, and, "Poof!"a CICS programmer was now a web developer. Although this approach worked, after a fashion, it led to some rather interesting web development standards.

Their standard went pretty much along the lines of trying to make web pages as much like the mainframe CICS pages as possible. These standards were a combination of the weird and the scary. An example of the weird was that initially all scrolling, regardless of the direction, was forbidden because it was thought to be unprofessional. This meant that it was necessary to break up tabular web pages into single pagesized chunks and provide the user with some means of navigation.

On the other hand, some of the scary things were really scary. For example, they believed that there was nothing wrong with giving scripts write permission to the web server. Let's say, for instance, that a shopping cart for the web application was needed. Following the local standards, it was perfectly acceptable for the "temporary" shopping cart to be written to the web server. The rationale was that it was easier to work with flat files than to store information either on the client side or in a database table. Time permitting, they also could write a "batch job" to clean up the web server of abandoned shopping carts.

The shopping cart was actually coded in the manner that I described, but, thankfully, it was an absolute pig. It was both slow and temperamental, with items both appearing and disappearing seemingly at random in the shopping cart. In fact, my wife would probably say that it was like shopping with me: "Where did those Parmesan Goldfish and Double-Stuff Oreos come from?"

I still shudder whenever I think that there was actually a chance of that page making it into a production environment and that management thought it was a perfectly acceptable design. Fortunately, the individual who developed that application was needed to fix a mainframe production problem, so I was assigned the task of making it work. I spent maybe a total of 10 minutes attempting to determine what was going wrong before deciding to try a somewhat more modern approach.

The initial concept was to make the client work for a living and to pad my resumé with a whole bunch of things that I had only played with in the past, such as the XMLHttpRequest object. The result was a separation between the presentation layer and the web server; it was easily ten times faster than any of their existing web pages. It could have been faster yet, but, unfortunately, I was unable to bypass the draconian rules that were in place regarding stored procedures. Stored procedures were, in a word, forbidden, being considered as both too confusing to write and of no use. Argh! I was one step away from a three-tiered architecture.

Regardless of the frustration that I felt at the time, I did achieve something wonderful by stumbling upon what was years later to be named Ajax. The shopping cart application was both similar to and different from the site's existing pages. The similarity to the existing applications was akin to the similarity between a soufflé and scrambled eggs. Many of the ingredients are the same; the real differences come from the technique used in putting the ingredients together. Probably the easiest way to illustrate this difference is to use a picture, such as the one shown in Figure 8-2.

Very different from Figure 8-1, isn't it? Instead of a page seemingly unloading and reloading forever, the single page communicates directly with the web server. This greatly reduces the need for the unload/reload cycle, which has a lot of overhead. Think of it in terms of a trip to the moon. What if the Apollo astronauts needed to bring every necessity with them? Air, water, food, and anything else that was required had to be trucked along with them from the Earth to the moon. Now imagine for a moment that the moon had a breathable atmosphere and McDonald's. All of a sudden, a trip to the moon becomes almost as easy as a trip to Florida.

Ajax does something similar by establishing an infrastructure on the client side. This infrastructure can be as simple or as complex as you want. In fact, now is a good time to see what goes into building our Ajax infrastructure. So queue the storm sound effects and put on the lab coat, and let's get our hands dirty.