writes: The vendors of WebKit, Chromium, Edge, and Firefox announced their united effort to create a binary execution format for the world wide web. Like the previous projects pnacl and asm.js, WebAssembly features near-native performance, but without the vague specification pnacl had, or the space-consuming asm.js format, which had a 20x parsing overhead compared to a bytecode format (now arrays can be used instead of lookup maps, and no heavy decompression step).
Besides wider adoption as its plugin-less, and an open specification, the main advantage of this project over plugin based solutions like java applets has been characterized by Mozilla's Luke Wagner as:
[T]he API surface area is that of the Web platform (e.g., WebGL for graphics) and thus WebAssembly use cases will contribute to driving forward the whole Web platform.
It’s crucial that wasm and asm[.js] stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support.
He further writes:
Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format. [...] wasm should relieve JS from having to serve two masters [FAQ entry here].
Most likely due to Mozilla's envolvement, WebAssembly even tries to address the "binary" barrier built up when dealing with WebAssembly on a client.