I've been doing quite a bit of research into this very topic. I posted a presentation I did on it at the Java Lobby knowledge base (
http://www.javalobby.org/kb/entry.jspa?entryID=183&categoryID=5).
I think there is a place for both HTML and rich client applications. Here is why:
1) HTML is easier to hand code and to have frameworks generate
2) HTML is easier to make look good
3) HTML is easier to deploy out to just about anybody
4) HTML is about as accepted a standard as you can get
The big problems with HTML business applications are:
1) It's really hard to get a truly intuitive and interactive user interface, without turning JavaScript inside out and upside down, debugging on every browser, etc...
2) The GUI state information really needs to live on the client, but instead most of it winds up on the server, which gives you a bunch of unpleasant choices. Use a lot of server memory, use a lot of bandwidth piping the state back and forth, or weaken your GUI so there isn't much state to keep. Meanwhile, the average client PC has megs of unused memory.
3) You can't do partial page refreshes very well so you always get clicks and blinks when ever the user does anything interactive outside JavaScript. The server has to generate and send a whole new page even for a simple GUI state change. So you get a clunky GUI, and the server is doing a ton of work while there are lots of unused CPU cycles on the client.
4) The browser back button is just a misery for business applications, but users expect it and want it.
5) Printing formatted reports in HTML is a misery as well.
If you really look at it, most of a typical browser application doesn't need to be that interactive and isn't worth all the extra work for programmers to make is so. For those pages generated HTML is fine. But some sections of every business application will benefit greatly from a rich client. For things that end users spend a lot of time in, like high volume data entry screens, or high volume reposts you can save them a lot of clicks, the server a lot of load and the network a lot of bandwidth with a rich client. So I think a typical business application will in the future consist of around 70% generated HTML and 30% rich client.
The question is what technology will be used for the rich client. That's very murky right now. I looked at a bunch of technologies and some are very promising, but none are there yet. (Sorry Amy Fowler, but applets and webstart are still far from an ideal deployment platform, although making Swing easier to work with using a tag language is a great idea).
I'm really interested in XForms which is supposed to be the latest W3C extension to HTML. The thing about XForms is that it is basically an HTML/XHTML page, with charged up form processing. It has an independent XML model on the client and it supports partial page submits. You can just submit and get back just the model and not the whole page, and the view automatically rebuilds from the new model. So you get some state on the client, no clicking and blinking on submits and fewer bandwidth problems. Also XForms are an extension to HTML and so one document can have both. The problem with XForms is that it is very bleeding edge and browser support is terrible at the moment. If good implementations where available on IE and Mozilla (or looked like they were coming) I would seriously think of rewriting my
open source framework around this technology. Unfortunately I don't expect any really good XForms browser implementations any time soon, but there are quite a lot of bad ones out there. Maybe somebody will get it right eventually.
Of the other technologies out there, Macromedia Flex seems most promising because it's the only one that at this moment can run on most browsers out there. The problem with that is that it's proprietary and expensive. And I really don't know if I want to be subject to the whim of Macromedia. I suggested to a customer they try it and they told me if they wanted something proprietary they would be using Microsoft. If only Flex were open source