For years, I've laughed (from skull throne) at the "whyyyy no bytecode" posts on HN. Now bytecode, still complaints. Still laughing, too.
Don't you think developer tools should have good UX, too? Microsoft does, and Visual Studio just works. Oracle does, and Java and Netbeans just work. Even setting up Node and NPM was a better overall experience than trying to get Emscripten working correctly and integrated into my projects.
Emscripten and NaCL are both like 4 years old now. Why hasn't there been greater adoption of these tools? I postulate it's the bad UX. I mean, Emscripten only working with VS2010, three whole versions behind latest, is a pretty good indicator that there is a whole class of users that have just written it off. Is there any concern for that with WebAssembly?
Things took a while because vendors had their own prior paths to pursue, while asm.js had to prove it could get close enough to native perf. (You could say Mozilla's prior path was JS.)
Tools for JS are pretty good; VS does TypeScript and JS, will do wasm. Firefox devtools are giving Chrome devtools a run for their (bigger) money.
I think tools are the least of it, while agreeing they make a difference (see Mandreel with VS integration, vs. Emscripten).
NaCl (PNaCl, you must mean) never went cross browser as such, nor could it. WebAssembly is the PNaCl end-game, and a pretty good one.
As for Emscripten, it's a huge win that both Unity and Epic (Unreal Engine) support JS/WebGL as first-class targets. This happened over the last few years, tools built into the game engines. Doesn't disprove your point, you could be right! Let's find out.
For myself, I've had very little to complain about web development since '08 or '09. It became an application platform for me with the emergence of the canvas tag, and since then it has grown into a full operating environment of sorts. There have always been awkward and limiting features to the web because it is such a hodgepodge and I think that's where most of the complaints come from. But the browser compatibility situation continues to improve, which has always been my biggest gripe.
I worry a bit about the exploit potential of WebAssembly as more features are layered atop what Asm.js offers. Don't add too much, okay? ;)
I see any web-scale runtime standard inevitably having versions spread across the installed base of any server, so prone to the same pressure JS was, which led to polyfills, graceful degradation, object detection, monkey-patching in full. People who complain about this are complaining about physics.
You're right to worry about security, which is why the "MVP" for wasm is co-expressive with asm.js, just faster-to-parse syntax. After that, we must be even more careful.
And great work, this is very exciting news.
Not really. NaCL was limited to a single browser, and asm.js was a stepping stone towards a bytecode for the web. WebAssembly has support from the major browser makers, plus a (mostly) clean slate for developing a bytecode suitable for the web. This is a golden opportunity for the web to evolve into a high performance application platform.
As for tooling, C# and Java are anomalies, no other languages come close. What sets those two languages apart? They're very popular in the commercial world, and they're based on virtual machines (C++ and JS may have decent tools, but I'd rather debug C# than, and part of that is the ability of the compiler to understand the program structure). A universally supported bytecode for the web is very likely to decent tooling.
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.
Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?
Or maybe I'm missing the whole point of this? :)
I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!
If you want that from your JS codebase, I'm sure it would happily compile to Wasm - you'd probably find that a JS-to-Wasm compiler would be one of the first proofs-of-concept for Wasm.
In contrast, wasm is for C and C++ first, and in due course many languages. The C/C++-first design point is a way of limiting scope creep and catering to important native-code use-cases (games, AI, CV, etc.). It's the starting point, not the final state. But it involves the usual static types trade-off that reduces runtime overhead.
Therefore a full JS engine in wasm would not run very fast compared to today's in-browser JS VMs, which are evolving to be JS/wasm VMs. For dynamic languages to compile to efficient wasm, we'll need the future JIT-generated wasm support and other desiderata on the roadmap. These come after the "MVP" that is co-expressive with asm.js.
So the proof of concept for wasm must start with asm.js and grow to PNaCl in full (which has had APIs and optimizations that asm.js or JS and the Web APIs have not provided yet), and then on to dynamic language runtime support. HTH.
Another dynamic language support part of wasm's roadmap that's post-MVP: GC support, both for GC of allocations from wasm code, and for references from wasm memory into the JS (DOM whatever) object space. One GC to rule them all, and one VM too.