Programming Microsoft ASP.NET 4 - Dino Esposito [436]
There are many benefits to writing Ajax applications. First and foremost, the page that triggers the call remains up and running and refreshes its Document Object Model (DOM) with the freshly downloaded data. No page replacement occurs, and the overall user experience is smooth and continual. In addition, you can fire and control asynchronous and potentially lengthy operations without freezing the current UI. An Ajax application minimizes user frustration, provides timely feedback about what’s going on, and can deliver great mashed-up content.
The Hidden Engine of Ajax
Let’s find out more about the internal HTTP engine that makes it possible to create and execute script-led HTTP requests. The key to the success of Ajax is that at some point around 2005, perhaps because of a rare astral conjunction, nearly all browsers on the marketplace happened to support the same component with a common API—the XMLHttpRequest object. This is the real hidden engine of Ajax applications, whatever browser you pick up and whatever the underlying platform might be.
The Classic Browser-Led Model
Using the local Domain Name System (DNS) resolver in the operating system, the browser resolves the requested 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. 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.
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. The net effect is that 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. And 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 perfect for unleashing the frustrations of the poor end user.
The New Out-of-Band Model
The chief factor that enables Ajax functionality in a Web page 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 different from the browser. This component is the XMLHttpRequest object.
Historically speaking, the first version of this object saw the light of day in 1998 as part of the Microsoft Outlook Web Access subsystem within Microsoft Exchange. Later on, the component was embedded as an ActiveX component in Internet Explorer 5 and then was integrated in other browsers.
Note
In the mid-1990s, there was a team at Microsoft working on a technology called Remote Scripting (RS). RS never reached the stage of a version 1.0, but it had a lot in common with today’s AJAX hidden engine. In RS, the proxy component was a Java applet managing the browser-to-server communication.
XMLHttpRequest is a browser object that is scriptable through JavaScript.