«
»

Smart terminal, dumb terminal

November 21, 2009, 3:20 pm

Saw this in my Twitter feed today (retweeted by @andrew_chen):

sachinrekhi Funny thing about Chrome OS is that it’s analogous to going back to the days of Terminals where data & computation was server side

I don’t know a lot about the history of computing, but haven’t there been major shifts back and forth over the decades?  The terminology I’ve heard includes “dumb terminal” vs. “smart terminal”, “thin client” vs. “thick client”, and “centralized” vs. “decentralized” computing.  There’s always been a major question of how much computation and data should be at the endpoints, and how much in relatively centralized resources, whether it’s mainframes and their terminals, Web apps and browsers, or mobile apps running on smartphones.

I’d guess such shifts are natural, depending on the availability and cost of bandwidth, storage, memory, and CPU.  Will they continue?  The Web enables a hybrid approach that seems to provide the best of both worlds: apps and data live in the cloud, but some code (JavaScript, Flash) is downloaded and run by the endpoints.  Hosting apps centrally affords many advantages, especially the ability to deploy software updates almost instantly, by a process that is usually effortless or even invisible to the user.  Downloading some code (especially UI code) allows maximum performance and responsiveness, but—this is critical—that code, too, can be updated instantly and seamlessly.  (Projects like Google Gears are even providing offline access without sacrificing this essential advantage.  I love offline access in Gmail; for me, it was the biggest feature Gmail lacked compared to Outlook.  Most services, such as Dropbox and Evernote, still achieve offline access using desktop clients, but I suspect this will change eventually.)

I don’t think this hybrid approach could have been done from the first days of computing; it had to wait for a certain level of bandwidth, memory, and CPU (not to mention advances in programming languages and software design—could we have had Web apps running JavaScript before OO design?)  The mobile world is still a bit before this point:  Web apps work on mobile, but they’re usually too slow and unresponsive, so most apps are native.  (This is a major disadvantage for mobile apps; no mobile app can fully practice continuous deployment, and the iPhone App Store approval process greatly exacerbates the problem, as Paul Graham points out in a recent essay.)  But in maybe five or ten years, mobile devices and networks will be powerful enough to just run Web apps, and software will shift again.

Does anyone know enough about the history of computing to provide some perspective here?

On a related note, read Naval of Venture Hacks on why you will eventually dump your laptop and just use your smartphone.

UPDATE: See also the Jargon File on “wheel of reincarnation” (thanks @mjgardner).

Category: Uncategorized  |  Comment (RSS)  |  Trackback
  • This is an interesting question and I would argue we're heading toward an architecture that is a little bit more down the middle than firmly on either side.

    If you look at the pros and cons of both architectures, there is one glaring problem with Chrome OS: if the network goes down, so does the app. Sure, the network may go down less and less but do we really want to lose all use of an app when the network isn't available? What if we're in an airplane? Or on the South Pole? Or in an underground bunker? Should computing devices become useless without the network?

    On the other hand, the advantages of the thin client are clear. Data stored in a device-independent fashion. Seamless backup and sync. Immediate and simple software updates that flow out to devices. I'm sure I'm forgetting more.

    The next generation of apps are bringing these advantages together. SugarSync is a good example, with seamless clients running on Windows, Mac, BlackBerry, iPhone, Web and Mobile Web. If I go offline, all the changes I make are queued up and transmitted when I go back online. Installed clients are auto-updated over the network when needed. (I would also add SMS as a potential client although SugarSync doesn't use it.)

    The challenge is: does every app have to build six or eight or ten clients? Or can development tools improve to the point that this gets much less expensive and time consuming to do right?
blog comments powered by Disqus