Skip to Content
Often, when I use our clunky HTML based email client, I wish my local Outlook would work. But with no VPN connection available I have to wait through those endless timespans until the HTTP server decides to show me those pages of spam I long for.

What do you think about using HTML as a basis for the log viewer? IMO it would not be so good because the fat client does have real advantages: better controls, faster response time, client side intelligence. I read more and more that the fat clients are coming back. Some companies are like an oil tanker. The whole industry just turned towards the thin client and has trouble seeing the (fat) light.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Microsoft is moving away from the browser and going back to the hard disk, I hope that SAP doesn´t follow Microsoft back there. 

    Working as a portal consultant I can say that getting rid of locally installed programs is part of my job.  There are issues such as speed to overcome and limits with the current technology but in time I hope that people can work through a browser with close to zero footprint.  When this is possible and beneficial depends on the number of users, their technical skills etc.  When everyone has broadband connections (wireless ones as well preferably) then we might see a mixed model.  Zero footprint when the user is logged off but a quick install and download of a fat client when the user is working. 

    1. Former Member
      Here is a link to a demonstration of ClickOnce, slated to come in v2 of .NET framework.  This is MS’ solution to having fat clients (with offline support) whilst having the benefits of web app deployment.

      It’s not the size of the fat client that matters, it’s the support costs involved in deploying and running your software on many clients.

      Of course, the problem with this approach is that each machine requires the .NET framework, which will take a long time.  If only MS would allow the relevant assemblies to be linked into the binary, avoiding the need for deployment of the .NET framework.


      1. Former Member
        A similar way is java webstart. ( Webstart support:
        # Multiple JREs
        # Code-signing
        # Sandboxing
        # Versioning and incremental updates
        # Desktop integration
        # Offline operation
        # Automatic installation of JREs and optional packages Application launcher

        This is portable, you can handle different JREs and you can update all clients from a central server.

  2. Fat clients are the way to go 😉 Of course it’s a shame not using all those inexpensive CPU cycles and storage capabilities that are available on the local client for the benefit of more responsive, intuitive and adaptive user interfaces. 

    The issue is more … how do we make PCs (and their applications) centrally manageable in an easy and efficient manner.

    I heart once the story that when the electrical engine was invented, initially they centralized the engine in factories, and used an ingenious system of chains etc. to distribute the power to the individual workstations. But this was long ago in the days when electrical engines were clunky, expensive and unreliable.

    Thesedays, we have small, powerful, inexpensive and reliable electrical engines available.  Every workstation in a factory has its own engine.

    I believe the PC is in the same evolutionary stage as where the electrical engine was around the turn of the century.  And I’m glad engineers have spend time on making small electrical engines viable.

    1. Former Member
      I would not have any problem with using more cpu power and hard drive functionality (temporary use) if we could run programs the same way in every operating system and on every hardware platform (new and recent ones).  This is not the case and it is expensive to deliver software that runs on every desktop OS and mobile equipment without running it with a low footprint and through a browser.  Access everywhere with any device is certainly a great vision and the browser is the best bet yet for that to come true.  We will see what the fat client followers can come up with to change the tide back.
  3. Former Member
    Having an IDE in the browser makes definitely no sense, but a lot of applications can and shall be run in the browser. The portal is definitely “just” and application, iView-development for sure an IDE-task and therefore fat. I think you cannot generalize and say fat is good thin is bad or vice versa. It depends on your application and the task. And here is were the middle has to be found.



Leave a Reply