Today I'm going to tell you that the Web is being used incorrectly by both its users and especially by companies hoping to leverage it for profit. Hopefully by the end of this post you'll believe me.

Let me first introduce the concept of a thin client, if for some reason you're reading this blog and don't know about them. Back in the day, computers were huge, expensive machines whose processing capabilities rivaled those of my pocket calculator. Individualized computers as we know them today were not possible. So we came up with a centralized computing model using machines known as "dumb terminals" or, more accurately, "thin clients". The thin client contains only enough hardware and software to accept user input and display feedback. Everything the user sees and does on the thin client is processed by a central server via a network rather than on the client itself. This was the cheapest computing model at the time, allowing each user to have his "own" computer, while not paying through the nose for computing power.

This was first done with the text-only screens of systems like IBM's AS/400. Each thin client was just a monitor and keyboard, and text positioning and other information was handled by the central server. Since text computing is cheap (relatively), there was no reason to try and offload those calculations to the thin client itself. In more modern centralized computing models, such as a centralized Solaris Unix environment, users demand a more robust graphical display and input capabilities. The modern thin client in this environment offers a keyboard and mouse as input, and runs a distributable graphical display system, such as the X Window System. In this model, the central server handles the back-end computing of what the user wants, and the thin client handles the display, input and event processing.

This is still a very cheap computing model, since you still have a centralized server doing most of the work and a set of thin clients which are effectively nothing more than graphics processors. All of the user-specific graphic events are kept off of the central server, freeing up its cycles for the (optimally) important calculations the users need to run.

The opposite of thin clients is what most people think of when they think of "computer". The desktop or laptop or PDA or cellphone you use to do things on a daily basis. When running things like games and office productivity software, the PC's hardware and only the PC's hardware is used to run all of the calculations involved. When the computer isn't being used, all of its cycles are being wasted on nothing. This makes it a very, very expensive computing model. Only gamers and professions in certain design and engineering occupations can make full use of such individualized hardware. One need only remember that a computer with a processor weaker than that of a modern pocket calculator used to be able to support dozens of concurrent users doing their work over thin clients to see that we're wasting our thick-client CPU cycles. (Also, software bloat contributes a great deal to this phenomenon but that's another discussion entirely.)

HTTP, the hypertext transfer protocol, is very similar to the modern distributed system of computing. In its original inception (that is, just transmitting HTML without any extras) all it did is transmit the information required to display results and transmit user input to the server. The browser (analogous to a thin client) handled display calculations and the server managed everything else. Then other things were added to the Web, such as images, CSS, more well-defined HTML and even small scripts that were run on the client to manage some display calculations. HTTP was still very much a centralized computing model, with nothing more than display code being run on the client. The big difference is the fact that HTTP is sessionless: once a web page is delivered to the client, the server forgets about that client. So if you wanted to make an application that reacts to every input the user gives, the client has to tell the server everything every time. This results in a great deal of network bandwidth being used to communicate information that the server technically knows already.

So we did the worst thing we could have possibly done. We tried to mash HTTP into a sessioned protocol by lumping entirely new frameworks on top of it on the server side. Then we even warped HTTP into micro-requests for interactivity instead of sending the whole page every time. AJAX is the name given to this practice. The end result is more and more computing is offloaded from the server and onto the client. Web pages are now not so much individual documents meant to be read as they are miniature dynamic distributed applications. Instead of moving toward a centralized computing model, we're putting more and more of the actual calculations onto the client. This works because the client usually has cycles to spare, and companies want to do it to reduce the work their servers have to do.

The problem is the Web isn't being used in a thin-client model. Rather it seems to be moving more and more toward a distribution system for tiny applications. Web pages are often warped into single-serve software. Things like web-based e-mail and office productivity suites (I'm looking at you, Google) are the best examples of this. It would be better (in terms of efficiency and bandwidth usage) to have office software installed on the client rather than all of the individual screens, scripts and other information transmitted to the user over the Internet every time he wants to use the software.

We should have come up with a lower-level protocol than warped session-HTTP for this kind of thing. It's really nothing more than a hack on top of a system that was specifically designed to do the opposite of what we want to do with it. Instead of bending HTTP to our desires we should have created a sessioned sister protocol to HTTP that could reflect a thin-client model, and leave HTTP to its original site-distribution purpose.

Not that there's anything you or I can do about this. It's just a fact of the Web now. What it means is that as we move more and more into the Web-as-distribution-agent model, web pages are going to be expected to look and act more and more as thick clients and will therefore have to rely on more and more hacks to accomplish this. And all this time we should really just have looked back to those AS/400 dumb terminals for guidance. Really I didn't want to do anything more than bring this to your attention.