I think the emscripten and NaCl (core) teams should concentrate on the tool chain, not on UI tools or IDE integration, IDE support is only useful with full debugger support, and that's a massive amount of work, and I guess every new version of Visual Studio requires a lot more work.
I spent a bit of time to write a set of python cmake wrapper scripts which make cross-compiling to 'esoteric' targets easier (see here: http://floooh.github.io/fips/), it doesn't solve the problem to directly develop/debug for emscripten or NaCl in an IDE, but it lets you easily switch between cross-compile-target configurations, with the idea that you write and debug your code as native desktop application in VStudio, Xcode or QtCreator (or any other IDE supported by cmake), and then only cross-compile to emscripten, NaCl or Android NDK on the command line. In my experience, 99% of bugs happen in the platform-neutral high-level code, and are caught by debugging the native desktop version.
My comments aren't about GUIs. A command-line interface is still a user interface. It still needs to be designed for the user experience. I count developers as a type of user, and just as much care should to be put into the discoverability, accessibility, and usability in the software that developers must use as is put into the software that end users must use.
On the command line I don't see it as an issue. Both emscripten and NaCl provide standard gcc-style cross-compiling toolchains that are easy to integrate with other higher level build systems. That's IMHO the only way that makes sense when providing a C/C++ compiler toolchain. The big missing piece in the puzzle is interactive debugging, hopefully with WebAssembly we also get proper debug information format (something better then source-maps), and can then debug-step in the browser through the original source code (this sort-of already works with emscripten since it can generate source maps, but it is quite rough for big scripts, and mapping back variable names doesn't work very well).
I spent a bit of time to write a set of python cmake wrapper scripts which make cross-compiling to 'esoteric' targets easier (see here: http://floooh.github.io/fips/), it doesn't solve the problem to directly develop/debug for emscripten or NaCl in an IDE, but it lets you easily switch between cross-compile-target configurations, with the idea that you write and debug your code as native desktop application in VStudio, Xcode or QtCreator (or any other IDE supported by cmake), and then only cross-compile to emscripten, NaCl or Android NDK on the command line. In my experience, 99% of bugs happen in the platform-neutral high-level code, and are caught by debugging the native desktop version.