Real Story Group. Make Better Technology Decisions.

Kas Thomas

Web UI development: inherently slow?

22-Jul-2008

Tags: Portals and Content Integration, Web Content Management, Implementation, Information Architecture, Red Hat: JBoss Enterprise Portal Platform, WebSphere Portal Server

In a thoughtful post at JavaLobby, developer Ali Loghmani poses a simple but important question: Why is Web UI development so slow?

Here, Loghmani is not just talking about the creation and placement of AJAX widgets on web pages. He is talking about full-cycle development and testing of web and portlet interfaces that integrate with popular MVC webapp frameworks such as Grails, Django, Tapestry, or any of a slew of others.

The reason this is an important question, of course, is that people write custom web and intranet apps against their DAM, WCM, ECM, and Portal systems all the time, whether for public-facing B2C apps or just to create a CMS front-end that content contributors will actually use. And it is invariably a resource-intensive process. Gobs of time, money, and engineering talent go into the creation of web interfaces (and the code that binds those interfaces to back-end business logic).

Loghmani laments the protracted program-test-debug time in development frameworks that require (as many do) redeployment of files to an appserver before changes can be previewed. This is certainly a problem. It's one thing to do an eye-pleasing mockup of an AJAX webform in a browser; quite another to wire it into JSF and do full-cycle debugging in WebSphere, say, or JBoss (or whatever).

There's also the perennial cross-browser compatibility bugaboo. Web UIs tend (still) to perform differently in different browsers, necessitating ugly "browser-check" code with parallel logic branches to handle the various browser types and their legacy quirks. Writing and testing this kind of code takes time.

Of course, to some degree UI development is an inherently hard problem. The mapping of widget states to program states is not always straightforward. To the contrary, the possible permutations are more often than not incalculable, and the potential side-effects legion. You can't expect this kind of programming to go quickly.

In the end, Loghmani argues that the sheer complexity of popular MVC frameworks is a major (perhaps the major) contributor to long UI development times. As much as I value simplicity, I have to disagree here. In my experience, complexity is not a bad thing per se if you can properly hide it. Twenty years ago, three-person crews were the norm on airliners. Today it's almost entirely two-person crews. Ironically, the airplanes have gotten much more complex, but the human interface has been refined to the point where you no longer need a "flight engineer." This is an example of how complexity can be hidden, to good effect.

I think one could argue that the main reason Web UI development is slow is because insufficient tooling exists to make it quick and easy. Things like Tapestry and JSF (and appservers) are complex, with many moving parts. Developers are constantly having to open the hood and make hand adjustments to rather intricate machinery, using only basic hand-tools.

In the post-2.0 world, that won't do. Time is too precious. We're going to need better tools -- or perhaps an entirely new development paradigm. Old-school MVC development, à la Struts and all the rest, is just not cost-effective any more. If indeed it ever was.