You can never be too rich or too thin

You can never be too rich or too thin

Summary: In order to sell Longhorn when it launches, Microsoft has been trying to convince everyone of the importance of rich clients. Microsoft will lose its lock on the operating system if the only thing that people run on them are browsers.

TOPICS: Google

In order to sell Longhorn when it launches, Microsoft has been trying to convince everyone of the importance of rich clients. Microsoft will lose its lock on the operating system if the only thing that people run on them are browsers. Meanwhile, CIOs love thin-client applications because of the additional overhead that rich clients bring to desktop management. Sure, desktop management tools like LANDesk and Altiris reduce the burden, but it never goes to zero.

Microsoft wants CIOs to believe that the choice between rich clients and thin clients is mutually exclusive. You can be rich or you can be thin, but you can't be both. Interestingly, Google and others are demonstrating that thin clients can be rich as well.

If you've used Google's GMail, you're probably aware that its interface is more natural than most Web applications. Still, it's obviously a Web application. For a better idea of what's possible, take a look at Google Suggest. This version of Google offers suggestions as you type. It's kind of fun to put in a few letters and see what suggestions come up.

How does this work? The quick answer is Javascript. Javascript's name and usage has given people the impression that it's a second-class programming language, not really up to snuff for serious programming. In fact, Javascript is quite capable and offers features that other programming languages do not. Most importantly, it's the language of choice for programming browsers.

Chris Justus has a detailed look at how Google Suggest works. Take a look if you're interested, but the summary is that it uses Javascript's XMLHttpRequest to communicate with the server without reloading the page. Since Javascript can manipulate the page inside the browser without rerendering it, you get a rich client feel inside a thin client browser.

One company that's elevated this to an art form is CanyonBridge Technologies. I wrote about them on my blog last year and demos I've seen since have

Topic: Google

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • And half is too much

    I won't believe the half of what Ballmer says! Your javascript arguement goes to the heart of what I've been saying all along - we have ENOUGH computer languages! Enough, is ENOUGH - but its probably TOO MUCH! The only programming language that I've ever seen that has been removed "from play" is Pascal! But with the proliferation of OSS, I have seen way, Way, WAY WAY WAY TOO MANY programming languages. They must exceed the total of human languages on the planet! Why don't we all just use one - Ada? ;)
    Roger Ramjet
    • ada? you can't be serious

      Pretty often, I'm using C or C++.
      However, I think of java as essentially a safer
      C++. gcj compiles java, and is I think in fact
      running the gnu c++ compiler. After all largely a
      compiler is in essence a binary string
      replacement system.
      It should in fact be pretty easy to write a
      universal any programming language to any
      programming language converter, perhaps using an
      SGML or ASN.1 parser as a genericised input

      ---------- Favourite languages -----------
      java - it is very neat and tidy. People think of
      it as slow because of perhaps bad implementations
      (for whatever reason). Why not compile up in gcj,
      or for windows get excelsior jet?
      PHP - man this has blown the web apps world
      apart. There are so many great web apps written
      in this!
      By the way, Eric Raymond always says let the data
      structure do the heavy lifting. Why write a ton
      of javascript to give a rich feel to a set of
      controls, why not define the behaviour in some
      kind of XML form type description (eg: XUL and so
      on). Writing tons of customised javascript is a
      messy solution.

      -------- other languages that have something
      going for them: ---------------
      Perl - has some very interesting hashing and
      associative array techniques built in.
      Forth - survives in openbios on mac and solaris
      machines for drivers. Very fast.
      Python - has a powerful object model... that's
      all I can say about it really.
      Tcl - used TkDesktop as my desktop for years. IT
      works, and it's pretty fast. I wrote a forms/data
      package in Tcl including a "form" and "view"
      editor. Man there is very little code required in
      Tcl to do this. (as it's interpreted, you can
      autogenerate more tcl). I'd use gambas in
      preference now though.

      C/C++ - I use these a lot, but I think they
      should eventually be deprecated in favour of
      java, as it's too easy to screw up as a
      programmer in C and C++.
      C sharp - pretty much like java in it's protected
      form I think, and no advantage over C++ in

      Basic/Gambas. I like Gambas a lot, it's very
      light and fast. Interpreted languages like this
      are a great way to get something done fast.

      Prolog I think should be a sublanguage to a
      database like SQL.
      Lisp - interesting in a lot of ways. This is used
      as a binding language for a lot of GNU apps
      including of course emacs. Personally I'd prefer
      something like gambas, but different folks...

      ------- Absolute consign to dustbin languages
      Modula2 and pascal

      So for me, I'd vote for PHP, java and gambas.
      (and forth for drivers).
      • Hey come on!

        Jovial and Algol have 'em beat hands down.
  • Thin clients

    The danger of thin clients is they lead to a world where you only need centralized servers and simple internet appliances. Why is that a danger? Certainly for companies like Oracle, SUN and IBM, its a dream that could put them back on top of the world. But it could also mean the end of an openly (lower-case "o") programmable platform.

    The PC has unlimited and unguessable potential, because anyone can write software for it and do whatever they want with it. Things could be invented in the future that we cannot imagine now, because of this very real freedom to program.

    The alternative is a home computer more like a Playstation, some little brick of epoxy that plugs into our television and lets us browse the web. And if you have an idea for new software, you will have to buy development kits and get your idea vetted by SONY or SUN or some other hierarchy of corporate executives.

    So beware when people start talking about thin clients. You could be walking into an evolutionary dead end of the software revolution.
    • Rich Client/ Poor Client

      So a rich client environment means the stake one has in open source is maintained, and thereby granting MS an open license to disembowel its opponents. Perhaps there's a middle ground.
    • The only danger with thin clients

      is to the army of technicians needed to keep the Windows PCs in the world running.

      After nearly 20 years supporting Windows, Mac, OS2, AS400s, and several versions of Unix/Linux I say "thin clients rule". Even Windows terminal-server clients.

      Tight security and fewer boxes to protect and patch, and the users don't even know that little box on their desk isn't a pc.

      Anyone CAN write software for wintel machines. That's why their are hundreds of thousands of programs for Windows, but only a handful that are actually used.
      • At any cost

        So is your argument, that to stop Microsoft, you would sacrifice all free programming, even open source?

        I gather you are an IT staffperson, but I'm a programmer, and I so I cannot support the idea of close thin client hardware. I think its a dead end.
        • What do you care what platform

          the software runs on.
  • Don't particularly like thin clients

    As a developer, I liked thick clients better (now morphing into "smart client" technology). Maintaining state with a smart client app. is a no-brainer. Maintaining it with a thin client app. is a chore. Even with the advances in the technology that the tool vendors have come up with, which IMO makes thin client development just bearable, it doesn't compare to the ease of smart client development. So I personally hope that the thicker client technology gets more appealing to customers. I think MS's Avalon/XAML technologies will be a step in that direction on the Windows platform. What MS is striving for, as they always have, is a unified programming model from the client to the server end. I agree with a previous post-er that the proliferation of languages does make things more difficult. Javascript is the primary language for programming the browser, but it's a scripting language with its own rules.

    A while back I listened to a talk given by a guy who came up with his own application framework for .Net that he sells, that enables one to easily design and pass objects back and forth between the presentation and data layers. It stops there, though, because there isn't really a practical way to pass objects to the client from the server.

    It's my understanding that what MS is striving for ultimately is a client system that allows the same ease of "just running the app" that you get with a browser, without the install steps, and you also get the ability to do some of the "richer" things we used to be able to do with GUI apps. using more capable languages that make doing these things easier.

    Having said that, I don't get where Ballmer is going in saying that Longhorn is THE road to this capability. MS has already announced they're going to make Avalon, WinFX, etc. available for WinXP and WinServer 2003. So I assume people with these systems will be able to get the same benefits he describes as on Longhorn. It could just be the sales pitch, to convince customers to buy Longhorn when they really don't need to, just as customers were developing for .Net because they thought it was the leading/only platform that supported XML web services.
    Mark Miller