Knowledge brings fear ... Prosthetic Conscious

When I read an intro to .NET a year or so ago, it was touting support for downloadable applications. It's a pretty simple idea. You connect to a web address and download the code for an application. Maybe you authenticate first, or make a payment. The application runs, and leaves no trace on the local system. Moreover, it's zero install. The user can walk up to any PC with access to the web and run their application. There are no more upgrades, because the most current version of the app is downloaded freshly each time. Developers don't need to worry about installing their application.

Sound familiar? Remember Applets? Applets have been around much longer than .NET. Why were they not a success?

1. Not true zero install. The client had to install a browser plugin.
2. Compatibility. Said browser plugins were always behind the curve. Developers were stuck writing applets against the oldest possible versions of Java.
3. Performance. Applets, and Java apps, were slow.
   

Now we have something calling Web Start, which solves #2, sort of. This downloads the app and runs it using a locally installed JVM, not a browser plugin. This makes it much easier to have the latest, greatest version of the JVM accessible to the app. #1 can't really be solved unless Java can be made part of the major PC OS distributions (OS X, Linux, Windows). By "part", I mean that software developers can assume it's there even on a minimal install of the OS. In reality, I have a hard time understanding that this is a problem. On every modern OS I've every used it's been trivial to make Java available. Sun has even created a license which allows Java to be included directly in Linux distributions. As for #3 ... everyday I use a 100% Java IDE on a less than high-performing desktop system and it is definitely usable. To be fair, the system has a good amount RAM, which is one of the major complaints about Java apps.

Enter Javascript applications. They can run on any browser that supports Javascript (which is all of them). They are truly zero install as they run in the browser application. They perform reasonably with a low memory footprint. On the other hand, you have the problem of browser dependence. As a software engineer, I have for the most part found Javascript based solutions offensive. When using Javascript, one is almost always forced to do "hacky" sort of things. Javascript solutions never seem to be put together cleanly. I am not exactly sure why that is though. Maybe it's because Javascript is often written by web designers not software engineers. Maybe it is because Javascript is less structured and doesn't push developers into writing more structured applications.

And then we have Flash. Flash applications run in a plugin so they don't have the browser dependence issue. However, they suffer from the "not zero install" issue just like Java. And they potentially suffer from compatibility problems as well. Despite this, they are becoming more and more popular.

Both straight Javascript and Flash have taken the downloadable application meal away from Sun + Java. It's quite sad. As a developer, I'd much rather be writing an application using Java's well-designed UI frameworks than writing Flash or Javascript. The problems with Java as a downloadable application seem to me to have been solvable. Either technically, through partnerships, or via some well-designed "examples" that can showcase the solution.

Sun has a good example internally in their bug tracking software. It's 100% Java and deployed via Web Start. It works flawlessly on every platform I've tried it on and it performs well.

I don't know what Sun's plans are around this problem. Considering the popularity of delivering applications over the web, they would be well advised to be looking into this and coming up with some solutions.