User Interface Programming

In search of the Unholy Grail or Why Web App­li­ca­tions are Evil

Java Web Start, from Sun, is an application deployment technology that lets you download and install Java app­li­ca­t­ions without the traditional installation and up­grad­ing hassles and without compromising security. In a similar vein, Windows Instal­ler combined with .NET assemblies allows on-demand installation and up­grad­ing as well as a secure execution environment (sandbox).

Real app­li­ca­t­ions (sometimes called fat clients, but perhaps better termed rich clients, but then again, that would seriously screw up my title) have many benefits over web app­li­ca­t­ions (thin clients). They have much richer and more responsive user interfaces (including, but not limited to, drag-and-drop, integration with the desktop and with other app­li­ca­t­ions), they can run even if the browser does not, they are less dependent on connection speed, and they let you work offline.

In 1997, around the time NCs failed to save the world, the applet-based Corel Office for Java was a miserable failure. How usable would Microsoft Office be as a suite of web app­li­ca­t­ions? I’m writing this in Microsoft Word; if I had to do it in a web-form text field I would go mad.

In an interview with InfoWorld last year, Alan Cooper said:

“The browser is a red herring; it’s a dead end. The idea of having batched processing inside a very stupid pro­g­ram that’s controlled remotely is a software architecture that was invented about 25 years ago by IBM, and was abandoned about 20 years ago because it’s a bad architecture. We’ve gone tremendously retrograde by bringing in web browsers. We have stepped backward in terms of user interface, capability, and the breadth of our thinking about what we could do as a civilization. The browser is a very weak and stupid pro­g­ram because it was written as essentially a master’s thesis inside a university and as an experiment.”

Whatever the color of the fish, it is certain that the browser was designed to dis­semi­nate hyper­text, not to serve as an application platform. Over the years, an amazing plethora of duct tape, chewing gum, and paper clips has been invented to rectify this, starting with the original CGI specification. Later came more efficient ways to extend the web server — first ISAPI and NSAPI, then seriously clever stuff like ASP and JSP, which mixes HTML with VB or Java, the HTML itself mixed with various in­com­patible client-side scripting languages operating on various in­com­patible DOMs. The browser expanded its understanding beyond scripting languages and DOMs to include embedded objects (Java applets, ActiveX con­t­rols), and client-side cookies help manage a sort of “meta-session” on top of a sessionless protocol.

Rube Goldberg would’ve been proud.

Mixing presentation and content is inherently evil; it gets in the way of effective maintenance. And, just like the Pleistocene 3270 terminal, the browser application reloads the entire screen on each push of a Submit but­ton — an extraordinary wastefulness of bandwidth.

The entire hypertext navigation paradigm of the browser is hostile to app­li­ca­t­ions. By a formula I just derived, 82.5 percent of all web application development is spent fighting the confusion of the back but­ton, the difficulties of multiple browser windows, and the evil of HTML frames. And double-clicks! We’ll never know how many bills have been paid twice because of an inadvertent double-click.

Now fat clients are making a comeback, and it’s time again to start thinking about “what we could do as a civilization.” (Cooper is always modest in his phrasing.)

Then we can go back to using the browser for its intended purpose.

---

(Start bottom menu)

Top • Home • Articles • Book • Resources
Win­dows De­vel­oper Maga­zine • R&D Books • CMP Books
Amazon.com • Amazon.co.uk • Contact Petter Hesselberg

(End bottom menu)