«AL Developing Next-Generation RI Web Applications TE MA Web applications have historically been less rich and responsive than desktop applications. ...»
04_109625 ch01.qxd 4/27/07 9:42 PM Page 1
Web applications have historically been less rich and responsive than desktop applications. End
users don’t necessarily understand the details of how an application works, but they know that
interacting with a website in the browser is distinctly different from using an application installed
locally. When a development team tackles a new project, one of the first questions they are faced with is whether end users can accept the limitations of web development or whether they need to HT require a client desktop application to be installed. Web applications are accessible from just about any browser, just about anywhere, but they are limited by what you can do with markup and script code running in the browser.
IG Desktop applications, also called fat client applications, require that the user perform an installation on their machine, but let developers leverage the advanced mouse and graphics capabilities of R the operating system that would be extremely difficult to implement in a web browser, and also take advantage of the user’s machine for tasks such as offline storage. Conversely, web applicaPY tions can be updated just by changing what is running on the server, and site visitors get the latest version instantaneously. However, it’s much more difficult to update a desktop application, because you’d have to get users to perform yet another installation or else ensure that the applicaCO tion has been coded to include a clever system for doing updates automatically.
Web applications are said to use a zero-deployment model, but desktop applications use a heavy deployment and configuration model. The choice is often characterized as a tradeoff between rich and reach: Desktop applications generally offer a richer user experience than what could be offered in the browser, but with a web application you are able to reach users anywhere on anyOS with almost no extra effort. Further, many companies have restrictive policies in place regarding what software can be installed on employees’ machines, and they often don’t allow employees to have administrative access that is required to install new applications, so web applications will be the only viable option in many situations.
04_109625 ch01.qxd 4/27/07 9:42 PM Page 2
Chapter 1: Developing Next-Generation Web Applications
Bringing Richness to Web Applications Years ago, having a web presence was a distinguishing factor for companies. That is no longer the case.
Now just having a web presence is no longer enough. Companies are distinguishing themselves further through web applications that react intuitively to customer actions and anticipate user input. This book shows you how ASP.NET AJAX addresses specific web development challenges and paves the way for taking your website to another level of user experience. In this chapter, I discuss the need for richer frameworks in web application development. I talk about the key pieces of the ASP.NET AJAX platform and highlight some other options.
The fundamental set of technologies that enable the next generation of web applications are not new.
Online news articles and blogs point to Google, Flickr, and several other services as prime examples of leveraging these technologies in unique ways. The applications have some unique features, but in reality, the underlying technologies have been around and in use for nearly a decade. Take a look at how Microsoft Exchange Server provided rich access to email from a web browser in the Outlook Web Access application, and you can see that the concept of ubiquitous access from a browser while leveraging a common set of browser features for a rich user experience has been around and in practice for years.
Users get a remarkably full-featured application with no local installation and are able to access e-mail from virtually any machine.
Even that rule can be bent. Some applications are pushing this boundary and completely changing the user’s view, just as though they navigated to a new page, but they do so through an asynchronous post and by changing the page content without actually navigating to a new URL.
Who Benefits from AJAX?
AJAX offers benefits to both end users and developers. For end users, it reduces the “rich or reach” conflict; for developers, it helps in overcoming the constraints raised by HTTP.
04_109625 ch01.qxd 4/27/07 9:42 PM Page 3
Why End Users Want AJAX Applications Users tend to view desktop applications as a sort of commitment. They install a program, usually from a disk pulled from a costly shrink-wrapped box. The program consumes hard disk space as well as a position in the program menu. The user may need to update the program periodically or perform an upgrade later on to get new features. If the program is proactive about updating itself, the user is confronted regularly with dialogs about accepting patches or downloads. In exchange for this investment of time, money, and energy, the user gets repaid by an application that is able to leverage the operating system and machine resources. It is a rich application. It has local storage capabilities, offers quick response times, and can present a compelling and intuitive graphical user interface.
Expectations of web applications are rising. The end user has now seen that it is possible to avoid the commitment of installing a desktop application and still have a rich and responsive experience.
Chapter 1: Developing Next-Generation Web Applications historically dictated a lot about the nature of the application and the development problem space. Many developers are now choosing to build web applications by default unless something about the application dictates that it must be a desktop install. If it must run offline or if it requires a user interface that is complex to achieve in HTML, targeting the web browser may be ruled out, and the choice to write a standalone application is forced.
Developers have a difficult job writing modern web applications due to the inherent worldwide-web functionality constraints imposed by the use of the Hypertext Transfer Protocol (HTTP) and the way browsers use it. HTTP is a stateless protocol. The web browser requests a page, possibly carrying some querystring or form input parameters, and the server processes the request and sends a response that includes HTML-rendered content. The server can only react to the information supplied in the current request and doesn’t know, based on the information in the request itself, details about the path the user took to get to the current view. When the response is rendered, the connection may be broken and the server won’t have any information to preserve for the next request. From the server’s perspective, it is simply listening for requests to come in from any browser anywhere and then reacting. The browser issues a request to the page and receives an HTML page in response. It uses the HTML it receives to render the user interface. The user interacts with the page, and, in response, the browser clears the screen and submits a new request to the server, carrying some information about user input or actions. Again, a complete HTML page is returned. The browser then presents the new version of HTML. Fundamentally, the HTTP protocol is stateless. The server gets a request and responds to it. The request carries limited information about the ongoing conversation that is happening between client and server.
AJAX makes this much better. AJAX breaks this pattern by updating portions of the page separately, via partial page rendering. Figure 1-1 shows a typical non-AJAX series of browser and server interactions.
Each request results in a full page rendering, and, in response, the browser updates the user’s entire view.
In Figure 1-2, AJAX is employed to improve the user’s experience. A request is made for the initial page rendering. After that, asynchronous requests to the server are made. An asynchronous request is a background request to send or receive data in an entirely nonvisual manner. They are asynchronous because 04_109625 ch01.qxd 4/27/07 9:42 PM Page 5
This can occur without clearing the screen to paint a whole new page. Using the XmlHttpRequest object, you could send information to the server and get data back without requiring a whole new HTML page.
What Is ASP.NET AJAX?