I've been working on hybrid web/desktop apps for a while now. I use Qt's webkit to make the application window a HTML page (QWebView) and load pages bundled with the app or from a remote server (or mix content from both). Whenever I need to reach out to the client platform--in my case, for bluetooth and for app.exit()--I use Qt's javascript/native bridge mechanism for great justice.

As with everything there are tradeoffs. Benefits include reusing libraries for both browser-based and native-based applications portably across client platforms. I have a large library of server code for the kinds of applications I write, so knocking up a new application in that domain is easy. I find writing clients in HTML/javascript easier for my iterative development style. Client libraries like jQuery help too, although I don't use them much as my apps run on an embedded device (333MHz) where they slow down page rendering too much. I use them for mocking up and prototyping and rewrite to inline javascript for deployment.

The biggest drawback is the native client, and I try to avoid having to use one as much as I can. And while Qt is good for Windows/Linux/Mac, you need something else for Android (I can't comment on iPhone/iPad because you can't program the bluetooth on them, so it is useless for my particular requirements). So you'll be maintaining separate clients which can be a bitch, but such is the nature of tradeoffs.

On the whole I much prefer this style of application, playing around mostly in HTML/javascript/perl, dropping into C++ when I need to touch the platform. Originally I thought using a browser might be too slow on my constrained device, but webkit is quite pleasingly snappy--faster than VB for an application one of my hybrid apps replaced.