[2015-07-02] New material in these sections:
[2015-06-24] I added an FAQ with three new questions:
Initially, WebAssembly is (roughly) a binary format for delivering asm.js code. The two main advantages of such a format are:
Faster loading. Especially with large code bases and mobile devices, parsing becomes a bottleneck: “On mobile, large compiled codes can easily take 20–40s just to parse” (WebAssembly FAQ). First experiments show that WebAssembly can be loaded more than 20 times faster, because the work for parsing is minimal.
There will be a text format for WebAssembly. It will mirror the semantics of the binaries and contain a tree of statements and expressions.
xto a 32 bit float.
Math.imul(x,y)multiplies the two integers
Performance critical functionality (games, video and image decoders, etc.) will be implemented via WebAssembly, either by hand-coding it or by yet-to-be-invented languages that are slightly higher-level.
External code bases, especially those in C/C++, will be easy to port to the web platform, via WebAssembly.
The initial focus is for WebAssembly to be a compilation target for C/C++. Longer term, more features supporting other languages will be added, including the ability to create garbage-collected data (currently, asm.js creates and manages its own heap).
Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed? There are three reasons:
First, this is a collaborative effort, no single company goes it alone. At the moment, the following projects are involved: Firefox, Chromium, Edge and WebKit.
WebAssembly is not bytecode: Bytecode is linear and (usually) stack-, register- or SSA-based, WebAssembly is a binary format for an abstract syntax tree (AST). Compared to bytecode, this has the following advantages:
On the other hand, WebAssembly is like bytecode in two ways:
WebAssembly eliminates the parser as a bottleneck.
Short answer: yes (load time) and no (execution time).
70% of the speed native C/C++ means that WebAssembly is fast where C/C++ is fast (static code) and slow where C/C++ is slow (e.g. dynamic OOP features).
The reduction of the size of executables will be less dramatic. One can already save a lot of space via minification and compression. First experiments (see below) resulted in gzipped asm.js being 1.4 times bigger than gzipped WebAssembly.
The main three options are:
For the Unity Game Engine, first tests were made with WebAssembly. Quoting “WebGL: WebAssembly and Feature Roadmap” by Jonas Echterhoff for the Unity Blog:
Especially informative is Eric Elliott’s interview with Brendan Eich: “Why we Need WebAssembly”.