I've just read Ted Neward's tips for HTML based apps. They are good ideas, and, if used, will result in a more pleasant end user experience. For instance:

What is it, exactly, that takes an otherwise well-built, well-behaved application and turns it into a snail? A large part of it is the HTML being returned. When an HTML page contains dozens of references to images, large and small, scattered all over the page, the page as a whole seems to drag to a crawl as the browser is forced to go back to the server over and over again to download those images. Yes, the images make the page look pretty, but does the website really need mouse-flyover image-switching graphics buttons for a main menu? Or a footer of ivy leaves twined around the copyright statement? Or the company logo in the upper-left corner of every page? I'll be the first to admit that these things make the page look pretty, but after they've been seen once, they just fade into the background in the user's mind. Worse, though, they still need to be displayed, which means that they still need to be downloaded each and every time. (A good browser will sometimes cache some of the images, but there are limits to what can be cached.) Even beyond that, consider the size of the images themselves--if they're any decent size and color depth at all, they can measure well into the hundreds of kilobytes in size, all of which has to move across the network from server to client.

He goes on with some recommendations, all of which are good - but they raise a simple question in my mind. 20 years ago, we started the migration from server (mainframe) based applications to client (PC) based applications due to - well, pretty much exactly these problems. In fact, a web application is a green screen terminal application with (slowly loading) graphics. So why exactly do we want to deliver applications that way?

In some contexts, it makes a lot of sense. Outside the walls of the business, web apps provide a way of getting feedback from, and getting information to, customers and prospects. We have no control over the platforms those people have, so we have to settle for an LCD solution - a web app. Let's look within the business though - once you get beyond the simple applications, what value is being provided by web apps to your corporate users? Sure, IS can update them easily. On the other hand, delivering patches and/or new versions over the intranet for a client application isn't hard either. You have all that desktop power in front of the users - why throw it away? What many IS groups seem to forget is that the time of their users is important. I've seen web "solutions" to reporting from sales staff that force field sales people to spend 3 and 4 times more time on reporting than they did prior to the roll out of the "productive" web application. There was a reason we abandoned terminal screens; IS organizations would do well to recall those lessons.