14.0 Introduction

JavaScript-enabled browsers have always provided a level of control over page content so that scripts can influence what the visitor sees on the page. But it took sophisticated document object models and the automatically reflowing page features of browsers such as Internet Explorer 4 and Netscape 6 to give scripters carte blanche over the page content, both during page loading and after (within security boundaries, of course). This chapter focuses on how to generate content that goes into the page and manipulate the existing content of a page. The next chapter picks up where this one leaves off, showing several specific applications of these powers.

Web programmers who spend most of their time coding for server processing frequently overlook the power that a scripted client can provide to an otherwise dead and dull web page. Their (quite logical) train of thought is to have the server work its magic to assemble content that shoots its way to the browser, where users read it and perhaps enter various things into forms. The browser then sends the form back to the server, where more programming processes the user input. It's powerful stuff on the server, and applications involving transactions and database access need that power running right where it is.

Users, however, are accustomed to direct manipulation of data and instant feedback from their experience with standalone applications running on their computers. When you change the font characteristics of a selection in a word-processing document, the change is instantaneous; when you sort the columns of a spreadsheet, the sorting occurs in a blink of the eye. Waiting for a submission to the server, remote processing, and delivery of the reconstituted page is not fun, even when you have a broadband connection to the Internet.

Unless the content that needs manipulation is updated so frequently in the server database that it requires constant updating on the client, it is likely that a set of retrieved data can be delivered with the document such that interactivity with the data—transformations of the rendering in particular—can be handled entirely on the client. Not only is the response instantaneous, but you also free the server from some of its burdens.

This chapter and the next are all about pages that may look entirely different from the way they were delivered by the server because the user is able to sort tables, experiment with the body text content, and even filter content based on user preferences. Power to the people, in a sense.

Only time will tell if server-centric developers will feel comfortable enough with client-side dynamism to take full advantage of it. Early horror stories about incompatibilities among browser generations and brands are increasingly less relevant as the installed base of W3C DOM-capable browsers reaches critical mass.