Web applications are easier to develop

Let’s start by dispelling a few myths about web based development.

Web applications are easier to develop

Easier than what exactly? Faster than light space travel? Mapping human DNA? Or perhaps just figuring out why people watch Reality TV? It might be easier than these but it’s certainly not easier than Windows Forms based development. Here are a few bullet points of where web development, even in ASP.NET falls far short of “easy”.

  • Number of technologies used. It’s not enough to know VB or C#. To create an even remotely useful web page you have to know HTML (tags and DOM), CSS, _Javascript, and at least one programming language. Put ASP.NET WebForms architecture on that and you add the concept of server controls, postbacks, and XML. Now throw in multimedia or applets (Java or ActiveX) and it gets significantly worse.
  • Most applications don’t work in a strictly request-response paradigm. ASP.NET goes to huge lengths to overcome the basic obstacle of web development which is that it is a request and response based communication. So there is ViewState, SessionState, Application Caching, SqlDependency, Output Caching, and lots of other things all because centralized server based processing doesn’t hold state between requests. To create a robust, enterprise scale application a developer has to take on the burden of wiring together all of these various services just to be able to recognize that the user has already logged into the application. Now I will grant you that ASP.NET does a fine job of making it easier, but easier doesn’t mean easy.
  • Web based interfaces are incredibly difficult to build accurately. Any developer who has written a widely deployed web based application has gotten that call from a user saying that some piece of the web page isn’t showing up or isn’t showing up in the correct way. Even on the same browser and version (more on that later) dozens of settings from screen resolution to font sizes can change the way an interface looks between users. This leaves the developer with either having to test the interface on as many browsers as their PC will hold or simply aim for the middle and hope for the best.
  • This myth is based on the concept that it’s easier to deploy an application to a server or web farm than to 1000 desktops. But that concept is another IT slight of hand that has people looking the other way while the same deployment issues that exist with local installations get solved through different means. Specifically here are some examples of the issues involved with web based deployments.
  • Without the browser on those 1000 desktops, your web application is useless. Why then does it seem like no big deal to deploy a web browser? Simple, for the most part it’s already there. Windows (the ubiquitous desktop platform) includes Internet Explorer of some version or another. So many companies can leverage that browser and concentrate on the apps, or so they think.
  • What web based application fans might not understand is that this same argument is also why .NET based Smart Clients are a good idea. It wasn’t too long ago (and yet not long enough in my mind) that you couldn’t predict which of the various browsers your clients, even corporate desktop clients, would be using. Netscape ruled the world and IE was coming up quick, but there were others. But since Microsoft started pushing out IE with every version of Windows this has become much less of a problem. The same thing will happen as the .NET Framework is included with every new version of Windows and on Windows Update. Windows Media Center, which is growing more popular every day, requires the .NET Framework. With more than 120,000,000 installations, it’s unlikely that you really need to worry too much about the fact that a Smart Client application requires the .NET Framework be installed.

  • Browser incompatibility. I’m not just talking about the differences between Internet Explorer and FireFox, which is a big enough problem. I’m talking about the differences between IE 6.0 and IE 7.0 or even IE 6.0 with HotFix A versus IE 6.0 with HotFix B to say nothing of Windows XP SP1 versus XP SP2. These can be hugely time consuming to track down and fix and require you to get deeply acquainted with the innerworkings of your client PCs. This is not easier deployment, you simply have shifted the issue from one of application deployment to that of browser deployment.
Advertisements

~ by UTS on May 16, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: