So how do you code an AJAX Web page?

See hands-on examples for creating lighter, faster interactive sites

This article is excerpted from the soon-to-be-published book AJAX: Creating Web Pages with Asynchronous JavaScript and XML by Edmond Woychowsky, copyright Pearson Education Inc. Reprinted with permission from Pearson Education, all rights reserved. The book is part of the Bruce Perens’ Open Source Series.

A little more than a year ago, an article by Jesse James Garrett was published describing an advanced Web development technique that, even though individual components of it have existed for years, few Web developers had ever stumbled across. I can guess the reason for this lack of knowledge; basically, in the last few years, the need to produce measurable results has gotten in the way of the need to practice our craft. Or, as a former manager of mine would say, it's "that mad scientist stuff," except, as I recall, he used another word in place of stuff. Unfortunately, nine times out of ten, the need to produce measurable results gets in the way of "that mad scientist stuff."

However, it's the tenth time that's important. The article didn't stop at just describing the technique; it went on to say that Google used the very same technique. Invoking that single name, Google, was enough to change a point of view. Quicker than you could say, "Igor, the kites!" the phrase "that mad scientist stuff " morphed into "Why aren't we doing it this way?" The reason for this change of perception is that the name Google made this a technique that could produce measurable results. All it took was that single name, Google, to make using the XMLHTTP Request object so that the browser could communicate with the server without the page ever unloading and reloading into an acceptable practice.

This article introduces you to that practice, the practice of updating Web pages with information from the server. Beyond the XMLHTTP Request object, which has been around for several years as a solution looking for a problem, there is nothing weird needed. Basically, it is how the individual pieces are put together. When they're put together in one way, it is nothing more than a pile of parts; however, when put together in another way, the monster essentially rises from its slab.

Not a mockup

A few years ago, I demonstrated an application that did what I just described. The demo ran for more than 2 hours with the same questions repeated over and over.

"It's a mockup, right?"

"No, it is the actual application."

"It can't be. The screen doesn't blink."

"That's because XML, HTTP and SOAP are used to get the data directly from the server. JavaScript then updates only the parts of the page that have changed."

"It's a mockup, right?"

And so on. It took the client more than 2 hours to realize that the database was actually being updated without the page "blinking," as he referred to it. 

A technique without a name

Now, if I had been smart, I would have given the technology a name then and there, and thus ensured my place in Web history, shutting up the client as well. After all, a name is a thing of power, and the client, not wanting to sound stupid for not knowing what the acronym meant, would have saved more than two hours of my life that were spent re-enacting the scene of peasants with pitchforks from the 1931 version of Frankenstein, minus the tongs. Unfortunately, I drew an absolute blank and just called it as it was.

With apologies to the people who make the cleanser and the detergent, legend has it that the original AJAX was the second most powerful of the Greek warriors at Troy. Even though he had some issues (who in The Illiad didn't?), his strength and skill in battle were second to none (well, OK, second only to Achilles). In naming the technology AJAX, Jesse James Garrett gave the technology both AJAX's strengths and issues. 

1 2 3 4 5 6 7 Page 1
Page 1 of 7
It’s time to break the ChatGPT habit
Shop Tech Products at Amazon