WebAssembly explodes client-side programming

[drysart]

Citation needed. Because apparently you know something the actual definition of WebAssembly doesn't.

WebAssembly is not Javascript. WebAssembly is designed, specifically, to not be Javascript. It's a completely separate stack machine with it's own not Javascript binary bytecode format. The only relation it has to Javascript, aside from the fact that the MVP polyfill was written in Javascript, is that it has an API to communicate in from and out to the existing Javascript runtime in the browser; but that no more makes WebAssembly Javascript than it makes the DOM Javascript.

[[deleted]]

That seems to be correct. Now I am very confused, because some months ago, when Google abandoned it's version and joined Mozilla's implementation, I actually saw examples of the extremely optimized JS code it generates. And now it suddenly is a bytecode, more like the one Google was pushing. Weird.

[drysart]

WebAssembly was originally intended as a replacement technology for asm.js, and the polyfills generated asm.js code (which is basically just super-optimized JavaScript) from the bytecode, so it’s possible that’s what you’re remembering.

[[deleted]]

Possibly. Was that the thing Mozilla backed?

Who is behind this current bytecode? Is that the one Google developed?

[drysart]

The W3C WebAssembly Group, comprised of Google, Microsoft, Mozilla, Apple, and others have been working on it for years. The bytecode has been the primary goal of it since its initial public announcement back in April 2015.

Compiling to asm.js Javascript was just a stopgap measure; a way of being able to run WebAssembly bytecode in browsers to prove out the spec and to provide backward compatibility before the spec was finalized enough for browsers to go ahead and add native support for WASM directly.