Persistent Myth: Bandwidth is Infinite

There exists, still, the myth of infinite bandwidth. The myth exists in support of the notion that "web" applications can and should be just like desktop applications. But there is a problem: what is a desktop application? In the beginning, 1982, the IBM PC provided a standalone little computer, which was expected to be programed just like the 370, only for smaller problems related to the work of the individual.

That fairy tale came to an end with Lotus 1-2-3, which turned the PC into a toaster: an appliance which did some computing (itself done by programs written by professional assembly language programmers) upon some data entered, or made available, by the individual. Then came typing programs, later renamed word processing. The toaster syndrome was in full swing.

Then came Netware, and its ilk, to lead us to a kind of client/server environment. This is what "desktop application" really means these days: a local PC connected to a semi-local big computer. The VT-100 connected to a *nix database machine is the precursor to that.

AJAX, and so on, are attempts to take the 3270 behaviour of the web and turn it into the VT-100, albeit with pixels and graphics. In order to do that, the link to the outside world has to behave like fast RS-232.

So, today The New York Times runs this story. Infinite bandwidth, my eye. A bloody phone brings the net to its knees. When will people learn what your Mama told you, "what kind of world would we have if everybody behaved like you?". Nothing is infinite, stupdity likely excepted.


Update II:

There is the olde canard about tapes in a station wagon. Here is a new and even more amusing example.


Update:

In response to some questions from readers elsewhere, I'm led to pontificate further.

I missed out the obvious point (to me, anyway). There are two expenses in getting an image on the screen: computation and transfer of the image. With a 1982 desktop, what could be computed was memory mapped to the screen, so transfer was instantaneous (mostly).

With local networks and VT-100 to RS-232 to database, the screen is still a memory map in the server; all that goes over the wire is the characters in the screen image.

With GUI-ed screens in a local network, it's still manageable with Ethernet on wire.

With GUI-ed screens in the cell tower, not so much. Given that HTTP is about lots of request/response between the client (iPhone) and the server (Google machine, or whatever), the "virtual wire" gets overloaded. And will always be.

It's the same with building highways or subways or ...; traffic overwhelms infrastructure.

With an HTTP based internet, it's not possible to have a (mostly) passive (memory mapped) screen with all the computation at the server. Fact is, increasing computational power is a couple of orders of magnitude cheaper than I/O. And the web is about the least efficient form of I/O ever invented. It's not being used the way Cerf had designed it.

Abuse leads to breakdown, and the web is broke. The iPhone just makes it obvious, but not the reason.