You’re reading this on some kind of client: a laptop, a desktop, a smartphone. This post, along with the software that runs it, lives on a server (operated by WordPress.com). There’s probably a connection between the client and the server at the time you’re reading this.
How big is the client? How is work split between client and server? These are questions addressed at GigaOm by Michael Mullany of Sencha.
In the mainframe age, data and application state were stored at the server tier, and the client device was a stateless (and therefore cheap) terminal. But in the client-server era, application logic moved down from the server-side to the end-user workstation…
In the web era, we returned to the mainframe model of thin clients and fat servers…
But now, HTML5 heralds the return of state and application processing to the client-side device.
The argument is that parts of the HTML5 standard describe means of storing web pages and data at the client side. The pages can then be used at even when there is no connection between client and server. This part of the standard will soon be implemented in browsers.
This means that the client will get fatter. In particular, it means that part of the (server side) cloud will be condensed into a client side puddle.
If (and I won’t go into whether that’s a thin or fat if) this comes to pass, it has several interesting implications.
- There’s a need for excellent heuristics to populate the client-side puddles. If the locally-stored page links to another page, does that other page get stored? What about its links?
- We are a way away from ubiquitous high-speed connectivity. If and when we have that, clients can go back to being thin again. If we had it now, we wouldn’t be interested in client-side puddles.
- Good for the browser that implements this part of the standard. Perhaps not so good for apps?
- Good for the operating system that exists mainly to run the browser, such as Chromium OS.