At a high-level of abstraction, Web applications look like a state machine where the user activity determines the next state. A graph of connections form all possible state transitions. What's a state, ultimately? A Web page-for example, an ASP.NET page-represents a state of the application. Moving from one state to the next implies that a brand new page is displayed. This model was good enough in the early days of the Web when applications were a collection of mostly static pages with limited graphics, no advertising, no animation and no multimedia contents. A decade ago, Microsoft started investigating technologies to make the state transition of a Web page more seamless and smooth. A first result was Remote Scripting (RS), which at its core, was nothing really different from the today's AJAX. But over the last decade, the creation of rich and powerful "tools" including XMLHttpRequest, Web services, and a standardized DOM has moved the goal of a dynamic web model into a practical, cross-platform reality.
With AJAX, you can achieve two key goals-refreshing portions of the page and invoking server-side code sending and receiving rich data thanks to a type system powered by JSON (JavaScript Object Notation). You might not notice it at first, but these two goals also herald two diametrically opposed, but not mutually exclusive, approaches to AJAX programming.
To refresh a portion of the page, you don't need to change much of your programming model and style. You just work with a bunch of new controls and let the back-end of your AJAX framework (be it ASP.NET AJAX Extensions or any other freely available technologies out there) to generate any script necessary to make the engine go. To invoke a server method, instead, you need a client-centric programming model. You need to take advantage of the full power of the JavaScript language.
This first approach seems ideal if you need to add AJAX capabilities to an existing application or just to a subset of pages. You don't need to rewrite anything; you just edit pages by identifying regions that need separate update logic and wrapping those into AJAX panels. It's a kind of zero-cost AJAX and is tremendously effective.
Second, even more effective from a purely traffic-oriented standpoint is any solution that leverages the JavaScript engine. The traffic between the browser and Web server is limited to just input parameters and return values; no viewstate, no event validation data, no extra burden of any sort. A client-centric approach requires a significant reengineering of existing pages and makes inevitable to design new pages in accordance with new patterns and principles.
A third possibility that somehow falls in between the two is represented by third-party suites of controls. There are some good ones on the market: ComponentArt's WebUI, Infragistics' NetAdvantage, Telerik's r.a.d.Controls just to name a few. [Ed: See Bringing the Desktop Application to the Web]
All of them are suites of rich UI server controls with an optional client-side object model to allow JavaScript programming. These controls shield you from the details of AJAX programming and propound a task-oriented approach to AJAX programming. Instead of reasoning in terms of updatable regions or page methods, you just think of UI features and user tasks. Need a pop-up menu, a tree-view, a smart grid? The libraries have this and much more and incorporate AJAX functionalities in any controls. In this way, Web pages get ajax-ified under your nose and you may not even realize it.
AJAX is a reality today and everybody can afford it. The real issue for developers and Web architects is finding out the most effective way to bring it into new and existing applications.
