Comparing the Cost of Web Applications and Rich Clients

  • Article

I've receieved several great comments, both online and offline, regarding my previous posts around smart clients (1,2).  All of the comments tend to revolve around the perception that web applications are, for the scenario in question, the only affordable option.  Instead of responding to the comments individually, I thought it would be a good idea to respond all at once in a new post.

First, let me make clear that I think web applications are great for certain scenarios.  I think they are great for public access terminal scenarios, for reaching users on the Internet/Extranet, and for occasionally used applications within the enterprise.  For enterprise applications which are heavily used, however, I think that a rich client is better.

Anyway, here are the points I'd like to address:

1. Rich clients are a lot more expensive to deploy than web applications

Historically, this has absolutely been true.  The .Net Framework 2.0, however, introduces a new technology called click once deployment.  This allows you to deploy rich client applications using the same techniques that you use to deploy web applications.  The client does have to have the .Net Framework 2.0 installed (more on that below).  But, once that is done, the rich client applications can be updated simply by copying new files to the web server.  You might think that rich client applications would be much larger than web applications and that they, therefore, would require more bandwidth to deploy.  .Net Framework applications, it turns out, are actually relatively small.  Unlike previous programming models, you don't have to include a bunch of system libraries and code with your application.  All of that stuff has already been deployed with the framework.  In fact, if your web application has a lot of graphics, or uses add ins like Flash, it may actually be larger than a .Net Framework 2.0 rich client application.  If you'd like to try this out for yourself, you can access a hands on lab here.

2. Deploying the .Net Framework 2.0 is too much work

All applications have to run in some sort of environment.  Browser based applications require a browser.  IM applications require an IM client.  Reading PDF documents requires the Adobe client software.  Flash applications require the flash runtime.  Etc.  All of these environments had to be installed on the client machine at one point.  They all need to be updated as security patches and new versions (with new features) are released.  It seems to me that there is no reason that the .Net Framework 2.0 can't be made part of the basic client install "image", in the same way that these other environments are.  Granted, it will take some time before the new image is rolled out to all of the workstations, but, it seems like it should be possible to include the deployment of the .Net Framework 2.0 as part of this existing process.

3. Existing web applications can run offline without re-work

I discussed in a previous post the questions I get about deploying a web server on a laptop so that a web application can be taken offline.  I made the point that, if you are going to pay the deployment cost, why not deploy a rich client application.  A very good coment was made that, if the web application already exists, isn't it cheaper to keep the web application instead of re-writing it into a rich client.  The catch here is that the data needed by the web application also needs to be copied to the laptop.  By the time you are finished modifying the application to handle data synhronization and other issues, you may find that re-architecting it to a rich client user interface isn't that much extra cost.  In fact, if you use click once deployment, in the long run, the cost will be much less than trying to keep all of the web pages on all of the web servers on all of the laptops up to date.

4. User productivity benefits are intangible

While I agree that enterprises don't have good ways of measuring user productivity, I think that bad user interfaces can have a profound cost for an organization.  If you have a frequently used application, and 50 users, if you can save just 10 minutes a day for each user with a better interface, you would get over 8 hours in time savings per day.  That is like getting an extra employee.  I really think that user costs need to be factored into the overall application cost decisions.

Thanks again for all of the comments.  I appreciate the dialog and hope that it continues.

-David