FAQ - WebAssembly

… especially since pthreads (Mozilla pthreads, Chromium pthreads) and SIMD (simd.js, Chromium SIMD, simd.js in asm.js) are coming to JavaScript.
There are two main benefits WebAssembly provides:
The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience.
By avoiding the simultaneous asm.js constraints of AOT-compilability and good performance even on engines without specific asm.js optimizations, a new standard makes it much easier to add the features required to reach native levels of performance.
Of course, every new standard introduces new costs (maintenance, attack surface, code size) that must be offset by the benefits. WebAssembly minimizes costs by having a design that allows (though not requires) a browser to implement WebAssembly inside its existing JavaScript engine (thereby reusing the JavaScript engine’s existing compiler backend, ES6 module loading frontend, security sandboxing mechanisms and other supporting VM components). Thus, in cost, WebAssembly should be comparable to a big new JavaScript feature, not a fundamental extension to the browser model.
Comparing the two, even for engines which already optimize asm.js, the benefits outweigh the costs.
WebAssembly was designed with a variety of use cases in mind.
We think so. There was an early prototype with demos [1, 2], which showed that decoding a binary WebAssembly-like format into asm.js can be efficient. And as the WebAssembly design has changed there have been more experiments with polyfilling.
Overall, optimism has been increasing for quick adoption of WebAssembly in browsers, which is great, but it has decreased the motivation to work on a polyfill.
It is also the case that polyfilling WebAssembly to asm.js is less urgent because of the existence of alternatives, for example, a reverse polyfill - compiling asm.js to WebAssembly - exists, and it allows shipping a single build that can run as either asm.js or WebAssembly. It is also possible to build a project into two parallel asm.js and WebAssembly builds by just flipping a switch in emscripten, which avoids polyfill time on the client entirely. A third option, for non-performant code, is to use a compiled WebAssembly interpreter such as binaryen.js.
However, a WebAssembly polyfill is still an interesting idea and should in principle be possible.
As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++.
However, by integrating with JavaScript at the ES6 Module interface, web developers don’t need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JavaScript.
Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects . Even before GC support is added to WebAssembly, it is possible to compile a language’s VM to WebAssembly (assuming it’s written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, “compile the VM” strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.
WebAssembly initially focuses on C/C++, and a new, clean WebAssembly backend is being developed in upstream clang/LLVM, which can then be used by LLVM-based projects like Emscripten and PNaCl.
As WebAssembly evolves it will support more languages than C/C++, and we hope that other compilers will support it as well, even for the C/C++ language, for example GCC. The WebAssembly working group found it easier to start with LLVM support because they had more experience with that toolchain from their Emscripten and PNaCl work.
We hope that proprietary compilers also gain WebAssembly support, but we’ll let vendors speak about their own platforms.
The WebAssembly Community Group would be delighted to collaborate with more compiler vendors, take their input into consideration in WebAssembly itself, and work with them on ABI matters.
Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.
Existing Emscripten users will get the option to build their projects to WebAssembly, by flipping a flag. Initially, Emscripten’s asm.js output would be converted to WebAssembly, but eventually Emscripten would use WebAssembly throughout the pipeline. This painless transition is enabled by the high-level goal that WebAssembly integrate well with the Web platform (including allowing synchronous calls into and out of JavaScript) which makes WebAssembly compatible with Emscripten’s current asm.js compilation model.
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of th