I've overheard conversations at MIX06, as well as at other gatherings such as the PDC. I've also helped answer questions on several difrerent mailing lists.

A common theme I've heard is that IT folks are trying to work around browser limitations in order to deliver rich applications on their internet internet.

These days, developer productivity is key to the success of any IT organization. Microsoft and other companies have made it a primary goal to help people develop applications faster, and deliver the best possible user experience.

Why is it then, that IT staff are willing and happy to work around back buttons, write hundreds of lines of undebuggable JavaScript, work around session timeouts, work around significant UI limitations, deal with performance issues and otherwise bend over backwards to deliver browser-based applications for use in internal intranets?

It has been proven time and again that given equivalent UI functionality, it takes longer to develop a web application than a rich client application. That time could be spent providing more features, providing a better user experience, or just getting the application out faster.

If you have control over the desktop, you should be developing rich/smart client applications. Full stop.

Is it the sex appeal of web apps? Sure, they can look a little snazzier than windows apps, and are easier to brand, but is that worth all the other issues? Nevertheless, we've put together rich client apps that have good branding and look like web applications while behaving like a rich client should. Luckily, WPF eliminates this difference.

Is it the deployment? Please tell me that we're not letting deployment stand in the way of good application development. With ClickOnce in .NET 2.0, and with the existing deployment mechanisms most companies have (how do you think service packs and similar get to the desktop), this is really a red herring. Folks who think deployment is the main concern are likely still thinking about how they were bitten in the VB6/ActiveX/COM days. If you're one of those folks, please step back and reevaluate your position on this.

Is it the idea that the application can be reused on the internet and exposed to your customers? Yes, I've heard this one, and I think this is a very misguided approach. It is extremely rare for a customer to have the same UI requirements as an internal user. Internal users typically want to move through things quickly, and have access to potentially sensitive data, whereas external users typically need more hand holding and data verification. Instead of reusing the UI layer, ensure you follow a good architecture (SOA or other) where you are able to reuse your application logic and provide both an internal rich client UI and an external web UI. We recently did this at a client and it has worked well.

Is it the idea that the application can survive desktop upgrades and not get stomped on by other software? This is a myth. Intranet browser applications are typically tied to a single version of a single brand of browser. This happens because compromises need to be made to provide a user experience that begins to approach even half of what a rich client can do. So now, when you need to upgrade the browser, you suddenly have hundreds of intranet applications that need to be fixed. With Windows Forms or WPF applications, you don't have to worry about getting stepped on. They just work.

Is it because management is still in the dark ages of the internet boom? If so, it is the responsibility of IT staff and consultants to help get them out of this. Web applications belong on the web, not inside the organization.

Is it the idea that you may jump to another OS platform in the future? This may provide some measure of comfort, but (1) it almost never happens (too many other apps like Office rely on the operating system you have) and (2) see the issue with browser incompatibilities above. It simply isn't worth sabotaging your internal development for this "maybe some day" approach.

I've seen RFPs, client vision and scope documents, and other artifacts that start off with "We want a web app which will..." and then later include all sorts of things which could be done quite easily with a rich client, but will take man days/weeks of effort in a browser app.

I'm interested in your thoughts on this matter. I think as IT professionals it is our responsibility to inform clients and management as to where the industry is going, and how to get the most bang for the buck out of their development efforts.

It is also important for us to help educate clients and management on the options available. Web app does not have to mean browser app. It can mean a web-service-enabled, browser-delivered, auto-updating, WPF application. Not only will you able to get a better user experience from that, but you will get it done faster, better and smarter.