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.
Figure 8-1. The traditional unload/reload cycle
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.