Why the future of UIs is not the Web 2.0

Let's make two things straight at first:

• A major part of my work is to design web-based software.
• I'm intensely familiar with Ajax, and I think it's fantastic.

However, I don't believe that the so-called Web 2.0 plays any kind of major role in implementing software for serious use after about five years from now. HTML wasn't meant to be a base for UI design, and Ajax brings it's problems more visible.

Recap of the problems of HTML/CSS/JavaScript

HTML lacks many extremely necessary components like the following:

• tree view
• combo box
• menu
• tooltip
• calendar
• scroll bar
• editable and scrollable table

I addition, HTML/CSS/JavaScript lacks

• the ability to draw freeform graphics,
• proper support for dragging,
• multi-thread support (theading is one of the corner stones of building good UIs), and
• proper events (there is for example no "content changed" for a text field - the onchanged event is triggered only after the focus has left the text field).

And - last but not least - the Back button: From the user's point of view it is something close to undo but not quite. From the developers point of view, it's a tremendously difficult thing to get working in any sane fashion. In many cases the Back button should simply be disabled from the browser once the user starts a web UI.

You can, of course, circumvent many of the promblems above. You can create components manually using JavaScript or pick them from the web. And there are some pretty impressive JavaScript libraries for vector graphics and drag'n'drop, for example.

However, the following caveats still remain, no matter what:

• CSS has no namespace, which means that style rules from your CSS file can inadvertedly affect the components and vice versa. There isn't any clean and easy way to stop this from happening.
• If there is a JavaScript error in one of your components, with high probability the browser (at least IE) stops interpreting JavaScript at that very point. If your program relies heavily on JavaScript, it's now useless. Hopefully the Reload/Refresh button does something useful.
• Cross-browser support is rather difficult to come by and maintain. CSS and JavaScript are severely broken in IE 6, for example.
• Building HTML/CSS/JavaScript components is rather tricky, since there is always a risk of the component state getting mixed between the state in the DOM and the state in JavaScript. One must be prepared to rebuild the broken part of the DOM in JavaScript, which makes a nasty example of tight coupling between HTML (the DOM) and JavaScript - the looks and behaviour aren't separated after all.
• HTML/CSS/JavaScript components depend very heavily on the framework you use - sad news for the reusability of this kind of components.
• Ever tried to debug a HTML/CSS/JavaScript component? It's scary how fragile they are, even though you'd use TDD with JsUnit, for example.

All the above make me doubt very seriously the future of web UIs, sugared with Ajax or not. And considering the speed in which things are developing at W3C, I'll probably retire when they get at least half of these problems solved. Perhaps they don't even want to get them solved, I don't know.

Problems of web UIs with Ajax

Once people start to give up the current form-based paradigm (every update action of the UI is preceded by a link or a submit request) and start building more interactive web UIs with Ajax, the sorry state of the DOM, its events and its unreliability becomes more and more evident. Actually, one must wonder how a technology as horrible as HTML user interfaces has had the chance to live as far as year 2006. Alan Cooper said already in 1995 in his book About Face that the architecture of web user interfaces is a joke. I wish someone would have listened.

One explanation for the success of HTML UIs in addition to the non-existent installation phase is that they are easy to implement. As long as the system works in a form-based fashion and the Back button is in practise disabled using cookies, implementing the logic needed for HTML UIs is incredibly simple compared to implementing a full desktop UI with drag'n'drop etc. Thus, form-based HTML UIs can be built with less skilled workers. And an additional benefit: the behaviour of the software can nicely be separated from the looks, since the HTML artist builds the looks and the behaviour is implemented by the technology expert on the server side.

Ajax, I'm afraid, is going to change this, because it requires the former server-focused developers to become aware of things like component events in the DOM. This is quite a requirement for an average developer, since for example the very clever and skillful server-side web developers I work with are amazingly ignorant even in basic HTML, so I wouldn't bet on them wanting to learn anything about the idiotics of DOM events. The DOM is such an unsuitable environment to build UIs that Ajax UIs probably become more difficult to implement than for example Swing UIs. Or then perhaps the power of Ajax is only taken partly in use, which means the UIs built with it are only a fraction of what they could be - a sad thing from the perpective of a UI designer (like me) or an end-user.

The killer technology?

I'm far too cautious to advertise any current technology to be The Winner, but I seriously believe that technologies like Java Web Start will be a better bet than HTML + Ajax at least for implementing UIs that the users do a lot of work with, i.e. the most necessary pieces of software the users use on a daily basis. Java Web Start for example has none of the problems above: you can create reusable, robust components in Java, the existing component set already contains the missing ones mentioned above, there are practically no limits in interaction methods, so you can use drag'n'drop, live searches etc. with much less work than with Ajax and HTML. The downside is the time needed to download the application, but hopefully increased bandwidth and tuned techonolgy will cure this. If the download is as easy as in Flash games, it isn't a problem anymore.

I don't believe in pure client side software - of course there will probably be at least a modest server side in the application as well, since it's practical to keep at least the shared data (in form of a database or some other storage) on the server, for example. However, interaction of the UI should be handled locally and not on the server: the user needs and should be granted immediate feedback. After all, there is a lot of unused processor time on the user's machine compared to the busy server.

There will always be a market for non-installable software, but the web simply isn't the technology base of the future.