In my previous post I talked a bit about the direction DHTML is taking. OK, that's one way to make an application in the future. How about the other ways? Let's take a look:

Sun's Swing/AWT

Swing has been around for quite a while, but hasn't been adopted as much as Sun had hoped. It works by taking over window drawing at the OS level and hand-drawing all of its own widgets. UIs are created with API method calls.

The obvious drawback of this is that Java/Swing apps didn't look like other Windows apps, and they performed poorly. A good chunk of Java's reputation as a poor performer on the client can be blamed on Swing.

Recent improvements in Swing allow apps to be skinned to look just like Windows apps, and Java's performance is getting a lot better on the client. Will people give Swing a second look or just move on?

Mozilla's XUL

XUL interfaces are created in an XML markup language and rendered with the Gecko rendering engine, the same one that renders HTML for Mozilla and it's derivatives. XUL UIs use JavaScript to manage events and make calls to lower-level C++ methods through a COM-like interface called XPCOM. These lower level methods do things like read files.

XUL interfaces use skinning while rendering. While there are skins that looks like standard Windows widgets, some are slightly modified (ie. Modern) and give apps a different look and often a different feel. However the skins look the same across the different platforms.

Since the Gecko engine has been ported to many platforms, XUL interfaces can be used on all of these platforms. The lower-level code, however, must be written carefully in portable C++ code in order to be compiled and executed on all of the different platforms. This makes XUL a less than ideal cross-platform GUI tool so far.

Java integration would save XUL from this problem though.

Eclipse's SWT

SWT is IBM/Eclipse's answer to Java/Swing's cross-platform performance problems. It uses a common API but native widgets to display the GUI. The perfomance, especially on Windows, is quite good.

The problem is that all of the SWT implementations are separate, with the Windows version containing the most features. All of the other platforms play catchup. This will likely get better in the future when the Windows version slows down, however.

SWT is used via API method calls. The trend though -- with things like DHTML, XAML, XUL -- seem to be moving to XML markup languages to represent UIs. It's much easier to manipulate UIs this way, I think and SWT is probably going to be persuaded to move into this direction too. A WYSIWYG editor alone will not be good enough.

Lately SWT is also moving into the skinning direction, straying from the hey look, we're native! bragging. This complicates SWT GUIs beyond the cross-platform common denominator (sometimes custom widget to fill in gaps) approach.

Microsoft's XAML/Avalon

Avalon is Microsoft's new .NET GUI API for all of the new hardware accellerated widgets. In managed code, it's also an opportunity to introduce some new tools like XAML, an XML to object markup language.

XAML has many uses, but for UIs it can be used as a form and function seperation between GUI and application code. This lets UI designers focus on just the GUI XML while developers fool with other things like the event listeners and underlying method calls in code. At compile time the XAML XML code and C# source code are combined into one class definition.

While XAML is often compared to XUL, it appears to me that it's nothing like it. The XAML XML is converted to classes/objects that make standard Avalon API calls to display widgets. The widgets aren't rendered like XUL/Gecko, though they are rendered in the sense that they are hardware accelerated -- likely via a DirectX desktop in the same way that Apple's OS X uses OpenGL.

This makes Avalon decidedly not cross-platform, since a renderer cannot simply be ported like XUL/Gecko. In order to implement Avalon support on another platform, one would have to reimplement all of the Avalon method calls (think Wine), drawing widgets on a hardware accelerated desktop.

A hardware accelerated desktop is something that Linux does not have at the moment in mainstream use, though in development. If the Mono project wants to do it's own version of Avalon, it could be a lot of work. What I think it might do instead is make a Avalon to regular widget translation, losing some of the eye candy and functionality but retaining the general idea. It depends how much real functionality is lost I guess.

More Thoughts ...

Developers seem much less concerned about common look and feel these days. Was this ushered in by web apps, which all look different but use simple widgets? Skinning takes this to the extreme by making distinct looking UIs with equally complicated and custom widgets sometimes. This can't be good for usability, can it? While new types of widgets are interesting, it will only increase the training effort needed to use the software.

XML markup languages are all the rage, beating limited and hard to use WYSIWYG tools. I would say that with a minor amount of training and/or DHTML experience a good graphic designer could become familiar with these markups. Designers of these markup languages should keep in mind that graphic designers and UI experts are using them, and make them look HTML-like while seperating code from the GUI as much as possible.

XAML does this well, XUL -- which is scattered with JavaScript method calls on event handlers -- does not. UI designers need to be in the driver's seat with GUIs and need to be able to manipulate them quickly and freely. XML markup languages will enable this and free GUIs from API calls, putting GUIs back into the control of graphic designers and usability experts where they belong.

Cross-platform will become more, not less, of an issue. If Microsoft insists on keeping Avalon Windows-only, it could be hanging itself ... especially since Avalon won't be avalable in Longhorn until 2006 at the earliest like Joel said, and won't be in mainstream use until years later.

That's a lot of time for cross-platform solutions to catch on and for people to get used to them. Nevermind all of the (cross-platform) web apps that will be created in that time. XUL will lose out to cross platform languages and runtimes/VMs -- like Java and possibly C# with Mono -- because XUL apps are just too darned complicated at the lower levels. XUL needs to simplify there.

Eclipse's RCP is in a position to become a web browser for rich cross-platform applications with native widgets. Sun has no such platform for Swing, which could be its death knell as a GUI toolkit (developers could see it as a dead end). If Eclipse wants to get more web app developers using SWT it needs to make it easier to use and deploy -- a SWT XML markup language and (Gecko-like) renderer -- or even an XML to code translator/precompiler -- could be the answer.

Java is already well entrenched with J2EE developers, so it wouldn't be much of a switch from Java/J2EE/DHTML to Java/J2EE/SWT-XML. Eclipse could leverage all of this Java experience on the server side to switch these developers off the limited DHTML train and onto fully-featured SWT native widgets and rich cross-platform applications.