The miracle of Web apps gone wrong

Remember when Web-based applications were going to save us all? Nothing to install on the local system, quick and easy access, centralized security, lower TCO, and a bevy of other big benefits. Ah, those were the days. Unfortunately, it seems that those noble ideals were co-opted by the same type of mediocre programmers that made many thick apps such a disgrace — they managed to take a framework that should have resulted in far fewer IT headaches and turned it into a worse situation than before.

Here’s an example. Vital Application A was built specifically for Internet Explorer and will not work on any other browser. In fact, it was built specifically for IE 6 and will not work with IE 7 or IE 8. Vital Application B worked fine with IE 6, but a recent upgrade broke that, and it will now only work on IE 7, but only as long as nearly all the security protection settings are turned off. And so on, ad nauseum.

[ Discover what’s new in business applications with InfoWorld’s Technology: Applications newsletter and Killer Apps blog. ]

It’s an impossible position. There’s no way to make this work reliably and securely. In fact, it’s likely that browser-specific stipulations such as this will be more responsible for future IT application choice and direction rather than features and cost. Too bad if a new application is cheaper, simpler, and richer in features — if it cannot run on the currently installed user browser, you’re out of luck.

So how did we get here? Simple: Laziness, time, and a disturbing reliance on closed frameworks. It’s probably accurate to say that if anyone was going to start building an enterprise Web application at this point in time, they’d head straight for an AJAX foundation — at least I hope so. But that wasn’t available eight years ago when the application was developed. Now the app is at Version 9.45, and it’s an ungodly mess of ActiveX controls and patchwork .Net code. The application vendor has probably had several meetings to discuss the possibility of rewriting it from scratch to alleviate the constant break/fix cycle caused by the legacy code, but it’s just not feasible in this economy.

And there we are.

Users are confused, too. They see what’s happening whether they understand it or not. They use eBay; they use Facebook and Gmail and sites driven by Drupal all the time. Then they look at the applications they have to use day in and day out that resemble an Edsel in comparison. They know enough to use Firefox at home, but they’re forced to use IE at work. Users may not be IT people, but they notice things that affect their daily functions on a fundamental level.

So what’s the solution? There really isn’t one. Only time and technical Darwinism can fix this mess. Vendors that have painted themselves into a corner with browser-dependent applications will either be forced to rewrite the application as browser-agnostic or wither on the vine. IT organizations can resolve to choose more wisely when it comes to browser-based apps, demanding that they function without such restrictions. There was never a good reason to build an application that was browser-dependent, but that’s water under the bridge at this point.

I’m not saying it’s simple to build an application that functions perfectly across all browsers. It’s challenging too — but it’s far less so than trying to figure out how to shoehorn buggy six-year-old .Net code into a new release that will yet again be Windows-only.

The fundamental Web app commandment is simple: Thou shalt not use platform-specific hooks in thine Web application. There are plenty of server-side languages and tools that are more than capable of delivering the goods for just about any application: Ruby on Rails, PHP, Python, whatever. Mix in some JavaScript and jQuery, and there you go. Google Wave and Gmail are perfect examples of highly complex, high-profile applications that work in just about any browser on the planet. There’s your template, vendors. Go forth and sin no more.

This story, “The miracle of Web apps gone wrong,” was originally published at InfoWorld.com. Follow the latest developments in applications at InfoWorld.com.