here’s no brawl like the brawl over a GUI technology. XML is the new entrant into this particular pit-fight, and it looks like the ultimate winner to me. XML is not the winner today, but it fences off such a big chunk of potential that existing GUI players such as .NET and Java don’t wow me that much any more. If you do GUI development, start watching XML; it’s easy to write, easy to change, and perfectly suited to the fluid and subjective nature of GUI development. Also, because XML is a crossover technology, it has a huge potential user-base: all GUI programmers, both Web and traditional.

One of the easiest ways to find a dying piece of software is to look for one that’s getting a new GUI. Somehow, refreshing the GUI is supposed to give the application new life. It’s an Elvis kind of thing. If only such magic applied to GUI technology itself. For general-purpose programmers, I’d say most 20th century GUI technology stinks.

Tools Make Statements
GUI technology is a touchy area, too. Your choice of tool makes a statement about you, because of the highly visible output of your work. It’s not a free choice, either. Most GUI technologies don’t come in pure form. When you commit to a GUI technology, you also commit to a bunch of other technologies that help to tie your applications to a particular platform or technology. The commercial GUI vendors know that unbundling the GUI from their product infrastructure is a suicide play. If it looks and acts just like Microsoft Windows, who cares if it’s really Windows underneath or not? Style can rule over content. No wonder the folks at Lindows.com have had legal hassles with Microsoft.

When you code in someone’s GUI, the rest of the enabling technology?an operating system, some application, or a specific language?also arrives at your doorstep.

Developers have waited 30 years for a simple cross-platform GUI technology to come along, but what we have isn’t very efficient. We have X-Windows and Xt, which are about as much fun as hand-coding in assembly language. We have Smalltalk, which was hopeful, but never reached its potential. We’ve seen endless class libraries such as Xaw, GTK, Qt, Java’s AWT and Swing, and pure commercial plays such as Galaxy. Sure, these solutions are powerful, and when combined with a scripting language they’re even palatable?but they still require learning an object library. Learn a library just for a pop-up window? Give me a break. It seems that there’s no really simple way to express just a GUI. I’d rather hide entirely inside a closed and specialized 4GL?or an application server?than use a generic GUI toolkit, even though those environments aren’t as flexible as I’d like.

At least Microsoft knows this. That’s why the MessageBox function exists. MessageBox, and its JavaScript equivalent, alert(), are possibly the most accessible functions in Windows and Java. Write one line in your favorite language and up comes a dialog window, nicely formatted, with icons and a title, appropriate buttons?the works. It’s easy and instant. Easy is good. Microsoft would tie the whole of .NET to that one MessageBox call if they could. Oracle would tie every server they have to SQL*Forms if they could. Apple did tie the whole concept and internals of the Macintosh to their look-and-feel, via a set of design standards. When you marry the girl, you marry her family. When you code in someone’s GUI, the rest of the enabling technology?an operating system, some application, or a specific language?also arrives at your doorstep. There’s that bundling problem again.

As soon as you step beyond Windows’ MessageBox, or Java’s alert() function, both technologies become complex quickly. Windows programmers know this. VB GUI programmers know that moving to .NET means hitting the library learning curve again. At one time, I thought Java would unbundle the GUI, with its then-AWT-now-Swing, GUI technology, but no more. Java’s Swing, for all its cross-platform value, is just another GUI object library to learn. Java pundits grouse that the Web applet sneak-attack, delivered as it was from inside the successful uptake of Web browsers, didn’t grab the desktop when it should have. Truly robust flexible GUI applet technology would have been an alternative to the entirely bundled-up Windows GUI. Java applets, however, are just as closely tied to the general Java infrastructure as MessageBox is to Win32.

XML is Better than a Library
All this “which library?” discussion obscures developers’ real needs. The GUI is the most fragile, changeable, arbitrary bit of all software packages, due to those flesh and blood users and their finicky tastes. You have to start on a GUI early, show it often, and change it more often. Class libraries, even scripted ones, are too structured for the super-fluid changes that GUIs require. GUI technology has been too clunky if you just want to get it out there.

You write your GUI using XUL tags, just like any other XML file, load it into a Mozilla-based browser and there it is. No HTML, no object library, and no standard browser toolbars.

I’m tired of the productivity debate between millions of Java coders and millions of Windows coders. Have you noticed that those millions of Web coders have cranked out billions of Web pages? Even if it’s not programming, HTML is really fast to produce. Programmers should be paying attention. But HTML pages?intended for hypertext, remember?are deeply abused every time someone adds a form. Forms turn hypertext into a sort of Frankenstein’s Monster GUI, half alive, which must be tamed by a graphic designer before anyone can use it. HTML will never be a real GUI tool.

But now, finally, HTML has a pure GUI brother. It is an application of XML, whose tags describe the controls typically found in GUI libraries. It’s not a W3C standard, and it’s not fully polished, but it is well-tested. It’s called XUL and it’s in the Mozilla project. You write your GUI using XUL tags, just like any other XML file, load it into a Mozilla-based browser and there it is. No HTML, no object library, and no standard browser toolbars. You add scripting to handle user input or shunt server messages around. The Mozilla engine can run turnkey or it can be embedded. Creating XUL documents is nearly as fast as creating HTML, but the results are much more impressive. XUL documents look nothing like HTML’s weak user interfaces.

XUL is about equal to HTML 2.0 in maturity, if not in adoption?in other words, it’s still young. Still, XUL documents are totally portable today, and the best XUL engine we have (Mozilla) is also widely ported. It can run with or without the Web. XUL is complimented by XBL, another emerging standard. XBL lets you construct new GUI widget tags out of existing XUL tags, and tie those new tags to real code to make them go. You’re not locked into a feature set.

Apart from Mozilla’s XUL there are several other XML-based UIs. Enode is a proprietary Java-based XML UI. Luxor is an experimental but Open Source Java-based XML UI. There’s also a rather cumbersome and abstract attempt at a formal XML UI standard, called UIML. Alas, other XML UI projects seem to have died aborning, such as www.xulux.org.

XUL is the most practical and complete of these options. Because XUL is XML, in Mozilla it is integrated with standards such as CSS, XSLT, and JavaScript. I think this Web technology integration is a very competitive offering. It’s not that it enhances the Web, although that’s true too; it is more that it brings the development benefits of the Web to ordinary desktop applications. They’re easier to make with XUL.

Can’t Be Intimidated
XUL stands up to the alternatives. .NET attempts to hide well-known Web standards inside its own architecture, presenting the developer with a separate application framework. XUL uses the Web’s standard document-centric model. It’s plain old Web stuff, so there’s no need to learn a new conceptual language. That’s a far easier path than .NET. XUL is no Java acolyte either. Being XML, it must be interpreted and that’s historically Java’s sore point. Java’s mantra is “Write Once, Run Anywhere,” but if your application is already portable (because it’s XUL), does it really matter if your engine is written in Java or .NET? I don’t think so.

Java is a well-established cross-platform implementation language. IBM now has a history of releasing strategic Java tools. IBM wants to encourage XML-based business programming. Let’s see IBM announce an XUL engine written in Java. The former browser war will look like a skirmish. To see why, recall the hysteria when HTML was thought to be the new desktop. Microsoft responded by hacking Active Desktop into Windows. XUL is far more desktop-like than HTML ever was. It looks like every application or control you’ve ever seen. The idea of a portable, downloadable GUI?a modernized version of the 3270 terminal’s original goals?would surely appeal to IBM’s sense of irony, and its desire for server-centric computing.

XUL is a breath of fresh air for GUI developers. To me, there’s no other future. It has that comforting old-fashioned buzzword-compliance feel about it: cross-platform, human readable, client-server, extensible, integrated. Most of all, it has the beauty of simplicity. What we need now is some serious standards action, and one more significant XUL engine?just to keep Mozilla honest.