Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


New GUIs: XML Is the Heir Apparent  : Page 2

The future of GUI development isn't class libraries, frameworks or platformsit's XML.




Application Security Testing: An Integral Part of DevOps

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.

Nigel McFarlane is a freelance programmer, analyst, and author. His background is in science, telecommunications, databases,and the Internet. His current projects are in user interface technology. Reach him by e-mail at nrm@kingtide.com.au.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date