Classic Web Applications VS AJAX-Based Web Applications

Classic Web Applications
Today Web applications work by submitting user-filled forms to the Web server and displaying the markup returned by the Web server. The browser-to-server communication employs the classic HTTP protocol. As is widely known, the HTTP protocol is stateless, which means that each request is not related to the next and no state is automatically maintained. (The state objects we all know and use in, say, ASP.NET are nothing more than an abstraction provided by the server programming environment.)

Communication between the browser and the Web server occurs through “forms.” From a user’s perspective, the transition occurs through “pages.” Each user action that originates a new request for the server results in a brand new page (or a revamped version of the current page) being downloaded and displayed.

Let’s briefly explore this model a bit further to pinpoint its drawbacks and bring to the surface the reasons why a new model is needed.

Send Input via Forms
Based on the URL typed in the address bar, the browser displays a page to the user. The page is ultimately made of HTML markup and contains one or more HTML forms. The user enters some data, and then instructs the browser to submit the form to an action URL. Using the local Domain Name System (DNS) resolver in the operating system, the browser resolves the specified URL to an IP address and opens a socket. An HTTP packet travels over the wire to the given destination. The packet includes the form and all its fields. The request is captured by the Web server and typically forwarded to an internal module for further processing. At the end of the process, an HTTP response packet is prepared and the return value for the browser is inserted in the body.

Get Output through Pages
When a request is made for, say, an .aspx resource, the Web server passes it on to ASP.NET for processing and receives the resulting HTML markup in return. The generated markup comprises all the tags of a classic HTML page, including , , and

. The page source is embedded in the HTTP response and tagged with a Multipurpose Internet Mail Extensions (MIME) type to instruct the browser how to handle it. The browser looks at the MIME type and decides what to do.

If the response contains an HTML page, the browser replaces the current contents entirely with the new chunk of markup. While the request is being processed on the server, the “old” page is frozen but still displayed to the client user. As soon as the “new” page is downloaded, the browser clears the display and renders the page.

Capabilities and Drawbacks
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

Dynamic HTML is a quantum leap, but alone it is not enough to further the evolution of the Web.


AJAX-Based Web Applications
To minimize the impact of page redraws, primitive forms of scripted remote procedure calls (RPC) appeared around 1997. Microsoft, in particular, pioneered this field with a technology called Remote Scripting (RS).

RS employed a Java applet to pull in data from a remote Active Server Pages (ASP)-based URL. The URL exposed a contracted programming interface through a target ASP page and serialized data back and forth through plain strings. On the client, a little JavaScript framework received data and invoked a user-defined callback to update the user interface via Dynamic HTML or similar techniques. RS worked on both Internet Explorer 4.0 and Netscape Navigator 4.0 and older versions.

Later on, Microsoft replaced the Java applet with a Component Object Model (COM) object named XMLHttpRequest and released most of the constraints on the programming interface exposed by the remote URL-for example, no more fixed ASP pages. At the same time, community efforts produced a range of similar frameworks aimed at taking RS to the next level and building a broader reach for solutions. The Java applet disappeared and was replaced by the XMLHttpRequest object.

What Is AJAX ?
The term AJAX was coined in 2005. It originated in the Java community and was used in reference to a range of related technologies for implementing forms of remote scripting. Today, any form of remote scripting is generally tagged with the AJAX prefix. Modern AJAX-based solutions for the Windows platform are based on the XMLHttpRequest object. Google Maps and Gmail are the two most popular Web applications designed according to AJAX patterns and techniques. For AJAX, these were certainly the killer applications that established its usefulness and showed its potential.

Two combined elements make an AJAX application live and thrive. On one hand, you need to serve users fresh data retrieved on the server. On the other hand, you need to integrate new data in the existing page without a full page refresh.

Browsers generally place a new request when an HTML form is submitted either via clientside script or through a user action such as a button click. When the response is ready, the browser replaces the old page with the new one.

The chief factor that enables remote scripting is the ability to issue out-of-band HTTP requests. In this context, an out-of-band call indicates an HTTP request placed using a component that is different from the browser’s built-in module that handles the HTML form submission. The out-of-band call is triggered via script by an HTML page event and is served by a proxy component. In the most recent AJAX solutions, the proxy component is based on the XMLHttpRequest object; the proxy component was a Java applet in the very first implementation of RS.

Update Pages via Script
The proxy component (for example, the XMLHttpRequest object) sends a regular HTTP request and waits, either synchronously or asynchronously, for it to be fully served. When the response data is ready, the proxy invokes a user-defined JavaScript callback to refresh any portion of the page that needs updating.

All browsers know how to replace an old page with a new page; until a few years ago, though, not all of them provided an object model to represent the current contents of the page. (Today, I can hardly mention a single modern, commercially available browser that doesn’t expose a read/write page DOM.) For browsers that supply an updatable object model for HTML pages, the JavaScript callback function can refresh specific portions of the old page, thus making them look updated, without a full reload.

The Document Object Model
The page Document Object Model (DOM) is the specification that defines a platform- and language-neutral interface for accessing and updating the contents, structure, and style of HTML and XML documents. A recognized standard ratified by the W3C committee, the DOM is now supported by virtually all browsers. The DOM provides a standard set of objects for representing the constituent elements of HTML and XML documents. All together, these objects form a standard interface for accessing and manipulating child elements of HTML pages and, more in general, XML documents.

Note that although the first working frameworks for remote scripting date back to a decade ago, the limited support browsers have had for dynamic changes in displayed documents slowed down the adoption of such technologies in the industry.

Source of Information : Microsoft Press Introducing Microsoft ASP .NET AJAX