I was actually once involved in working on a web app, which we eventually almost ended up marketing as a standard "desktop application". For some reason, Marketing got it into their heads that one of our major clients wanted the product to "appear to be a GUI application", so we created a little Windows app that just hosts the IE ActiveX control, and points to our web app (hiding the fact that it's actually a browser). So effectively, to an untrained eye it looked like the product was a standard GUI app.
Granted, this isn't exactly what you're asking (we were still pointing at a web app, and not hosting the whole thing locally) - but it's close enough. It would have been trivial - minus some of the remote web services it used - to set this up to just have the whole thing sitting on the local machine.
Here was the biggest problem though: look and feel. Especially feel.
People expect certain behaviours from rich GUI apps (drag and drop, native-feeling windows and dialogs, etc). It is extremely hard to get a genuinely native look and feel from a web frontend. There is simply a different user flow in what is expected when you open up a web app in a browser (eg. Gmail), as opposed to when you use a rich GUI application (eg. Outlook). In my experience, trying to equate the two is asking for trouble. If you put out a "GUI app" which acts like a web app, you're likely to be flooded with usability and LAF complaints.
TL;DR - Web apps and GUI apps have different looks and feels, and a different user culture to some extent. While it's technically possible to do something like this, from my experience, I wouldn't go there (again). At best you're likely to end up with a horrendous mix of client-side scripting that will be more difficult to learn, use and maintain than doing the whole thing as a normal GUI app in the first place. And people WILL complain about things "not quite feeling right" for a native GUI app. It's tempting to think that they won't - but they will.
Server-side HTML rendering:
- Fastest browser rendering
- Page caching is possible as a quick-and-dirty performance boost
- For "standard" apps, many UI features are pre-built
- Sometimes considered more stable because components are usually subject to compile-time validation
- Leans on backend expertise
- Sometimes faster to develop*
*When UI requirements fit the framework well.
Client-side HTML rendering:
- Lower bandwidth usage
- Slower initial page render. May not even be noticeable in modern desktop browsers. If you need to support IE6-7, or many mobile browsers (mobile webkit is not bad) you may encounter bottlenecks.
- Building API-first means the client can just as easily be an proprietary app, thin client, another web service, etc.
- Leans on JS expertise
- Sometimes faster to develop**
**When the UI is largely custom, with more interesting interactions. Also, I find coding in the browser with interpreted code noticeably speedier than waiting for compiles and server restarts.
You might also consider a hybrid model with a light backend implementation using a front-end/back-end templating system like mustache.
Best Answer
The most important factor, to my knowledge, is deployment.
With desktop applications, you have to:
Web applications also have a few advantages by nature for which desktop applications have to jump through quite some hoops:
In terms of development effort, I'd say writing web applications requires a slightly different mindset, but it isn't intrinsically easier or harder than desktop programming, given decent enough tools.