I'd love to write C++ in the browser, but only if they fix timers. The power of C++ and manual memory management is completely useless if some independent overburdened thread gets to decide when you are scheduled and for how long you run. If you have to just take 5ms breaks in your thread execution, you might as well just get a garbage collector that stops your world for a couple of milliseconds once in a while. Performance and any resemblance of real-time programming is lost anyway.
Could you tell me a bit more about why you want to write C++ in the browser? What things are you doing that are so CPU intensive that C++ is higher productivity then just JS?
Not the OP, but you're assuming that systems languages are lower productivity than JavaScript. I don't believe that Rust and Swift are necessarily lower productivity than JavaScript.
Nevertheless, here are a few of the main reasons you might want to work in a language that can easily target WASM:
1. Wholesale porting of desktop applications and game engines to the Web. This is the guise under which we developed asm.js, and it resonated well enough that Epic and Unity added support for asm.js to their engines.
2. Re-using existing, well-tested libraries that are written in C/C++. Why settle for zip.js if I can use libarchive directly? What about libraries that don't necessarily have high-quality JavaScript equivalents, like OpenCV, Box2D, or libsass?
3. Shipping high-performance codecs for multimedia formats like FLIF, BPG, and AV1 that aren't natively supported by browsers. Mozilla is actively using this strategy to develope the AV1 codec: https://hacks.mozilla.org/2017/02/webassembly-will-ease-coll...
4. Optimizing hot paths in JavaScript codebases, in the same way that Python or Ruby programmers will often re-implement individual functions or modules in C to overcome bottlenecks. For an example of this, consider the Flask microframework in Python, which depends on the Jinja2 templating library, which depends on Markupsafe for escaping HTML. Buried inside markupsafe is a 200 line file, "_speedups.c", that speeds things up. So even if end-developers aren't writing C/C++/Rust, they can still benefit from libraries that incorporate WASM.
5. Saving battery life. The fewer cycles it takes to finish a computation, the longer the CPU can spend sleeping. WASM provides significantly greater control over exactly what executes, and you can opt to burn CPU cycles on optimization once, during compilation, to get more a more efficient .wasm artifact for everyone. Since WASM is statically typed, the compiler also has many more optimizations available to it; no more worrying about monomorphism or type inference as with a JS VM's JIT compiler.
It's not about being CPU-intensive - it's about getting to write better, more maintainable code in a better language with better tooling than JavaScript. Let's keep in mind that all lipstick notwithstanding, JavaScript is still a pig, and it's use is not out of its desirability on its own merits, but a product of circumstance.
True real-time audio.
The WebAudio API just connects a pre-existing collection of basic nodes implemented by the browser in C or C++.
Being able to write sample-level processing targeted to WebASM would open up a lot of opportunities for different types of audio synthesis, effects, and analysis.
Not the same person, but for me, and a lot of the people I know it's a case of: "Anything but Javascript", rather than a specific language. Seeing as the web, and web "apps" are taking over, we don't all want to be pigeon-holed into writing JS/React/Angular/Node.
Video games. They require soft realtime constraints which current browsers are far from satisfying. Think networking, frame rendering, physics loop (even with deltas), etc. All of that is highly time-dependent.
