What is a Web application?

Every week I write about various aspects of Web applications but I have never actually discussed what a Web application is.

The place to start is what differentiates a Web application from a regular Web site. Some people contend that this is a matter of interactivity; of the user entering or sending data to a Web server, but that doesn’t really address Web applications such as informational dashboards that just consume data generated by a Web site (indeed, I would classify Atom and RSS news feeds as Web applications).

Nope, the foundation of all Web applications is that they involve the delivery of dynamic content.

This means that, for example, a Web site that serves up content enlivened by Dynamic HTML (DHTML) is essentially a Web application despite the fact that the actual processing occurs in the browser. It is the fact that the site delivers dynamic content that matters. You might think of this architecture as a client-side Web application – the first of three basic architectures that Web applications can assume.

The alternatives to client-side Web applications are server-side and client-server Web applications.

Pure server-side architectures are actually fairly rare as they involve the Web client presenting data to the server that is consumed with no feedback. This is usually nothing to do with conventional Web browsers and would most likely be used by client applications for reliable uni-directional data transfers over HTTP connections.

Client-server Web applications are common and Web forms are a good, albeit simple, example. You fill in a form and the data is sent to the server, which responds with some kind of feedback – at the least with something along the lines of “your input has been received.”

Combination architectures are perhaps the most common of all. For example, when a client browser runs a script that validates user data input to a form, a client-side model is front-ending a client-server model that, in turn, accepts the submitted data and generates a response in return.

Why does this matter? Because breaking down your Web application architecture into prototypical models and discovering the data-flows and the constraints of performance and timing is the best way to drill down how the server and the client interact.

What you’ll often find is that Web applications that start out simple get complicated really quickly because they tend to grow organically. The consequence of not having a conceptual handle on your Web architecture always shows up as the system expands – intermittent 404s, failed form submissions, timeouts and authentication errors.

In future musings on Web applications, we’ll look at what aspects of design differentiate the good Web apps from the bad ones and the great ones from the rest.

I want your thoughts on this topic. Tell me what strategies you use in building Web applications and how much architectural planning goes into your designs. And better still, what mistakes you’ve made, how you discovered them and fixed them.