Although it comes with the start of the new year, this is not a new resolution, but I may consider myself newly resolved to tackle it. I need a new platform.

Since January of 1997 I've been building web applications. These aren't websites, mind you, these are enterprise systems with a web browser-based front end, eg. you use Internet Explorer to access the system. They are not trivial systems either -- they include systems interfaces for accounting, business partners, credit bureaus, and the usual ilk. Daily, weekly, and monthly reports and purges. Blah blah blah. Real-time interfaces to handheld point-of-sale devices. Whatever.

The user interface (UI) for all these projects has been HTML, although you can't do anything serious with just HTML. You have to add sprinklings of VBScript, JavaScript, Java, and ActiveX. And in the end you have something that's not quite entirely unlike something I would want to use.

And frankly, I hate coding for the web. Although Firefox and IE 6 represent an indescribable improvement over what I started with 8 years ago (IE 2.0? or was it 3.2?), it is horribly painful to develop a website, let alone an application, that works and looks consistent from one to the other. There is no "specification", and there is no "compiler" that could tell you whether you've done it right or not. All you can do is try something and see how it looks.

But wait, isn't there a spec for HTML? And for CSS?

You bet! But the spec is not what your goal is. Your goal is to have your web pages look and behave properly in IE and Firefox. The latest version if your lucky, the prior two or three releases if you're doing penance. And both IE and Firefox do not follow the spec perfectly. In the end, all you can do is try it in both. Then bang your head against your monitor, change a random line of code, and try it again. Repeat over and over until you stumble on a solution that works.

If only you had a thousand monkeys to do this for you.

So the experience of developing for the browser is painful, time consuming, and error prone. And, if you do anything in the browser outside of basic website stuff, you are almost guaranteed that your program will stop working with the next major browser release. It happened to me with IE 3.2, 4.0, 5.1, and 5.5.

And, all that pain is incurred to develop a UI for your program that is less interactive than a native one (e.g., a "regular" Windows program such as Outlook). Meaning, the web browser is all about request/response. Each time you select a row in a table, or click a button, the entire page is submitted and a new page sent back.

Its a horrible way to spend a day, let me tell you.

The reason we all set out to do it in the first place was to save time on deployment. In one instance we had nearly 1,000 PC's accessing the system, through a private network that spanned the globe. Its just not possible to run around to every PC and run a setup program each time we put out a new release. So we use the web browser. Several other projects did this for the same (wrong) reason. It turned out that in order to support it we had to first run around and install the right version of our chosen web browser (IE 3.2, in those days). And then force the users to stay on a supported version.

Hear my advice on this! If you have a large number of users and you want to simplify deployment, do not think the browser will help you. Do something else.

For example, in the above organization, given my present experience, I would recommend they deploy a native Windows or Java application and build-in the ability for it to update itself. In Windows you can package your modules as a set of Dynamic Link Libraries (DLL). When the application starts up, it can ask the server for the latest version number of each DLL, see if that's newer than the ones it has, and if so download them before running. In Java you can use the Webstart feature, or build your own similar to the aforementioned Windows solution.

There is a scenario where web applications make sense, and that's as part of a web site. Where anonymous users casually come and go, and you can't afford the overhead of installing a program, no matter how small it might be. And that's what CGI, PHP, ASP, JSP, and all that cruft is for. To add some dynamic content to an existing static web site.

My applications are all enterprise systems. They are used by the same people over and over again, day in and day out, all day long. Its their main productivity application in many cases. An initial install is not a horrible burden, and in many of the larger organizations they have Configuration Management tools that automate such routine tasks. Anyway, to recap, I build "enterprise" type database systems. I've been building to a web UI for 8 years now, and for the reasons given, I'm ready to move to a rich client platform.

Next time I'll describe what's in "the platform", why its taking me so long to migrate, and how I'm going to get there.