Recently, I’ve had several discussions with other developers about UI frameworks. One of the more interesting outcomes is my new desire to create desktop applications using traditionally web-based frameworks. I know it sounds weird, but after looking at the current UI framework landscape and factoring in the latest directions in rich Internet applications, it may not be too crazy. People like Jon Udell and Adam Bosworth have spent considerable time discussing the subject. Currently, there are several possible UI frameworks to choose from for commercial, shrink-wrapped applications (it’s what I do):
- MFC (Win32) – This popular framework should be avoided for new development. It’s a dinosaur and will drag your application back into the stone age. It’s quickly losing its leading edge status.
- WTL (Win32) – This framework makes good use of modern C++ techniques, but it’s in somewhat of a niche. Again, I don’t think it should be used for new development.
- VCL (Win32/NET) – I have always liked using this framework. It’s really a predecessor to WinForms and .NET libraries. Ease of use and UI productivity is definitely high. There’s even a nice migration to .NET from Win32. Borland’s commitment is the biggest problem with this framework.
- WinForms (NET) – The newest framework on block. Same RAD benefits of VCL, without the Borland problem. Well, not exactly. Microsoft is likely to moth-ball this framework before it really has a chance to succeed.
- Avalon (NET) – The “on-deck” framework, not exactly ready for prime time. You can bet Microsoft will throw a lot of developer support at the framework, but when will it be production ready? And why only run on WinXP and greater? Win2K will still be active for a while and in numbers that commercial applications won’t be able to ignore. Perhaps the security benefits of WinXP will cause migration to occur faster.
- Rich Internet Apps (DHTML / FLEX / Laszlo / XUL) – Not really a framework, but a new category altogether. These kinds of applications are generally browser-based and are really starting to generate a lot of interest. Providing rich applications through a browser results in a better user experience than traditional webpage applications. In addition, these applications are built on frameworks that are also enterprise-ready, with regard to deployment and scalability. However, there appears to be no traction in the desktop application area.
Overall, the UI framework landscape is in the worst shape I have seen in years. As bad as I feel about MFC, at least there was a time where it was ubiquitous, leading-edge and strongly supported. Those days are gone and no other framework has stepped up yet (in reality, not hype). WinForms is probably the safest way to go for now for the following reasons:
- It exists right now. Version 2 will be delivered in 2005.
- It is currently built on Win32 API and support for Win32 API will not go away quickly.
Something else I think about is risk. The UI frameworks listed above all have some form of vendor lock-in or platform lock-in. I don’t feel DHTML has lock-in. I am free to use various implementations on various platforms. It seems like less of a risk when I am not dependent on another company’s UI framework. Hey, I try to separate business logic/data from UI code as much as I can, but that only helps mitigate the risk. The risk is still there, the cost of swapping UI frameworks is just smaller. Even XUL and FLEX have lock-in. Laszlo seems to have a plan for using Flash and .NET runtimes, which is a good thing.
What I am thinking about is creating a bare-bones DHTML desktop application runtime using MSHTML (for starters). Much of the needed functionality is already there. I have already posted a couple entries on using MSHTML to augment your Win32 or .NET application. The big difference now is that MSHTML would actual host your application. Think of it as a specialized web browser. Instead of browsing web pages, the primary function would be hosting DHTML applications. Whatever functionality is not already present could be added (generically) using MSHTML extension interfaces.
If rich Internet applications like Oddpost can be built, surely kick-ass desktop applications are possible as well.