Waiting for the Future of the Rich UI

Joel Spolsky was praising Firefox today (and with good reason), but towards the end of his entry he made a comment I�ve seen repeatedly over the last few months: �...there's a glimmer of hope that one day DHTML will actually improve to the point where web-based applications are just as good as Windows-based applications �.

I don�t believe DHTML, javascript or any of our current web technologies will ever evolve to the point that they can compete with native client applications. Not that you can�t do some really cool things in DHTML, but in order to be truly competitive with native client applications, the resulting product would need to be maintainable by future programmers and flexible enough to grow.

Even after browser standardization and the creation of feature rich open standards (both of which are still a dream), the code will be made up of many different syntaxes glued together as an afterthought. A simple rich web application might be made up of XHTML with CSS and embedded with SVG and ECMA-script. Some of the code may be dynamically generated on the server-side. Some validation may be repeated on the client side. The server side code could contain any number of technologies (Java, J2EE, Struts, XSLT, Tiles, JSP, perl, python, etc.).

While its interesting from an academic perspective that a simple markup language was able to be extended to support such a wide variety of features, it doesn�t provide a very practical solution for our problem. For almost 20 years, we�ve known how to create a rich interface between the user and the computer. The only thing we were missing was a safe and easy way to distribute these applications. Rather than solve the original problem, we found an existing technology that didn�t have deployment issues (html) and tried to retrofit it to act like a rich client.

I believe a better solution is to take a rich client technology and find a better way to distribute it. This has been tried before:

• Java Applets � failed because of lack of support by Microsoft, and because AWT wasn�t useful
• ActiveX � failed because it was insecure and only supported by Microsoft
• Java Webstart � failed because it only runs Java apps, and Java never took off on the desktop
• Avalon � not released yet, but this will also only be supported by Microsoft

(For those of you who are easily excited, the term failed is a relative term. I simply mean that these technologies didn�t live up to their potential)

As I�ve written earlier, Avalon looks to be an exciting technology. But in the end, it�s a Microsoft technology. It�s bound to be an extremely successful tool within the Microsoft camp, but never touched outside it.

What I really look forward to is the rest of the community looking up from their servlets to see the bigger picture. When that happens I hope to see several independent solutions from the open source community (I�m guessing the first would be from the Mono team). Until then, back to my web app.