... especially since pthreads [1, 2] and SIMD [1, 2, 3] are coming to asm.js.
There are two main benefits WebAssembly provides:
-
The kind of binary format being considered for WebAssembly can be natively decoded much faster than JS can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40s 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 (1) AOT-compilability and (2) 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 JS engine (thereby reusing the JS 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 JS 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.
Yes, this is a high-level goal and there is a
prototype with demos
[1,
2]. Although the
binary format is not yet specified in any detail, the format used
by the prototype has promising initial experimental results. To allow direct comparison with asm.js,
the prototype has a tool to pack asm.js
into the prototype's binary format. Using this tool, we can see significant size savings before and
after gzip compression:
| Demo | asm.js | binary | gzip asm.js |
gzip binary |
|---|---|---|---|---|
| AngryBots | 19MiB | 6.3MiB | 4.1MiB | 3.0MiB |
| PlatformerGame | 49MiB | 18MiB | 11MiB | 7.3MiB |
By writing the decoder prototype in C++ and Emscripten-compiling to asm.js, the polyfill is able to perform the translation to asm.js faster than a native JS parser can parse the result (results measured in Firefox 41 on an Intel® Xeon® E5-2665 @ 2.40GHz):
| Demo | binary | time to decode into asm.js |
|---|---|---|
| AngryBots | 6.3MiB | 240ms |
| PlatformerGame | 18MiB | 550ms |
Since the polyfill algorithm (at least in the prototype) is simple and single-pass, memory usage is basically the size of the input plus the size of the decoded text.
Additionally, there are two further improvements that can be made in the real polyfill:
- Decode while downloading using either chunked files, HTTP
Rangerequests or (eventually) the Stream API. - Include optional better-than-
gzipcompression in the polyfill. For example, the lzham library shows an additional 24% improvement over the above "gzipbinary" figures while maintaining high decode rates.
Extrapolating from the prototype, these extensions would provide a roughly 45% over-the-wire size reduction (compared to current gzipped asm.js) without hurting load time (assuming moderate network speeds and more than one core). Developers may even want to switch to WebAssembly with the polyfill even before there is any native support.
As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++. However, by integrating with JS 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 JS.
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 (JS, 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 proposed for 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 platform.
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 JS) 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 (JS). While WebAssembly will, over time, allow many languages to be compiled to the Web, JS has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JS and WebAssembly will be used together in a number of configurations:
- Whole, compiled C++ apps that leverage JS to glue things together.
- HTML/CSS/JS UI around a main WebAssembly-controlled center canvas, allowing developers to leverage the power of web frameworks to build accessible, web-native-feeling experiences.
- Mostly HTML/CSS/JS app with a few high-performance WebAssembly modules (e.g., graphing, simulation, image/sound/video processing, visualization, animation, compression, etc., examples which we can already see in asm.js today) allowing developers to reuse popular WebAssembly libraries just like JS libraries today.
- When WebAssembly gains the ability to access garbage-collected objects, those objects will be shared with JS, and not live in a walled-off world of their own.
The LLVM compiler infrastructure has a lot to recommend it: it has an existing intermediate representation (LLVM IR) and binary encoding format (bitcode). It has code generation backends targeting many architectures is actively developed and maintained by a large community. In fact PNaCl already uses LLVM as a basis for its binary format. However the goals and requirements that LLVM was designed to meet are subtly mismatched with those of WebAssembly.
WebAssembly has several requirements and goals for its IR and binary encoding:
- Portability: The IR must be the same for every machine architecture.
- Stability: The IR and binary encoding must not change over time (or change only in ways that can be kept backward-compatible).
- Small encoding: The representation of a program should be as small as possible for transmission over the Internet.
- Fast decoding: The binary format should be fast to decompress and decode for fast startup of programs.
- Fast compiling: The IR should be fast to compile (and suitable for either AOT- or JIT-compilation) for fast startup of programs.
- Minimal nondeterminsim: The behavior of programs should be as predictable and deterministic as possible (and should be the same on every architecture, a stronger form of the portability requirement stated above).
LLVM IR is meant to make compiler optimizations easy to implement, and to represent the constructs and semantics required by C, C++, and other languages on a large variety of operating systems and architectures. This means that by default the IR is not portable (the same program has different representations for different architectures) or stable (it changes over time as optimization and language requirements change). It has representations for a huge variety of information that is useful for implementing mid-level compiler optimizations but is not useful for code generation (but which represents a large surface area for codegen implementers to deal with). It also has undefined behavior (largely similar to that of C and C++) which makes some classes of optimization feasible or more powerful, but which can lead to unpredictable behavior at runtime. LLVM's binary format (bitcode) was designed for temporary on-disk serialization of the IR for link-time optimization, and not for stability or compressibility (although it does have some features for both of those).
None of these problems are insurmountable. For example PNaCl defines a small portable subset of the IR with reduced undefined behavior, and a stable version of the bitcode encoding. It also employs several techniques to improve startup performance. However, each customization, workaround, and special solution means less benefit from the common infrastructure. We believe that by taking our experience with LLVM and designing an IR and binary encoding for our goals and requirements, we can do much better than adapting a system desgined for other purposes.
Note that this discussion applies to use of LLVM IR as a standardized format. LLVM's clang frontend and midlevel optimizers can still be used to generate WebAssembly code from C and C++, and will use LLVM IR in their implementation similarly to how PNaCl and Emscripten do today.