in reply to web-based application or desktop application?
Like you, the first time I coded an app. to use a html interface rather than a gui interface, it felt like a retrograde step. So many of the things I was used to doing with a gui became horrible to achieve with html. I tried various routes -- dhtml, javascript etc., but even given that the site was a died-in-the-wool MS shop and the latest greatest version of Explorer was the only choice of browser I has to cater to, emulating the typical gui features was a nightmare. Menubars with drop-down menus, drag'n'drop, pop-ups etc. that are so typical of your average desktop app. are extremely difficult to implement and a nightmare to debug.
After several iterations and a lot of wasted effort, the realisation dawns. Almost all the problems come as a result of trying to emulate the desktop gui approach. If you can clear your mind of the need to approach the interface in this way, stand back from the problem and concentrate upon the usage patterns, then the problems and the solution to them become a lot easier.
That doesn't mean that all the problems go away. One particularly intractable problem is the need for dynamic updates of some part of the display. Only updating as a result of user interaction just isn't enough for some applications, but using a refresh timer to update the entire display every n seconds or minutes also isn't viable. If there are other parts of the same display that the user might need to scroll to read, the refresh will cause a loss of their position, and if they are entering information, the problem is even worse.
The best solution I found to this problem was to use iframe tags to create small areas to contain the dynamic content, and use the meta refresh tag to cause them to be updated. The server application then re-writes the dynamically refreshed url whenever required and it gets redisplayed within the refresh time period. If the browser being used has a sensibly configured and enabled caching policy, the body of the iframe will only be updated if the file on the server has been modify, further preventing unnecessary updates.
It is even possible to provide a crude kind of drag'n'drop, though it requires the use of a little javascript to make it effective, which maybe okay in an intranet environment. Basically, you provide readonly edit fields which automatically select and cut when activated and then when the user drops (pastes) the cut text into another edit field, it automatically submits. Like I said, crude, but possible if needed.
A couple of other advantages of using a browser is that it simplifies internationalisation of your apps, especially where different character sets are required. It also makes it easier to enable your application for color blind, partially sighted and/or blind users. The ease with which they can override such things as font sizes and colour choices and even use speech-readers if they have the appropriate setup is considerably easier than trying to enable all these features in all of your applications.
HTML interfaces will likely never be appropriate for all applications -- CAD/CAM, graphic editors and the like -- but for many more, the enforced divorce of interface from business logic, the inherently cient-server/centralised storage and (if used appropriately) the demarkation between content and presentation can become a compelling feature of writing applications this way.