I Believe in Network Clients

At an interview last week with John Markoff, I made a statement that seems to have generated some concern over my sanity. I said, “I don’t believe in thin clients.”

Let me start by saying I started my technology career with a company that built client (ie, desktop) software. I care a lot about user experience. And for that reason, I’ve always thought the words thin client were oxymoronic. No two words have ever been less comfortable sitting next to one another – one cannot have a client without at least some functionality or ‘state’ on a device, and the girth of that state (as measured by memory or storage or application footprint) directly correlates to the interactivity of the client.

In simple terms, TV’s got more interesting when they sprouted set top boxes. Radio got more interesting when iPods came along. And cell phones blossomed when you could download games and ringtones to their resident Java platforms. (Cache is king – although it can be stolen (think laptop), but I’ll leave that cryptically hanging for another blog).

Industry convention says that apps written to browsers are defined to be “thin.” But by that definition, thin really equates to “using someone else’s runtime environment” – in that the browser itself has to be present for the service to be rendered. And last I checked, browsers require operating systems and windowing environments. Not exactly thin. So in my book, it’s inaccurate to say Google or YouTube are “thin clients” – they’re services that leverage someone else’s thick client. A browser.

With this heresy behind me, I’m also (less controversially) of the belief that the most interesting consumer innovations are those we experience with our eyes – through compelling clients. And until recently, very few companies were investing in client software or hardware – sure, there were lots of browser apps, but that’s what they were.

But that’s changing. Innovation on clients is back – we see it in a flurry of Web 2.0 companies investing in creative desktop interaction and the resurgence of JavaScript, in the myriad toolbars the big portals are driving into the world, and more interestingly, in an ever broadening array of new devices showing up in the hands of teenagers, on automobile dashboards, in our living rooms, basically everywhere. None of these are thin – at least in my definition. They all, however, leverage the network. And that’s the big innovation – it’s no longer just a browser presenting the network to users. Its standalone client applications and devices.

But why the renewed energy around clients? This was venture capital no man’s land a few years back, but no more.

First, the strategic reason – relying on someone else’s browser is a precarious choice. Especially when the distributor of the browser can use it to compete against you (type “news” into Microsoft Vista’s browser, and you don’t go to news.com, you go to MSN News…). That’s driving a lot of companies to validate their services against Firefox, Opera and the Java platform – and as interestingly, it’s driving companies to rewrite their apps to be standalone network clients, like iTunes, or the NetBeans developer tool. Standalone network clients, hardware or software, avoid the threat of disintermediation from unfriendly runtime environments.

Secondly, users don’t like to wait. Which from my pedestrian vantage point is the fundamental motivation behind “Web 2.0” – resident functionality, whether Google Earth or NASCAR’s PitCommand, is more satisfying than visiting a web site that tries to load great heaping volumes of JavaScript into a browser every time a user appears (or more frustratingly, reappears). Patience isn’t a virtue when it comes to computing – out of site, out of mind (pun intended). Make the user wait, they’ll go elsewhere – provide a persistent executable, one that lingers between usage – or attaches to your belt loop – you’re more likely to keep the customer.

Lastly – the network has finally become pervasive. You can get a signal nearly (I did say nearly) everywhere – but as we move from a world of relatively reliable landline networks, to one in which we share services with mobile and wireless networks, the latter’s spottier reliability is becoming more pervasive. And for a network service to retain its utility, it’s got to do more than fail to appear when invoked off the net. Which implies an interactive client that persists, or hangs around, even when the network disappears for a moment. That’s why your in-car navigation system works, even if the update feature is disabled.

Now again, I am at my core someone who cares about clients – and user experience. Servers without clients are called space heaters – so it’s good to see innovation returning to clients, especially network clients. It’s been bottled up in the traditional definition of thin for too long. And although I don’t believe in thin (except for one very pure, very low power, unthievable interpretation), I’m a huge believer in the network. And all devices that attach to the network (just go to CES next year, you’ll be awed).

So with that as a preamble, allow me to congratulate the Java community on having voted to approve a new Java platform, Java Standard Edition 6 – whose arrival yesterday via the Java Community Process heralds the single biggest improvement in the Java platform in years. And a vast improvement in user experience. Vast.

With Java now powering more than four billion devices (ahem, network clients), the question we now face is how do we approach the next few billion. And without giving away the answer to that question, I’ll leave you with one of my favorite quips:

Different isn’t always better.

But better’s always different.


Filed under General

21 responses to “I Believe in Network Clients

  1. hi jonathan,
    if you try the following google search http://www.google.com/search?hl=en&q=news&btnG=Google+Search also does NOT give news.com as the first result!!

  2. Great move, I can’t wait to see your support for FreeBSD platform for Java Standard Edition 6 32bit and 64bit as well in the download area.
    Please support
    Thank you,
    Abdullah Al-Marri
    Arab Portal Network

  3. Jesse Kuhnert

    Having spent a good majority of my career drinking the jini || javaspace || swing kool aid before looking at web stuff again I can only hope such optimism is met with an equally ambitious new look at the swing api in general.
    Compared to its more native counterparts it always felt extremely lacking. (and I don’t mean perf, just really simple things. Rendering hints would probably make a lot of people happy. That and the death of GridBagLayout)
    JDK 6 is actually awesome as far as performance goes I have to admit. Haven’t looked at any swing code in it yet but if the runtime improvements have rippled out to that portion of the API then that really would be something worth being optimistic about.

  4. Andrea Mele

    I strongly agree with you. I developed client-server over internet using Swing on the client-side. I think that HTML clients fit well for pure presentation apps.only. HTML-JS-CSS is not good technology and if you ask highlevel interaction the development effort rump up to the sky.

  5. Speed

    Typing “news” into the address bar of IE7.0 brings up neither MSN News nor News.com. It brings up Live Search (if that is the search engine you have chosen) with the first result … wait for it … news.google.com.

  6. Bharath R

    The helio.com link seems to be broken, Jonathan. This is perhaps the right one – http://www.helio.com/page?p=device_overview_kickflip
    btw, is it Java enabled? Didn’t find a mention of it in the details page.

  7. Mika

    Where are the sunray thin clients in this picture? Are they counted as ultrathin clients, because they have no local computing power? Are they counted as thick clients, because they provide a full blown desktop? It is not that I dislike them, au contrair… But now I need some arguments, why I should buy more of them.

  8. lorin rees

    hi jonathan,
    thanks for the informative blog. i had no idea you did such a thing until i read about you in fortune magazine.
    i have a question: have you thought of writing a book?

  9. If one can buy but one computer every 8 years, and it was a cellphone,
    what would be the best option?

  10. Ernesto

    If you do not like the term “thin clients”, should be healthy rename the “thin client” product line in your website…
    Consistency matters!

  11. Larry Hunter

    SunRay is a “thin” client like Clark Kent is thin – Superman power available as needed but no fat. “Network client” is a more accurate name but doesn’t roll off the tongue easily. How about calling it a “netport” or other name like that, preferably (1) easy to remember, (2) with at most two syllables, and (3) not a technically accurate definition. Let the name acquire its meaning, like “browser” or “Google” or “PC” or … Jonathan is right, “thin” is right physically but not functionally.

  12. Kevin Hutchinson

    Last week you said you’d have some great announcements for this week. So far this week, your press releases have said: 1) We’re giving cheap stuff to start-ups 2) Our kit is certified to run Ubuntu Linux. Hmmmm, I’m underwhelmed. Where’s the beef?

  13. MN

    There was a time ~ 10 years ago when it was useful to note two different client paradigms. One paradigm was that of a “fat” client (AKA “the hairball on the desktop”) and another paradigm was that of a “thin” client (AKA a standardized, minimally acceptable client for network and webtone based computing). As useful as such distinctions were during those early days, I must concur with you Jonathan where you have written “one cannot have a client without at least some functionality or ‘state’ on a device, and the girth of that state (as measured by memory or storage or application footprint) directly correlates to the interactivity of the client.”

  14. Ernesto

    I was all the week long waiting for the same great announcement!
    I wish they were about “opensourcing” Java.

  15. frank gleason

    Apparently this gentleman believes in network clients also. However, he never considered the Sun Ray. At first I thought it was because the Sun Ray software does not run on linux. I found out with a quick check how wrong I was. LTSP is one of the longest lasting efforts to prompt thin clients, and K12LTSP would be an excellent gateway into the education market where IT is in total shambles. It would take little for Sun to make a big difference. And you got to love this

  16. Congrats for releasing of Java 6 Edition ! Hope so it will work perfect and should be appreciated by millions of ppl.

  17. I agree that the relation between clients and servers are changing, it is still not clear how companies are going to leverage it though.
    Anyway wonderful closing thought. “Different isn’t always better. But better’s always different.”

  18. Ashok Das

    Yes Thin clients and/or Network Clients are a common name in current enterprize world, especially in asia.
    Why not think something like Mobiclient(mobile client) !!!

  19. DRC

    >I must concur with you Jonathan where you have written “one cannot
    >have a client without at least some functionality or ‘state’ on a
    >device, and the girth of that state (as measured by memory or storage
    >or application footprint) directly correlates to the interactivity of
    >the client.”
    I maintain an open source project which uses streaming video to provide very interactive stateless remote display of 3D applications over a network (so interactive that you can play Quake with it.) The traditional notion of “thin client” is tied to the lack of state or storage on the client and the homogeneity of the client from the point of view of the server. A true “thin client” does nothing but receive and decompress images. Thus, as Jonathan pointed out, a browser does not qualify. Neither does an X terminal, because it is not stateless, nor is it homogeneous.
    The stateless nature of thin clients has nothing to do with their interactivity (or lack thereof.) Really, all you need in order to maintain interactivity in a thin client environment is 1) sufficient network bandwidth, 2) sufficient CPU horsepower (on both server and client), and 3) an efficient image compression algorithm. Available CPU horsepower is increasing at a much faster rate than available network bandwidth, which makes it easier in the long term to use more efficient compression algorithms and still maintain interactive performance. Currently my project can compress or decompress standard JPEG images at 30+ Megapixels/sec at a high enough quality that the human eye cannot perceive the loss. 5 years from now, I expect to be able to do the same thing with wavelet-based algorithms, providing the same interactive performance with much less usage of network bandwidth.
    There are some high-end scientific visualization markets in which the data sets are so huge that using some form of thin client is almost a necessity. The alternative would be caching 60 GB of data from the server room onto a refrigerator-sized machine next to one’s desk (companies that deal in these types of problems consider a laptop to be a “thin client.”) But even if one doesn’t have to regularly work on 60 GB data sets, the notion of moving all storage to the cold room is still a great boon for corporations. They save time by not having to install complex application software onto hundreds of devices across the company, they can keep a tight reign on their data sets (since they never get cached onto a client workstation), and they save money by not having to deploy a big honkin’ 3D workstation for every user that might ever possibly need to run the app (instead, they deploy enough 3D servers to accommodate simultaneous concurrent use, not total use.)
    It doesn’t really matter whether a thin client is running a real O/S on a real hard disk or whether it’s running some sort of embedded O/S from ROM. What makes it thin (and, arguably, what makes it useful) is the lack of state, and what makes it interactive is its ability to receive and process images at high frame rates. The two are not directly related.

  20. Peter Firmstone

    Jonathan, look into the technology DRC employ’s, you’ll realise the possiblility of enabling the SunRay, without changing client hardware, to display 3D and Multimedia far superior than currently possible.

  21. As usual, you pose an interesting question – in this case, “How do we approach the next few billion?”

    Well, first, we need to agree what these next few billion devices will be. I’ll take a wild punt, and suggest that at least a billion of the next few billion devices will be mobile phones.

    Next, I’d like to emphasize your point – “patience isn’t a virtue when it comes to computing”. So, you’re right that an executable that can persist between uses is a good thing [TM]. But not only that. Also, long-winded installation processes are a just huge negative… especially if the software is provided at no cost to the user. In fact, if you have to manually install the software, you may have lost out to your competition before you’ve even started. So, not only should the software persist, it often needs to “just run”.

    Finally, I agree – “better is alway different”. So, something needs to change.

    So, with all that said – what is the future of software on the next billion mobile devices? The answer, if members of the Java community aren’t very, very careful, will be FlashLite. In other words, no Java at all. The Java community is at great risk of completely screwing up the opportunity that network-connected cell phones present.

    Don’t believe me? Well consider this little story 😉 A good few years ago, I suggested to a senior Sun Java person that Sun might want to consider investing a bit more in what was then J2ME, because cell phones (and other devices) were very soon going to be big business. “Oh no, you’re quite wrong,” they said. “Software on devices will never be important anywhere outside of Japan. It won’t be a global market.” I didn’t bother arguing – because I knew that some technology, from some company, would enable people to exploit the potential of networked software on devices. It was just a matter of time. I say this, only to point out that Sun’s mobile Java vision hasn’t always been infallible, and to council against complacency…

    So, here we are, at the end of 2006, looking forward to the next few billion Java-powered devices. And I think there’s a significant risk that the Java part might become almost irrelevant. Why? Because on probably >95% of Java ME devices, software can’t “just run”. It needs to be manually installed.

    So, what could be done to Java ME to compete with technologies like FlashLite? The answer: enable software to “just run”. One solution for that, might be to make it possible to deploy applets to all Java ME devices. Of course, you might want to change the name 😉 Java Applets don’t have a great rep. But there’s no doubt – Java Applets running outside a browser, on a cell phone, could be amazingly great.

    As of today, I believe you can write applets only for CDC devices, of which there are almost none. The next billion cell phones, if they have Java ME, will probably be CLDC devices. So, there we have it – applet support (with a new name, and persistence between uses) for CLDC cellphones – my “approach” for the next billion Java devices…

    Well.. that and, of course, stopping the fragmentation of the Java ME platform… “write once, run anywhere” and all that good stuff…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s