Not to mention, JavaScript engines were essentially extended into supporting WebAssembly much like they were extended to optimize Asm.js. Browsers generally don't have entirely separate WebAssembly engines, parts of their existing JS engine are shared for WebAssembly. I think that makes the case pretty well!
That doesn't really make the case—JIT compiler backends are all pretty similar, so of course the browsers are going to reuse parts of their JavaScript JIT for WASM, but that doesn't make WASM "JavaScript, but fast". The only resemblance WASM has to JavaScript is it lives in the browser.
To be fair, as far as I can tell you are the first person to use the phrase "JavaScript, but fast" in this thread. Wasm's design isn't based on JS, obviously. It is, however, strongly inspired by ideas like asm.js and the existence of C -> JS compilers (among other things.) You can find more evidence of this than just HN commenters. Here's Google:
Heck, the same toolchain (Emscripten) that targeted asm.js became one of the defacto Wasm toolchains. They're not the same thing, but the path from which things evolved is not really open for much debate.
> Now the industry says: "Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make it fast by creating an IL runtime!!!"
If they'd said that we have a universal platform in the browser, make it fast, that would be different. It's the idea that the JavaScript runtime is going to be made faster by WASM that I'm objecting to.
>>"Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make _it_ fast by creating an IL runtime!!!"
Ok, I see the misunderstanding. The "_it_" I'm referring to is the "desire to run serious apps in that runtime". I wasn't claiming that WASM makes Javascript syntax faster.
jchw intepreted my meaning as I intended: From my PoV, they designed an IL runtime based on how some people were using JavaScript, aka inspired by Asm.js, not an IL runtime for or based on JavaScript.
My point is that history has now shown us that it's easier for Google to extend V8 engine to also run WASM, and for Mozilla to extend SpiderMonkey to also run WASM... rather than for Sun JVM applets to spread into all browsers as a universal runtime -- or for a JVM-bytecode-compatible engine to be embedded inside Chrome/Firefox.
Even though Javascript itself was not purposefully designed to be a universal compilation target for C/C++, it nevertheless opened a door to a universal bytecode runtime that the JVM/CLR did not.
Interesting. I think we are interpreting that statement quite differently.
From my PoV, they designed an IL runtime based on how some people were using JavaScript, aka inspired by Asm.js, not an IL runtime for or based on JavaScript.
I did not read that statement as saying Wasm was or was intending to be faster JS, at least not generally. Of course you are correct in that Wasm has absolutely nothing to do with JS on a lower level.
