I’ve participated in the construction of web apps off and on for at least a dozen years. But now – assuming that app refers to a robust, non-trivial business application – I’m beginning to question whether the web is an appropriate platform for developing and deploying them.
In theory, building a server-based application without a dedicated fat client seems to be a Really Good Idea. About ten years ago, I wrote an unpublished paper extolling the virtues of the web browser as a ubiquitous generic client. A that time, Electronic Software Distribution (ESD) was a hot topic as enterprises struggled to ensure that employees were using the right versions of desktop software, especially dedicated clients; recent experience at a former employer indicates that ESD is still an issue. The ability to transform a generic client into the latest version of a particular client on the fly, simply by connecting it to a particular server-based app, had obvious appeal.
At the time I wrote the paper, the commonly available technologies imposed practical limits on the “richness” of both the interface and the interaction with the server. Ten years later, the complexity of both the technology and the problem domain that it can address have multiplied. But has the adoption of these wide-ranging technologies turned modern web apps into Rube Goldberg mechanisms?
HTML is the foundation for creating a particular client on a generic browser. But now it is only a foundation on which is built CSS, JavaScript (including asynchronous server calls, modifications to the page itself, and other goodies), XML, Flash, Silverlight, and a host of other open and proprietary tools and plug-ins.
On the server side, the corresponding proliferation of app servers and scripting languages is less troubling because for any particular web app, the technology is likely limited to only a few choices. Even so, a developer in a JSP shop, for example, may confront a bewildering array of Java Server Pages, tag libraries, components, XML configuration files, frameworks, pure Java, extended versions of SQL, and both open and proprietary APIs. Much of this stuff exists only to transform the user’s browser into the required client. The problem with the client-side technologies is, as Neil McAllister writes,
While [many] of these technologies [are] defined by standards, actual practice is another matter. HTML tags that behave one way on Firefox may behave differently on Safari, and CSS support varies widely between browsers (particularly where Internet Explorer is concerned). Web developers must constantly balance between supporting the largest possible audience and delivering the user experience the client wants. [emphasis added]
For the web app developer, this balancing act adds these layers of client-side complexity to the inherent complexity of the server app itself. Yet another layer of complexity is added when the client must overcome the limitations of the web platform and simulate a server session or local storage of data. In fact, the ubiquitous generic client that I envisioned is here, but it comes at a very high cost.
Dedicated clients, for all their drawbacks, could natively manage presentation, execute code, maintain a session, and store data anywhere. Much of the complexity of web app development results from shoe-horning all that functionality into the browser. The irony is that ESD is still a problem but in a slightly different form! Given McAllister’s observations, which versions of which browsers must we deploy or support – and at what cost?
Further, in the Bad Old Days of client-server architecture, the client and the server were generally developed separately. At the very least, this separation enforced an opportunity to carefully partition the design, development, and deployment of presentation and application logic.
I am not suggesting that we should abandon the web – even with all its scaffolding – as a platform for business applications. That genie is out of the bottle, and the cost will simply have to be borne – even if Rube Goldberg-like skills are required to connect all the moving parts. My hope is that we see the development of tools and design patterns that can reduce the intertwining of client and server implementation and partition the complexity into manageable chunks.
