Adding Ajax

Despite all of the recent interest, most of these technologies have been around for about a decade. Why the interest now?

Ajax is more than just a set of technologies—it's also a determination to take web pages and applications in new directions. We've had this determination in the past, but we never had the tools with which to build these applications. Now, the specifications that were all new ten years ago have reached maturity, and, even more importantly, have broad support in web browsers. New specifications continue to appear, and tool makers cooperate much more than they did a few years ago.

Years ago when web developers made first tentative motions to add interactivity to web pages, we were constrained by browsers that supported completely different models, and at times, even different scripting languages. The use of Cascading Style Sheets (CSS) as a uniform way of adding presentation to a page was hampered by differing interpretations, not to mention proprietary extensions.

Now, CSS has almost universal support, and though there are still "quirks" in the system, most browsers support most of the specifications, and we're at a stage where what we can do exceeds what we can't do. As for scripting, through the efforts via the ECMA standards organization, we have a released version of JavaScript known as ECMAScript that is accepted and supported in all the major tools, in the Web and out.

The markup has become more sophisticated, and we're moving from the HTML with its vagaries to XHTML with its discipline. We're also adding new XML vocabularies, such as Scalable Vector Graphics (SVG)—a way of adding interactive graphics that don't depend on plug-ins and external objects. This is matched by the introduction of the Canvas object, both separate from any markup and included as part of the upcoming work on HTML5—the intermediate step between the older HTML and the more rigorous XHTML.

Yet we haven't completely abandoned the old proprietary objects. Now, rather than being implemented in one browser, their use is becoming universal. One such object is XMLHttpRequest, which allows us to make calls to web services directly from pages and then process the results dynamically without ever having to reload the page.

What does that mean to developers and consumers? It means being able to read an article, click it, and then edit it in place—all in the same page. We can also delete rows from a table and have the deletion happen instantaneously. Updates, too.

We can also add categories to a photo without reloading either the page or the photo. Or expand that photo to a larger size just by clicking on a thumbnail.

Our use of web forms has changed considerably. We can make a selection in one list and have another selection list automatically populated. We can sort a table using drag-and-drop, collapse fields to make room, or click on tabbed pages to fill in other parts of a large form or to see other information, again without having to reload the page.

Of course, what we think of as a "page" has changed, and there's good and bad with this new viewpoint. It's difficult to figure out how much to charge for ads by "page view" when a hundred pages can be loaded without once using a refresh. Search engine companies don't particularly understand dynamically generated links, and neither do screen readers. As for cases where scripting is disabled or nonexistent, well, that's a nonstarter when it comes to Ajax, with its dependence on JavaScript.

That's where the concept of progressive enhancement enters into the picture. Coined by Steven Champeon, progressive enhancement is based on the philosophy that Ajax effects are added as enhancements to existing web technologies, rather than as replacements. In other words, you still build the more traditional web application that's based on submitting a form to update a table, but then you enhance it by adding the capability to update the table with changes to the form fields without actually having to submit the form.

That tabbed page can become a series of vertical sections within a page if scripting is disabled; the data will still be there, just arranged differently. A slideshow can serve its content whether requested by an application created in PHP and residing on a Unix box, or via a JavaScript call from within Firefox, Safari, or Internet Explorer.

With the use of progressive enhancement, it doesn't matter if scripting is disabled or not, because no functionality is lost; it's just different. At the same time, the efficiencies that Ajax can add to a web application—and they are numerous—can still be provided to the 80 percent or so of people who do use an applicable browser and who do have scripting enabled.

The best thing of all for you? You're already halfway there.

Download Link