As Web mavens know, with html5, fat client is truly becoming dominant again, after many years when server-side driven, whole-Web-page-refresh Web applications were the order of the day.
What they may not know is that this trend may be reaching its zenith now in the ever-swinging pendulum course from fat to thin client and back again. Last week at work, a colleague told me about OnLive, a game company that employs a very unusual architecture: big-3D-graphics games are delivered via an edge-server network that does the heavy rendering lifting!
When I read that at least one prominent Eurogamer game writer thought the feat impossible both technically and financially ("Why OnLive Can't Possibly Work"), I had to try it out. Not being much of a "gamer", let it be said also that this was also to imrove my understanding of user engagement devices for my current job. Playing "Borders" from OnLive on a 20mbps connection, through 300mbps 'n' home wireless, was amazing! Although I am "the less discerning gamer", to be sure (to borrow a phrase from the Eurogamer article), I do have about ten years experience in Web applications and was duely shocked at what OnLive has built.
The graphics quality looked to me to be about standard definition, which is the level predicted by the Eurogamer article. But that's certainly enough to base a good game on. As for the responsiveness, I think they must be doing some real work on the client. Navigating in that 3-D world with really no perceptible latency just couldn't be done otherwise.
Nevertheless, if all or almost all the custom code is running server-side, this marks an important milestone. Cross-platform issues must have accounted for 25% of website development costs until recently when we've seen some major improvements. But now, mobile platforms represent a new giant cross-platform resource sink.
So if custom code can be isolated on the server side, even though that's a far cry from having truly dumb clients, that's a big leap forward. Apparently, HTC thinks so, having recently purchased OnLive for US $40M! On the Web browser end, Google has been hard at work on NaCl, its native client plug-in for Chrome, as evidenced by the clearly game-oriented bullet physics test.
If latency can be reduced this much, there is little reason to think that we cannot dispense with per-app/per-game custom client side code entirely before too long. Smooth animations still require at least 30fps (~ 33ms), and getting a screenful of freshly computed pixels to the client and then having the client decode and present them in that time frame still presents an unfeasible challenge. So for the near future, ultra-rich user-interfaces, such as those with smooth swipes and gestures, will need something more on the client than a simple VNC session.
But tools such as the html5-based "Browser VNC" Guacamole, combined with Amazon's EC2, could deliver applications that don't require rich gestures and rich interactions for a fraction of the cost of "the old" approach. Less sweeping, but still impressive, cost savings could be had for rich-gesture/rich-interaction applications and games if they are based on rich-effects engines accessible directly from a Web browser, such as NaCl. Sunset for cross-platform client-side code painstakingly built custom for each application-platform combination may be on the horizon.