Make the world better. Don’t say “thin client” again. Ever.

Thin client. How I detest those words!

Why? Start with some background. “Thin client” rose to popularity in the 1990’s as a marketing term to differentiate “server oriented software from Microsoft’s desktop oriented products.” That is, differentiating software running in a web browser from say, Microsoft Office. You can see the rise of the phrase in the chart below. I pulled data from Google ngram book search (book search data stops at 2000).

In the 14 years since 2000, the tech focus has shifted to mobile. So the phrase has gone into decline. To capture the fall, the second chart below uses Google search trends (data only starts in 2004). Despite the disparate data sources and gap in the middle, the overall picture is clear enough.

So why shouldn’t you say “thin client”? Because it combines two meanings which should be kept as far apart as possible.

• Meaning #1: client/server hardware performance
• Meaning #2: web app versus native app

For meaning #1 client/server hardware performance,this generalizes to the idea of multitier software architecture. What makes this version of “thin client” unhelpful is, as Eric Sink points out, Moore’s Law simultaneously increases internet bandwidth (favoring thinner clients), and increases client machine performance (favoring thicker clients). In practice computer capability relentlessly grows in all tiers. Using “thin client” with meaning #1 made sense when terminals were limited to green screen mainframe terminals or Unix x-terminals. Those days are long gone. Sure, the client-server ratio is becoming ever more lopsided for servers, but nowadays clients are more than capable of running very complex code. Which developers rightly take advantage of. For meaning #1, instead of “thin client” just say n-tier or networked computing. Nobody is “thin.” Note: don’t nitpick about internet of things devices, since my larger point is the baggage associated with “thin” makes it unhelpful even for them. For example, people wearing fitbit may in fact be thin. Sure. But calling fitbit device itself thin? Don’t.

Meaning #2 is about web apps versus native apps, where “thin client” is a euphemism for web app. In common usage, all it means is web site. Think the web version of gmail. In contrast native apps run directly on the client operating system (think Microsoft Office, or most of the apps on your phone). For meaning #2, the terminology “web app” is sooo much better than “thin client”. This was true even back in the 1990’s. “Thin client” was at least in part a sleight of hand trick to bash Microsoft and promote the web. You talked about having a proper n-tier architecture with meaning #1 (which had some truth). But in reality both web apps and native apps could be made to work with n-tier architectures. So most of the gains from web apps were install-upgrade-deployment. As a bonus they bypassed the Windows monopoly. All part of meaning #2.

Let’s see why meaning #2 is so important by using a table to compare web apps, old school native apps on PC/Unix/Mac, and new school native apps on iOS/Android.

The internet software revolution is really about the top four rows a-d. Web apps allow software developers to write a single version of an application which can auto push updates out to a standardized web browser container. All with centralized data (cloud storage). Instant push of software updates and keeping the entire ecosystem on the latest version is great for developers. In fact it caused a revolution. It made Software-as-a-Service possible. It jump started new software methodologies like Scrum, Extreme Programming, Agile, A/B testing, Lean. Amazing stuff! None of which had anything at all to do with hardware sizing of the client (meaning #1).

But look what modern iOS and Android have done in the rightmost column. They’ve converged on the web app advantages. Modern app stores automatically push out client updates, have better security sandboxing, and are much more compatible with internet services and cloud storage. Obviously iOS is ahead in successfully pushing out software updates. But by last year (2013) at least, the mobile OS competition became boring. So as Benedict Evans points out:

Regarding push updates, we should expect Android to now catch up. The real pain point for native apps is you have to pay the double price of writing separate Android and iOS specific client code (item c above). Yet the web app disadvantages from the bottom half of the table remain. Performance is worse, you can’t do cutting edge user interface, and you have more restricted access to contacts, camera, location, etc. Which brings us to Facebook.

In December 2012 Facebook famously ditched web apps based on html5 for native phone apps. A great discussion started by MG Siegler on the topic is here, the quality of which is demonstrated by nobody uttering “thin client”. It’s all web app (or html5) versus native app. The consensus is for the time being, cutting edge apps need to be native for usability and performance reasons. Looking toward the future, Cody Inman pulled an often cited quote from Marc Andreessen:

The application model of the future is the web application model. The apps will live on the web. Mobile apps on platforms like iOS and Android are a temporary step along the way toward the full mobile web. Now, that temporary step may last for a very long time. Because the networks are still limited. But if you grant me the very big assumption that at some point we will have ubiquitous, high-speed wireless connectivity, then in time everything will end up back in the web model. Because the technology wants it to work that way.

Ben Bajarin is less sure we’ll standardize on the web app model, though I think Andreessen’s “very long time” leaves it unclear if there’s any deep difference here. Everyone agrees we’re going to continue with native apps for the next few years, with a gradual shift toward web apps. Especially for less demanding cases. And as Benedict Evans notes, the distinction between web app/native app itself will continue to blur.

Where else should we avoid “thin client”? Chromebooks. Instead of calling them thin clients, call them dedicated web app devices. Ben Thompson clarified their real advantage is simplicity. Ironically, given the performance loss of web apps compared native apps, it’s arguably better to have more powerful hardware on such a device. “Thin” is worse than useless as a description for Chromebooks.

As for phones, tablets, and traditional laptops just avoid “thin client” altogether. Use n-tier, networked computing or whatever floats your boat for meaning #1. Use web app for meaning #2.

Of course people involved in tech know this already. “Thin client” is on the way out. But it occasionally pops up. In context it’s clear what’s intended. But whenever I see “thin client” I cringe. It’s a confusing zombie relic from the Netscape-Microsoft-Browser War era. Consider this blog post an attempt by a good internet citizen to hurry “thin client” along to its well deserved death.