I witnessed a recent BOF conversation in which the general feeling was that the browser GUI and its accompanying plethora of back-end frameworks had let people down by delivering a poor return on investment and a weak user-interface experience.

The Revenge of the Server
To predict the future you must study the past. Once upon a time servers ruled the kingdom of IT, with mainframe boxes delivering computing power to users who attached themselves via terminals. Then the GUI arrived along with cheaper and faster personal computers that promised a high-function user interface, challenging the era of the server. Early attempts to solve the client/server dichotomy exposed the weaknesses and strengths of both: the GUI delivered usability and high-end functionality while the server offered easier deployment and overall systems integrity. The server attacked the perceived strength of the client by offering a browser that provided a GUI, allowing green terminal users to put a fresh coat of paint on their applications. To all but the most belligerent among us, the browser had become the de facto user interface of the late twentieth and early twenty-first centuries.

The Clone Wars
It became clear, however, that to deliver a serious business application, an HTML user interface was just part of the story, and issues such as session state, transactions, and page management needed tackling. Back-end frameworks arose to handle these while front-end innovation faltered as forays into the world of JavaScript and other tricks to spruce up the user interface failed because proprietary extensions targeting particular operating systems couldn't do so without sacrificing the ubiquity of raw HTML. All Web applications ended up looking a lot like each other as the force pushed them toward the lowest common denominator, resulting in effective stagnation of the browser user interface.

Navigating, validating, or dealing with multiple forms simultaneously are a client applications' home territory; however, as the browser struggled with these, Mark Andreessen, Netscape's inventor, famously remarked:

There was one feature that was temporary in Mosaic: the Back and Forward buttons. That never made a lot of sense to us. Back to what? Forward to what? We thought there would be a better way to navigate. But no one ever came up with one. ... There's nothing emerging right now. Creativity stopped in 1997...
www.pcworld.com/news/article/0,aid,110156,00.asp

Form entry pages where information is left incomplete have to incur an entire server round-trip to determine the errant field, after which a new page is presented to the user with red text highlighting the areas that need attention. Sensitive information such as passwords is often not included in the error page returned to the user, so fixing the first error can just reveal further problems as this is now the missing required data. Pressing the back button can throw up the error message: "The page you requested cannot be displayed as it is the result of a post operation - please press Reload to refresh", after which a further dialog asks you to confirm whether this is really your intention. As Dr. Jakob Nielsen observed: "Billions of dollars are wasted every year in lost productivity as people wait for Web pages to perform duties that could have been handled better by a 1984 Macintosh-style graphical user interface application (www.useit.com/jakob)."

New Hope
It's never enough to score a victory simply by recognizing a strength in your opponent's argument and turning this to your advantage, for soon they will do likewise. The strength of the server is that it provides a single way to administer the client applications and HTML is a ubiquitous GUI format that can be read on almost every operating system. The force pushed the client to invent a way to have a full-fledged user interface that could be updated centrally by the server. Java Web Start now offers this. Although applets suffered problems in their initial incarnations, improvements made in 1.4 and beyond now mean they are a viable way to deliver a fully functioning Java GUI via a browser. Java's mantra of "write once, run anywhere" suits those wishing to write a GUI that can be delivered across a wide variety of platforms, and Swing improvements in the past few years now mean that it offers a high function point that couples good platform fidelity with a set of powerful frameworks. For those wishing to program in Java and enjoy native platform widgets directly, SWT provides a very good toolkit.

The Client Strikes Back
The problems that plagued early client/server for deployment and homogeneity with native appearance are solved. As the Web folks realized once HTML's glitz wore off, more is required than just serving up a fancy GUI. Application frameworks are required and JDNC is a powerful technology that provides a way to attach a Java GUI to back-end data. JSR 273, which was recently approved, promises to overhaul the JavaBeans component model specification and allow tools builders to create an easier and more powerful programming experience. Web services were once described to me as "HTML for non-carbon based life forms," the inference being that programs could send and receive messages using the simplicity of HTTP and the Web without needing a browser to render the data for a user to interpret. As more APIs from companies whose fame arose through the browser become published as Web services, the wealth of data behind the Web can become consumed by fully functioning Java client GUIs. It seems ironic that the transport of data over HTTP, the backbone that launched the Web, might become the new model for client/server, and Web services will propel the next generation of rich GUIs. The force is with us yet.