HTTP Sucks

HTTP in an anathema to the IT industry. Every day, developers waste thousands of man-hours reinventing web functionality that could be done orders of magnitude faster with a proper thick client. The siren song of web clients is an insidious one. After all, HTML is the ultimate common denominator. Its appeal is obvious: no client-side application deployment, minimal system requirements, seamless application updates, full cross-platform portability, global access: what's not to like? Actually, quite a bit.

Still better looking than Quicken With certain exceptions related to security, there's little (if anything) that can't be done with a browser. The main difference is in the amount of effort required to achieve a certain unit of functionality. As requirements surpass simple data submission and display, the amount of code required grows exponentially. HTTP and HTML were not designed to facilitate feature-rich applications so for all but the most trivial applications, developers must create or find their own framework to sit atop the limited tools they're given. Simple features like drop-down menus, trees, field validation and server-side data updates require a hodge-podge of JavaScript, DHTML, server polling and more. All this to achieve controls that are undeniably inferior to their thick-client analogues. It should be noted that, for the purposes of this article, we take "thick client" to mean "not browser-based". Technically, the term has more to do with where the bulk of the data is processed but that is not our primary concern.

Any HTTP solution must overcome a host of problems inherent to the protocol. How should the app react to the 'Back' and 'Forward' buttons? Which browsers (and their respective versions) will be supported? Must cookies be enabled? How about JavaScript? How should the app handle a user who opens multiple windows? What if a user attemtps to use the app on a second machine? What response is appropriate for a user who directly manipulates a URL? How can security be maintained if sensitive data must be sent to the client? Is there a way to provide more feature-rich widgets? How can server-side data updates be propagated to clients without an explicit user request? Will window resizing be handled intelligently? Can a user be productive without a persistent Internet connection? The list goes on.

Admittedly, frameworks do exist to address some of the above issues. Unfortunately, no serious developer can claim that even the best HTTP-based framework can compete with the foundation classes' API provided with an industrial strength language such as C++, Java, VisualBasic or the new .Net implementations. Web-based platforms introduce unnecessary comlpexity and serve to fragment the developer community rather than consolidate standards. There are thousands of commercial and homespun frameworks atop which web applications can be built. Every programmer rolling off of or onto such a project must (un)learn a host of non-transferrable skills.

We admit: web development has its place. Extremely simple applications are good candidates. The development effort for such apps should be comparable regardless of platform. Untrusted apps also make sense as web apps. Users may be reluctant to install programs unless the source is a well-known company or a mandate has come from their employer. Web-based apps that do not meet at least one of these criteria have no reason to exist. Automatic upgrades are a false consideration as the technology to force upgrades from a thick client has existed for decades.

An even more disturbing trend is the tendency of recent desktop apps towards emulating web applications. Instead of using controls provided by their API, these apps use custom-built widgets reminiscent of the kinds of foolishness seen all over the web. Nonstandard colors, bitmapped controls, decorative pictures: it's a travesty. If anything, web apps should strive to emulate their more powerful desktop brethren. There is elegance in simplicity and computer applications for which productivity is paramount are no place to explore one's individualist or artistic streaks.

Some people may think we're being selfish by dismissing an entire architecture simply because it makes developers' lives easier. These people should bear in mind that the pain will inevitably flow downstream. Someone has to pay for lost developer efficiency and the user will do so in the form of more expensive and less usable software. To all the managers out there with the power to make these decisions: avoid the temptation to be trendy. We know that web apps are the 'in' thing to develop these days. Resist the urge to follow the crowd. Do a comprehensive cost/benefit analysis when deciding to forgo thick clients in favor of a web-based application. Someone has to stop IT from further regression towards the days when every application had nary a thing in common.