What is a Web Application? (Part 1)

Introduction

This post examines what a web application is, by tracing (very loosely) how people thought of the web (and web applications), and what was expected of Web content.  The following sections "map" out a rough progression, over-generalizing for the sake of illustration.  There was (and always will be) sites that are ahead of their time, as well as sites that defy categorization.  Also, each stage includes all the previous stages.  Many completely static websites exist today, as they still are perfect for their job of dispensing unchanging information.

In the beginning (Web 0.5)

When the Internet was slightly younger than it is now (if that is possible), the distinction between applications and web pages was crystal clear:  A web page was what was pulled up in an application (say Netcape Navigator, or Internet Explorer).  A web page didn't actually do anything.  The application loaded the web page, and the user read it, and got the desired information.  An application, on the other hand, did something.  It might load a web page, or communicate with a stock feed server and get the most recent stock prices, look up a customer record, or allow the user to blast space aliens.  Of course, this dichotomy was never absolute (unless you look back to Archie, and call it "the web", but that's a stretch).  People mostly used the web for information, and the main issues were finding and being able to usefully read web pages.  The web in this model is just data:  all of the "action" is in the web browser.  The revolutionary thought at this stage was hyperlinking:  the documents themselves kept information about what is relevant or related.  This, by itself, was enough to change the world, as information was markedly easier to get than it ever had been before.  Directories (such as DMOZ) tried to  organize this information.

Web Forms, Applets, and Flash (Web 1.0)

A product page is much more fun to look at if there's a shopping card to add the product to.  It's also better for the bottom line.  However, this required some way to get data back to the publisher (It's true that clicking on a link gives the website information, especially with cookies, but the HTML "keyboard" that that implies is clunky, to say the least). Enter web forms.  With nothing more than a form tag, and some input tags, the server can get credit card numbers, and e-commerce really makes sense.  The problems with web forms are that they are ugly, and clunky, and the user experience is quite limited.  Refactoring a real application to have a HTML forms interface can be somewhere between painful and impossible, and using said application can be even worse.

Around the same time, Sun released Java 1.0, which had included applets -- a way of including Java on a web page, to be deployed as the page was loaded.  These applets allowed the code to receive the users keyboard and mouse events, and paint whatever was desired.  However, they are a lot harder to write, and the deployment issues seemed never to be worked out.  Most users can get applets (either because they have already installed Java, or because it came pre-installed).  Others could get Java by downloading it from Sun, but still others were more or less out of luck, with issues that were impossible to resolve.  This, together with long load times, meant that applets worked much better with a small group of users, as an administration console, for instance, for as an option for advanced users, as is seen with Power E-Trade.

Adobe's Flash, which is optimized for displaying video, playing simple games, and other graphics applications, is quite popular as an add-on for web pages that want to be flashier (pun intended).  Flash does not focus much on the traditional "business" uses of rich content (such as forms, ironically), and is more of a very good niche product.  While not as troublesome as applets, Flash pages still do not deploy everywhere, and add significantly to the load time of a web page. 

This meant that Web 1.0 presents an essential dilemma:  rich, fast and hard to deploy, or minimal and clunky, and easy to deploy.  Applications intended for a limited audience tended to be applets (for instance Lotus Notes, or Power E-trade), while other web pages were HTML forms.