A New Thin Client

The web browser has been the dominant thin client, now rich client, for almost two decades, but can it compete with a new thin client that makes better technical choices and avoids the glacial standards process? I don’t think so, as the current web technology stack of HTML/Javascript/Flash has accumulated so many bad decisions over the years that it’s ripe for a clean sheet redesign to wipe it out.

For the uninitiated, let’s start with some definitions. Thin clients have been around since the early days of computing, as there has always been a need to provide compact User Interfaces (UIs) remotely, such as with text terminals or the X Window System. I define thin clients as client-server platforms that use at most 10-30% of desktop resources such as the microprocessor and that do not deploy general-purpose program code, as exemplified by javascript in modern web browsers. Alternatively, rich clients have richer UIs and usually deploy code that then absorbs a larger share of desktop resources, such as C# in Silverlight and Java in JavaFX. HTTP/HTML started out as a thin client but has been turned into a hobbled rich client with the addition of javascript, as it’s stuck using HTML for legacy reasons. The other widely deployed rich client is Flash, which has evolved from a simple animation platform into an often inefficient rich client.

I argue that rich clients have efficiency and security problems that we should push off for later: right now, we should focus on building a better thin client. The essence of a thin client is to implement the most common graphical UI elements across multiple hardware and OS platforms while maintaining security. A thin client can be thought of as a first stab at ubiquitous network computing, where the security hassles of having the information superhighway coming into your PC- and the internet bandits and thieves who can now drive right up to your computer door- are handled by the thin client platform so that developers don’t have to. I estimate that 30-50% of all applications can be implemented on a thin client platform, as most applications don’t need much more than a thin client provides. And finally, thin and rich client platforms are hugely important to the future of operating systems, as I can write this today in a web browser using FreeBSD on my desktop because of the web’s ubiquity as a thin client.

But what would a better thin client design look like? It would provide better and more modern GUI elements than HTML, updating the standard widget set since HTML was initiated almost 20 years ago. Sessions would be the atomic unit of its network model, focusing on highly interactive user experiences rather than the old-fashioned request-response model used by HTTP/HTML. A binary encoding would greatly increase network efficiency, minimizing much of the wasteful uncompressed text sent over the network since I estimate that HTML makes up approximately 5% of network traffic. Graphic designers would use GUI tools exclusively to work with this binary format, which works out perfectly as nobody wants to muck around with a markup language like HTML anyway.

Finally, the internet standards process has not been beneficial for application protocols like HTTP/HTML. Rather, it has led to multiple implementations that each has their own quirks. Part of this is because of the vagueness of important sections of open standards, perhaps it is impossible to precisely detail any reasonably complex technology. Part of it is because every implementer tries to differentiate themselves by adding special features that are incompatible with alternate implementations. What is important for a software platform is that it is open to reimplementation and the resulting competition, allowing developers to always have the choice of moving to another implementation, not that it conforms to some preconceived standard. I’ve laid out some ideas on what should replace the standards process at my blog.

A better thin client design would follow the contours of these choices but adoption is the primary issue for any new platform. However, building a new thin client need not be a giant undertaking as much source code can be reused from existing open source web browsers, such as cross-platform image and text libraries. The better user experience enabled by such a platform would attract internet application developers and it wouldn’t be hard to write a HTML->new thin client format converter on the server side, that could convert HTML and the trivial javascript used in AJAX to the new binary thin client format. This would allow developers to reuse existing HTML and AJAX code until they can port it thoroughly to the new binary format. Also, one can bundle an existing open source web browser, such as Google’s Chromium project, with a new thin client on the client side, so that both technologies can be used side by side in the same program. Building in a complementary technology like a micropayments system, which the web has appallingly failed to deliver to this day, would constitute a “killer app” platform.

The web, as composed of HTTP/HTML/Javascript/Flash today, is a highly inefficient and insecure internet application platform. We can build something much better by rethinking some basic design choices. Instead, we have been incrementally building on the web stack for 20 years now and it shows. The web is ripe for disruption: it’s not a question of if it will happen, only what will replace it and when.

Mufasa blogs about GUI and thin client issues at A new thin client.


  1. google_ninja 2009-08-10 1:18 pm EST
    • FunkyELF 2009-08-10 3:32 pm EST
      • google_ninja 2009-08-10 6:34 pm EST
        • FunkyELF 2009-08-10 8:41 pm EST
          • google_ninja 2009-08-10 8:58 pm EST
          • sbergman27 2009-08-10 9:05 pm EST
          • frood 2009-08-12 10:49 am EST
      • snowbender 2009-08-10 10:49 pm EST
      • ddc_ 2009-08-11 6:22 am EST
  2. juvenile4909 2009-08-10 1:33 pm EST
  3. Brendan 2009-08-10 1:54 pm EST
  4. zimbatm 2009-08-10 1:54 pm EST
    • Laurence 2009-08-10 2:05 pm EST
      • _df_ 2009-08-10 2:19 pm EST
      • dagw 2009-08-11 7:09 am EST
  5. buzievagy 2009-08-10 2:15 pm EST
  6. hapalibashi 2009-08-10 2:23 pm EST
    • google_ninja 2009-08-10 6:40 pm EST
      • kragil 2009-08-10 7:13 pm EST
  7. John Bayko 2009-08-10 2:32 pm EST
  8. B12 Simon 2009-08-10 2:51 pm EST
  9. bugjacobs 2009-08-10 3:05 pm EST
  10. iq-0 2009-08-10 4:06 pm EST
  11. Yamin 2009-08-10 4:37 pm EST
  12. ba1l 2009-08-10 4:58 pm EST
    • happe 2009-08-11 1:37 am EST
      • ba1l 2009-08-11 2:08 am EST
        • happe 2009-08-11 2:50 am EST
  13. sto1c 2009-08-10 5:16 pm EST
  14. whartung 2009-08-10 6:03 pm EST
  15. vtolkov 2009-08-10 7:01 pm EST
  16. Eddyspeeder 2009-08-10 7:05 pm EST
    • sbergman27 2009-08-10 7:36 pm EST
    • PlatformAgnostic 2009-08-10 7:36 pm EST
      • google_ninja 2009-08-10 9:05 pm EST
        • PlatformAgnostic 2009-08-12 12:45 am EST
    • Delgarde 2009-08-10 9:21 pm EST
      • Eddyspeeder 2009-08-10 9:48 pm EST
        • Delgarde 2009-08-10 10:43 pm EST
        • coreyography 2009-08-11 12:45 am EST
          • Eddyspeeder 2009-08-12 9:53 pm EST
  17. FreeGamer 2009-08-10 8:08 pm EST
  18. Zan Lynx 2009-08-10 8:11 pm EST
    • dmarsh 2009-08-10 9:56 pm EST
    • Eddyspeeder 2009-08-10 9:56 pm EST
  19. rycamor 2009-08-11 5:17 am EST
    • rycamor 2009-08-11 5:20 am EST
  20. ddc_ 2009-08-11 6:44 am EST
  21. Different 2009-08-11 9:43 am EST
    • sbergman27 2009-08-11 10:07 am EST
  22. sseehh 2009-08-11 9:56 pm EST