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 technologyan operating system, some application, or a specific languagealso 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 palatablebut 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 4GLor an application serverthan use a generic GUI toolkit, even though those environments aren't as flexible as I'd like.
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 buttonsthe 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 technologyan operating system, some application, or a specific languagealso 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.