1.1. What Is a Web Application?

If you're reading this book, you probably have a good idea of what a web application is, but it's worth defining our terms because the label has been routinely misapplied. A web application is neither a web site nor an application in the usual desktop-ian sense. A web application sits somewhere between the two, with elements of both.

While a web site contains pages of data, a web application is comprised of data with a separate delivery mechanism. While web accessibility enthusiasts get excited about the separation of markup and style with CSS, web application designers get excited about real data separation: the data in a web application doesn't have to have anything to do with markup (although it can contain markup). We store the messages that comprise the discussion component of a web application separately from the markup. When the time comes to display data to the user, we extract the messages from our data store (typically a database) and deliver the data to the user in some format over some medium (typically HTML over HTTP). The important part is thatwe don't have to deliver the data using HTML; we could just as easily deliver it as a PDF by email.

Web applications don't have pages in the same way web sites do. While a web application may appear to have 10 pages, addingmore data to the data store increases the page count without our having to add further markup or source code to our application. With a feature such as search, which is driven by user input, a web application can have a near infinite number of "pages," but we don't have to enter each of these as a blob of HTML. A small set of templates and logic allows us to generatepages on the fly based on input parameters such as URL or POST data.

To the average user, a web application can be indistinguishable from a web site. For a simple weblog, we can't tell by looking at the outputted markup whether the pages are being generated on the fly from a data store or written as static HTML documents. The file extension can give us a clue, but can be faked for good reason in either direction. A web application tends to appear to be an application only to those users who edit the application's data. This is often, although not always, accomplished via an HTML interface, but could just as easily be achieved using a desktop application that edits the data store directly or remotely.

With the advent of Ajax (Asynchronous JavaScript and XML, previously known as remote scripting or "remoting"), the interaction model for web applications has been extended. In the past, users interacted with web applications using a page-based model. A user would request a page from the server, submit his changes using an HTTP POST, and be presented with a new page, either confirming the changes or showing the modified data. With Ajax, we can send our data modifications in the backgroundwithout changing the page the user is on, bringing us closer to the desktop application interaction model.

The nature of web applications is slowly changing. It can't be denied that we've already come a long way from the first interactive applications on the Web, but there's still a fair way to go. With applications like Google's Gmail and Microsoft's Office Live, the web application market is moving toward applications delivered over the Web with the features and benefits of desktop applications combined with the benefits of web applications. While desktop applications give us rich interactivity and speed, web applications can offer zero-effort upgrades, truly portable data, and reduced client requirements. Whatever the model of interaction, one thing remains constant: web applications are systems with a core data set that can be accessed and modified using web pages, with the possibility of other interfaces.