.NET Click Once can Learn Something from a Web Browser

In my day job I get to write software and try to run a company. When I moonlight, I get to be a pundit. It's really quite fun-- while scurrying about the code preparing for a release I use one side of my brain. Once the release is out, I start writing and hopefully use the other side of my brain.

In this post I'll try to use both sides of my brain to support an argument I've presented over at Read/WriteWeb. Its a two-part article that basically states Microsoft holds all the cards for capturing the next generation of computing platform, IFF they can get past themselves and improve .NET just a little bit. That is, take a cue from what makes web applications great, apply it to the .NET framework and make rich applications great again.

The article points out how .NET can be improved, but several people claim .NET already has the feature I have in mind. I claim .NET has the marketing checkbox for the feature I have in mind, but not an actual, usable implementation of it. The market must think so to, because up to now 'Smart Clients' have gone nowhere.

When you build a web page, you write the html and include references to things that help you present a page: an image here, a nifty javascript widget there and a form button yonder. What you don't have to do is compile and link everything together-- the browser does it for you. Better yet, it uses the client machine to make smart choices about what to cache and what to update. Very rarely do you need to download all the pieces comprising a web app at one time again.

And when you need to download some pieces, you never see this:



or this:



This is the advantage web browsers and web apps enjoy over desktop apps today. The current solutions I've seen are not transparent. They involve checking for updated install files, which tend to be large for desktop apps, and reinstalling newer setup.exe packages.

I'd rather it be behind the scense and done piecemeal the web way. Two rules:

• Don't Bug The User -- they don't care they are downloading updates to the app
• Don't Bug The User -- they don't care they are reinstalling an app

When I make a change to a web application, everyone gets the updates on their next page refresh without any proclamations or calls to action. .NET apps, if they want to be smart, should do the same.

Obviously there are many ways to solve this problem, so this is just an example.

A .NET app still goes through two steps in order to run: compilation and linkage. After compilation, all the component parts of a .NET app are laid out as object files in a directory structure. Usually these object files are quite small. Then the linker performs the final assembly and produces a larger output-- executables or libraries.

What if, for deployment purposes, the linkage step is not done on a build machine, but on a clients computer? What if, when starting a .NET app, a 'smart linker' is used to check for updates by making HTTP requests once in a while to all the objects files referenced on a deployment server somewhere? Then, if it finds an object file or two has been updated, it pulls down a couple kilobytes of data, links it into the app and runs.

Then the next time user with a problem runs the app, they see the problem has been fixed and they write me a note saying, 'Thanks for fixing the problem'.

As a rich application developer and publisher, I want that.

Installing Desktop Apps vs. Installing Web Apps

Who wants to download a 15MB installation file and take 5 minutes to install a classic desktop application? Especially when its so easy to point a web browser to a super spiffy web application. For instance, I could download and install a desktop collaboration tool like Groove-- which used to come in around 30MB or so before it became 'Officized.' Or I could just use a SharePoint server and my browser, which saves me the trouble, right?


Right. But did you ever wonder how many bytes that web application might take? IE7 has a nifty feature that allows you to save a web page to your local disk in a single file that contains everything the web page needs to render. I tried it on the standard SharePoint 2003 entry page for a document workspace. I saved it and noted it took 715K. Other than about 10 members, this was basically a stock document workspace page. 715K.

Let's see, 30MB / 715K == about 42. Other than being a most amazing coincidence in the universe of Douglas Adams, it means once I've look at a SharePoint document workspace page 43 times I've actually downloaded more bytes than it would have taken to install a comparable desktop based collaboration tool.

Curious.

What do you think the sum byte total of all web application page views are? Doesn't it strike you as similar to uninstalling an old mini-app and installing new mini-application with each URL click? Could there be a tipping point where it actually makes more sense to install a desktop app? Perhaps Douglas Adams knew something we didn't and 42 really is the answer.

For whatever reason, the browser has been able to better define application installation/uninstallation than the operating system. And its such a huge, overwhelming advantage that entire industries are making fortunes exploiting the gap.

Sooner or later the old dog will have to learn a new trick.