To get back to contemporary terminology, what this means in practice is that rather than creating a single page from fairly complex components on the server and needing to maintain this information on the server, you instead push the components onto the client, and each component in turn becomes responsible for its own interactivity with the server. The state of the application in turn either ends up residing in each component, or in a client-side "model" server which all of the other components interact with.

The distinction between these two forms is important (and I'll get to them momentarily) but one of the immediate upshots of this is that the server can in fact become dumb ­ it doesn't need, in either situation, to retain anywhere near as much state as it did before for that particular session or application. This has a number of immediate consequences:

The server needs to send each component only once then let the component handle the presentation layer directly rather than doing this task itself for each component every time some aspect of state changes. This makes the server-side code easier to write and more modular to maintain.

The server can standardize on a single given transport protocol that the various components can use, meaning that you have less need for extensive server-side development of "translators" between databases and a whole host of different presentation formats.

The server layer becomes thinner ­ more a generic conduit between the database and the client than a large set of custom presentation and content pages, and in general this translates into an ability to generate more sessions for the same resources.

From the client standpoint, however, things tend to get potentially more complex. (The third law of programming thermodynamics ­ complexity never disappears, it only moves around). Browsers are perhaps more homogenous with regards to interfaces than they were five years ago (especially now that Internet Explorer 7 is on the horizon), which in turn means that the amount of specialization code necessary to write to the diversity of browsers has shrunk. It hasn't disappeared entirely yet, though the good news is that the benefits of maintaining a uniform set of interfaces appears to have sink in to just about all of the major players.

Moreover, Google, Yahoo, and others have been working on creating standard frameworks to handle the small things (such as Sarissa, which provides hooks into the XSLT transformer objects on most browsers and supports a limited JavaScript-enabled transformer for those few platforms that don't have XSLT support fully enabled), making for a homogenous generalized environment without going overboard in trying to build extensive (and potentially restrictive) frameworks. These efforts are essential, since they provide the last homogenization/standardization in the browser space to use browsers as independent platforms for applications.

Send Down a Couple More Red Shirts AJAX and Web 2.0
This point in turn raises another and in many ways more crucial one. The AJAX movement is not about calling home without refreshing the page, is not about cool widgets appearing in Web pages, displaying the latest feeds from Slashdot or neat drag-and-drop effects, though certainly all of these have a place. Instead, the primary driving motivations of AJAX is the fundamental belief that the browser is ultimately the last platform, that the Web will not truly be universal until browsers can do everything that a standalone desktop environment can do, regardless of whether there's a multi-colored flag, a fruit, or an aquatic fowl on the start-up screen.

This shouldn't be a radical point, but somehow it is. Your customers, the employees at your company, and you individually spend a huge amount of time in front of Web browsers, which are in turn becoming the primary interfaces for all modalities of communication. I haven't used a standalone e-mail application in months, most of my IM communication occurs in a browser context, and increasingly my production tools exist as extensions to my Web browser. For many people, going from a Web interface to a standalone application seems a step backwards, forcing them from their primary point of contact for news, documentation, and communication into an isolated environment where they have to run the browser in the background and click back and forth to shift between the two.

AJAX has gained momentum not because someone put a Message Pump on a browser with 15% of the market, but because this move has basically catalyzed a reaction among the other browser vendors and projects and caused the Web developer sphere to shout "Enough is enough! If certain parties won't get their act together then we will solve this problem ourselves!"

Movements are funny things, especially in technology. No one takes them seriously at first ‹ there's no press releases, no aging rock star starts singing the praises of the product, usually just a handful of people who recognize that there is a problem and that the "market" isn't rushing to solve it because there's no immediate money in it.

Often there's a single event that sparks the whole thing ­ a programmer gets frustrated because no one can find information about physics papers written at the research center where he works and puts up a small set of tools for free, a grad student who sends out a note saying that because he can't afford to use the university's Unix implementation he's writing his own free one, and would anyone else like to help...events that occur almost daily now that are only important in hindsight. People pitch in not for glory or money (because there's seldom much of either) but because most software developers are a lot like Scotty ­ they do things because they need to be done and the problems are interesting enough to them to make it worthwhile.

Yet these sparks are almost invariably observable only in retrospect ­ and what's more, such sparks are much like those that start a forest fire ­ there may be dozens or hundreds of them flickering around a campfire that go nowhere because conditions aren't right, but if the weather has been dry for too long, if the underbrush is overgrown and primed then any one of those sparks (or many of them) may be responsible for the raging conflagration.

(This same argument, by the way, is one of the most compelling I've seen against software patents, as important as they may seem to CEOs and investors ­ good ideas can only exist in a proper context ­ too early and there isn't enough technology to support the concepts, too late and the ideas become obsolete. Because software developers live in a medium of common (and commonly available) ideas, it's very rare for a truly unique idea to actually occur in this space.)

About now conditions are ripe for AJAX to occur, if by AJAX we mean the consolidation of a baseline platform of XML, JavaScript, and connectivity support across multiple browsers, the development of a methodology for building distributed applications across the Web and agreements on the part of enough market movers to abide by common conventions to create an established framework.

It's arguable as to whether this should be called Web 2.0. It's a nice catch-phrase, and I've written a few articles myself on what Web 2.0 really means. However, I think that this tends to mask that what's really going on here is essentially a continuity with what happened in the 1990s, after taking a few steps back to rejig some of the basics...most notably XML.