April 10, 2001, 5:24 PM —
Let's recall the boundaries for this series. We're looking at GUI toolkits applicable to a broad range of office automation and engineering tasks, including system administration, medium-duty engineering automation and analysis, point-of-sale transactions, and so on. Widget set is still the rough synonym for toolkit in some domains. We'll leave specialized three-dimensional, virtual reality (VR), and gaming toolkits for another day, but note that the general-purpose toolkits we discuss have been the basis for many fine games and VR projects.
We also require that our toolkits be portable at least across the leading Unix and Windows platforms, and across a range of conventional development languages. Several fascinating GUI models, including DrScheme, Clean, NeXT, MetaCard, a couple of different Smalltalk and Forth libraries, Delphi, and G2, exhibit remarkable productivity under at least some circumstances. These all deserve consideration at another time; however, they don't fit the current series.
Web wins out
Unlikely as it would have seemed a decade ago, the real winner of the widget wars is the Web. The single toolkit we find ourselves most often using is the one HTML specifies.
Of course, thousands of books describe Web applications or selected aspects of them. Distill from these a pair of conclusions that fit our comparison:
- Deployment matters. Numerous times, we've heard professional developers moan about how impoverished and inadequate browsers are as a GUI. It doesn't matter, though, to the decision-makers who end up buying Web solutions that they understand rather than the fragile, handcrafted elaborations that programmers often prefer.
- The Web can do more than you realize. We periodically document in our Regular Expressions column the wonderful things that experts do with JavaScript, plug-ins, and an assortment of server-side facilities. The growing acceptance of DHTML gives Web applications approximately the full range of GUI capabilities that other toolkits enjoy.
Even if you know you're going to a different technology for a final delivery, it's OK to prototype applications with a simple Web design. You can often learn crucial usability results with that first rough draft.
Plenty of the world's applications require no more than a bit of Web sophistication. If this kind of work appeals to you, you'll be busy for a long time.
Notice that this wrap-up to our series is as textual as all the other installments. We've used no graphics in a discussion of graphical toolkits! This is because we're comparing the toolkits at the character level, which is of greater significance than cosmetic appearance. A different series of articles might justly compare the fashions of button details in Netscape 3, Internet Explorer 4, Opera, and Motif. Such a focus would help some projects more than our series does.
Our aim is to help developers get a feel for different programming libraries. The on-screen appearance of a typical Web application has changed over time, and admits a great deal of customization in the hands of a clever practitioner. Through all these changes, though, the Web's essence has been to model stateless, transaction-oriented, client-server operations with particular restrictions on the messages passed. That's the inner nature this series seeks to convey.
Java: Capable, widely accepted, and heavy
Java's Abstract Windowing Toolkit (AWT) and Swing are standard in many organizations. As with Web applications, there's extensive literature on these libraries, an abundance of vendors providing training, and at least nominal standardization in many US universities on Java as a teaching vehicle.
We have reservations about Java, particularly for GUI work. There's a lot to like about Swing's engineering. However, the technology trade-offs Swing embodies consistently fit our needs less comfortably than the toolkits we've covered in this series. Java is nearly unique in being able to specify rotating text in Arabic script with standard options. The predictable consequence of this high level of generality is that Java is relatively cumbersome for more common operations.
