This model was just fine in the beginning of the Web age when pages contained little more
than formatted text, hyperlinks, and some images. The success of the Web has prompted
users to ask for increasingly more powerful features, and it has led developers and designers
to create more sophisticated services and graphics. As an example, consider advertising.
Today, most pages—and often even very simple pages, such as blog pages—include ad rotators
that download quite a bit of stuff on the client.
As a result, pages are heavy and cumbersome—even though we still insist on calling them
“rich” pages. Regardless of whether they’re rich or just cumbersome, these are the Web pages
of today’s applications. Nobody really believes that we’re going to return to the scanty and
spartan HTML pages of a decade ago.
Given the current architecture of Web applications, each user action requires a complete
redraw of the page. Subsequently, richer and heavier pages render slowly and as a result produce
a good deal of flickering. Projected to the whole set of pages in a large, portal-like application,
this mechanism is just perfect for unleashing the frustrations of the poor end user.
Although a developer can build a page on the server using one of many flexible architectures
(ASP.NET being one such example), from the client-side perspective Web pages were originally
designed to be mostly static and unmodifiable. In the late 1990s, the introduction of
Dynamic HTML first, and the advent of a World Wide Web Consortium (W3C) standard for
the page document object model later, changed this basic fact. Today, the browser exposes the
whole content of a displayed page through a read/write object model. In this way, the page
can be modified to incorporate changes made entirely on the client-side to react to user inputs.
(As we’ll see, this is a key factor for AJAX and ASP.NET AJAX solutions.)
the Web.
