I developed many GUI applications for the Windows platform during my early professional career, and saw several GUI frameworks come, have whole magazines devoted to them, and then fade away. MFC is iconic.

Tasked with writing yet another GUI application, I starter researching cross-platform frameworks like Qt and WxWindows. I found the same steep learning curves I knew from before, and tooling doesn't help much in building a functional and elegant user interface because its clumsy and complicated.

But people are building beautiful and functional UIs on the Web all the time (look at this site!). The standards, the libraries, and the tools are certainly there.

My thought and my question: Why not write a GUI in which most of the UI is handled by an embedded browser? I already know that the Qt widgets support a large part of CSS and JavaScript, and programmers with good knowledge about web development are relatively easy to find, ..., so...

Have you done something like that before? What's your experience/advise?

A browser widget will likely support a subset of the functionality of mainstream browsers, but enough to produce a rich user interface using web technologies. There's the added advantage of the enormous simplifications possible when the web-stuff doesn't have to talk to a server to service UI requests.

My idea is not to embed a full-blown browser (yikes!). It is to enable the use of web technologies in GUI programming.


I haven't accepted an answer because the ones so far are suggestions about doing something else, and not about previous experience doing what I suggest. They're not even opinions or speculations about the pitfalls or benefits of doing it the suggested way, which is what I would expect in the unlikeliness that I'd be breaking new ground by using a browser widget to provide part of a GUIs interface. Think HTML, CSS, and limited JavaScript, with no Internet, no .Net or Java (or Air or Flex/Flash), no relational database; just executables, libraries, and templates that can be installed by copying them, and persistence to the user's home directory using the file system.

Some Addtional Related Questions

These are drawn from the answers so far:

  1. User experience: Isn't the WebApp that runs StackExchange rich and intuitive enough?
  2. User expectations: Hasn't the Web, and aren't portable gadgets (smartphones and tablets) moving the user experience away from the traditional GUI?
  3. Could it be that there apps that must be GUI but benefit from being webified while other's don't?
  • 3
    Isnt that basically what Adobe Air is? Commented Jan 5, 2011 at 6:24
  • I saw that suggestion (use the IE component for the UI of desktop applications) in the MSDN magazine, ~12 years ago.
    – user281377
    Commented Jan 5, 2011 at 14:38
  • Adobe Air is a complete, embeddable programming framework. You embed Air in your web pages. I'm asking about something much simpler: use a GUI framework widget to display and interact with content created with Web technologies.
    – Apalala
    Commented Jan 5, 2011 at 16:39
  • 3
    @Apalala: from Adobe: "The Adobe® AIR® 2.5 runtime enables developers to [...] build web applications that run as standalone client applications without the constraints of a browser." adobe.com/products/air
    – Jeremy
    Commented Jan 5, 2011 at 17:40
  • 1
    @Apalala I have read Joel's article before...my point is that you seem to be trying to find the holy grail which will allow your application to live indefinitely; you won't. While Joel's article is spot on he does make note where this is applicable..."large scale commercial applications". If you expect the presentation layer of your web application to live 3+ years using todays technologies then more power to you. Commented Jan 5, 2011 at 21:32

5 Answers 5


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.

  • @Guizca Thanks for sharing your experience. I'll follow up with some more questions in an edit of the question.
    – Apalala
    Commented Jan 5, 2011 at 23:51
  • @Apalala: Just saw your edits. It's possible. But most of the work I've been involved so far has been in fairly strict web versus GUI scenarios (Think Gmail users versus Outlook users). So my experience isn't strong enough to do anything more than speculate on these possibilities of future crossover. Commented Jan 6, 2011 at 0:09

This was exactly my approach for turning the Perforce P4V Qt/C++ client into a platform for user-written extensions using HTML5, now called the Perforce JavaScript API for Visual Tools. The idea dates back to 2007 and the first prototype was running in early 2008. It's particularly powerful to combine Qt and HTML5 (if you are already deploying a binary application).

Out of this project came several major initiatives for our company, including the Perforce Ecosystem, now headed by Jeff Bates, Slashdot founder.

Here is my blog article on the history and genesis of this project: http://blog.perforce.com/blog/?p=2805

Since then, we plan to bring this HTML5 capability to our P4Eclipse, Web Services and other clients. There have also been plans to create a remotely configurable client using HTML5 as the rendering environment.

So I'd say this has been a very successful project- not only for changing our view of a one-size-fits-all client program, but for bringing the idea of a community ecosystem for innovation into our strategic initiatives.

Going forward, web applications are closing the gap and may overtake what you would get from a hybrid Qt/C++/HTML5 like Perforce's P4V and P4Admin. Of course, all the solutions you have coded on your hybrid model in web technologies are easily ported to a Web Services or web application deployment.

  • Interesting. It turns out one can find plenty of experiences posted on the Web if you look for the right keywords: "hybrid application". Some of the latest news say that MS will ditch .Net for Windows 9 and adopt a hybrid approach based on HTML5, CSS, and JavaScript.
    – Apalala
    Commented Jun 24, 2011 at 13:08

We're mixing html interfaces and WPF interfaces quite a lot right now. There are some things to consider.

Like if you want to host your website in an embeded browser you might still have issues with different browsers on different systems. Chromeium on Linux machines and IE on .Net applications for example.

You could control this by embedding the browser you want to use in the application. This has been done for .Net with chromium: http://www.khrona.com/products/awesomium/

This is also a moving edge on the mobile device developer community. PhoneGap has a system where you create webpages that then are compiled into an embeded browser with hooks into the OS for more advanced features. I can imagine that you could get more experience reports from developers who have tried that out.

  • My idea was to use the framework-provided browser widget as the standard. Its capabilities will likely be in the intersection of mainstream browsers. Because that would be the only browser in use, there would be no cross-browser incompatibilities.
    – Apalala
    Commented Jan 5, 2011 at 15:28
  • 1
    If you expect the browser to remain the same for the coming 10 years then I say go for it. Even with IE things change during upgrades, since the sandboxed webbrowser in .Net is infact IE. The upgrade to IE 8 caused some serius issues for us. But that depends on how often the application will update. An upside with a HTML GUI is that its quite simple to upgrade if you keep the HTML files hosted on disc beside the actual webserver. Isolation between the GUI and the application logic is quite well expressed in whats available in your local webserver and what the gui shows.
    – Morten
    Commented Jan 5, 2011 at 21:33

I have once been involved in creating such application. It was written in Qt and C++, but most of the windows were just containing a single QWebView which was then fed custom HTML. Some random notes:

  • It was somehow easier to develop than traditional web app, since you had to target only one HTML engine (one of most powerful, BTW).
  • It was somehow harder to develop than traditional web app, because manipulating HTML in C++ is unconvinient to say the least.
  • HTML lacks lots of GUI-related functionality, that is provided out-of-the box by traditional GUI toolkit. For example - I had to recreate tree view control in JavaScript, with lots of special cases as keyboard navigation, mouse selection. Such control is standard part of virtually every GUI framework.
  • Interacting with widgets is cumbersome. To get text of a Qt text entry, all you have to do is to call QString value = entry->text(). To get text of HTML entry inside QWebView we had to emit custom JavaSctipt that retrieves entry value, then unpack data from QVariant returned as result. Or something like that.
  • It was hard to keep Qt and HTML parts of application looking consistent. We ended with three[!] separate theming engines.
  • Performance was suboptimal and that application was a resource hog. It's hard to tell whether it was HTML to blame, though.

I have seen some applications which have large parts written in web technologies but IMO that defeats a lot of the purpose of a desktop application in the ability to have a richer UI, although that distinction is disappearing with Silverlight and Flash etc. If you want to use web technology build a web app.

  • I think it's different when there's no web server, and the whole thing runs from a single executable and the file system. It allows for zero-installation programs (run from a pen drive), which is something you can't have with the usual WebApp. Also, one of my points was that nowadays you see WebApps that are richer and more usable than the typical GUI (in which just having a button backed by images is a lot of work).
    – Apalala
    Commented Jan 5, 2011 at 6:48
  • Also you can create webpages locally to display offline data. It's all about finding an interface thats easy to port between environments yet can control local resources the way a browser cant.
    – Morten
    Commented Jan 5, 2011 at 8:03
  • @Morten You make an interesting point: a GUI that uses a browser widget is not subject to the sandboxing that applies to web browsers.
    – Apalala
    Commented Jan 5, 2011 at 17:00
  • Which platform are you writing for? .Net, Android, Java?
    – Morten
    Commented Jan 5, 2011 at 21:35
  • @Morten The platform will likely be Python+PyQt, and something different from Qt when required.
    – Apalala
    Commented Jan 7, 2011 at 1:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.