Friday, November 10, 2006

The Great Pumpkin Question...

Normally, I don't do requests. But Brian <Anzalone> recently suggested I do a post where I discuss the age old question; Street Fighter II vs. Mortal Kombat. But I thought that was a stupid idea, so instead I'm gonna talk about Windows applications vs. Web-based applications.

Definition of Terms
For those non-techies who are still reading, like my parents, Windows applications are applications that you install locally on your computer (your hard drive) and you can run without being connected to the Internet. These are applications like Microsoft Word and Microsoft Excel.

Web-based applications are applications that you used through a web browser. The most popular web application is Google, but others include Mapquest and things like on-line banking websites and bill-pay sites like Check Free.

Which One to Use In One Easy Step
A lot of people who don't develop applications on both sides of the argument think that there is only one answer to the question "Should I make this a Windows application, or a web-based application?" and they are right. But it's not the answer they think. The correct answer is "it depends."

Tale Of the Tape
Windows applications have some definite benefits of Web based applications. From a developer’s side, it can be easier to control the way a user interacts with the user interface in a Windows application. For Web Applications, you're sort of at the mercy of the interaction the user has with the browser. Things like the "Back" button, navigating directly to an address inside the application or simply shutting down the browser in the middle of an operation are all things that the developer and architect have to work around in the "Web World."

Since Windows application run entirely on the desktop and don't generally have to make a bunch of calls, or post backs, to the server, there is the (perception) of speed as well. Technologies like AJAX and ASP.NET AJAX (formerly Atlas) have all but eliminated this advantage however.

Traditionally, user interface design on Windows applications has always been easier; you just put a component on a Winform, set some properties and you're done! Web Applications have been a little more complicated than that; back in the "old days" you used to have to create tables and use those to format you user interface. The other issue had been that not all browsers rendered all controls the same way. Heck, some browsers didn't support certain controls at all! With the growing adoption of Web Standards and the growing use of CSS style sheets to take care of all formatting (leaving HTML to be the keeper of the content) this is another factor that is starting to swing towards Web Applications favor.

To change the whole look of a Web Application you simply change the style sheet. No so with Windows Applications; if you were smart you may have a user interface hierarchy, allowing you to make changes to a few base forms which will propagate through your application. If not, you were visiting EVERY window in your application and changing every control on that window.

“Client side” scripting and validation is one area where Windows applications may still have an upper hand. Javascript has come a long way, but it is still ugly and not a lot of fun to debug. ASP.NET AJAX shows some promise in alleviating this, but it still in it’s infancy in that regard. Windows applications don’t have this issue, your presentation layer is easily accessible, easily automated and easy to debug.
Deployment is a mixed bag. Web applications are easy to deploy. You just put the application on the web server of your choice, send your users a link (or if you’re really snazzy and on top of the whole “Enterprise Computing” thing, you’ll have a portal for the users with a link to your new application) No going to each users machine, installing local components, making sure they have all the prerequisites, installing the application and setting up the database configuration. Now multiply that times about 250. So, in a corporate environment, with a centralized server, Web is clearly the answer for deployment purposes.

For all of Windows deployment headaches though, it’s still easier to write an install package for a home user buying a shrink-wrapped product than have them set up a Web-based application on their computer. Most home users aren’t going to be savvy enough to know if they have IIS or Apache installed, let alone how to configure it.

What to Do, What to Do...
When I am working on an application and I have to make the decision about Windows vs. Web, I ask myself some questions:


  • Is this application going to be deployed in a corporate environment, or shrink-wrapped?
  • Where is my data going to live?
  • How often will the application need to be upgraded?
  • Who is going to support this application?
  • Does this application need to be Section 508 compliant (if you get ANY money from the Federal government, the answer is “yes.”)
  • What kind of machine is it going to be deployed to?
  • What kind of infrastructure am I going to be working with?
  • What kind of security issues am I going to have to deal with?
  • Is the user going to allow cookies and have Javascript turned on?
  • Who is the applications audience?
  • Is the “content” of the application going to be static?
  • What does the client want? (Remembering that the client is NOT always right, but they are always the client)

The way these questions get answered will generally lead you down the correct path. Yeah, some questions are more important than others, but it’s good to have as complete a picture of what’s going on as possible.

Regardless of which avenue you choose, good architecture is important. A lot of bad Web applications have been built by people who thought you could design them to be just like Windows applications. It’s apples and oranges, and each has unique challenges.

2 comments:

Anonymous said...

Well said. I think you could beef this post up by mentioning smart clients, click once type deployments, and a few other things.

James Bender said...

I had a bit about those initially, but I was worried that this was getting a little too long, so I decided to save that for a "part 2."