+1 on the interactivity aspect. Not having to go through a bunch of compiler configuration (C/C++ land) to get a basic GUI up and running is a huge plus. And HTML is a lot easier to understand for people with no experience than a bunch of tkInter classes.
i kindof believe all languages should have some ability to run with a browser-based GUI... why bother with all the hair-brained implementations (Swing, Qt, etc.) when we could just have a "desktop mode" (altered security) version of Chrome pop up to provide GUI. it wouldnt even have to follow same rules as browser really (navigation could be via buttons only, no back/refresh), just be based on html & perhaps js to allow a bit of advanced nav logic (though hopefully not enough to start polluting app logic)
i believe chrome apps may have some steps toward this, though not sure... at 1 point i considered trying to make a browser-based GUI that does all local RPC communication to a c++ app, but i feel like you know.... there should be a nice standard way of doing this out there
Chrome apps are already the desktop mode :) There's also stuff like Chromium Embedded Framework[1] which Atom used to use[2]. AppJS[3] sounds the most similar to what it sounds like you want, though. I've never tried it, but it seems like it'd work well enough (Chromium-based).
I think this is easier than you think. About 8 years ago I was working on a big project in Qt that was two parts -- one part a 3d rendering engine, one part an interactive web view. Having the two interoperate was surprisingly straightforward, and we could do all kinds of HTML/CSS layouts and use JavaScript hooks to call to the Qt classes. I can't imagine it's regressed much since then, though I'll admit it's been a while since I touched it.
PhoneGap provides this kind of experience for mobile.
The issue always ends up being performance -- running the JS runtimes in sandboxed webviews is always* slower than native code.
