Yes, it sounds like they're attempting two goals; 1- to make the language of the web more language-agnostic (at least on the
front end; what's in front of the programmer that is...) and 2- as xtabber said, to push processing to the client rather than the server AND be more efficient when doing so.
When I first read the announcements on this, I was like "Didn't we already have this in CGI executables?" but, like Java and .NET for the web, CGI bins run in their own little world, separate from the HTML they reside in. Where JavaScript excels is in actually working with and manipulating the content. WebAssembly is like the best of both of those worlds, with a few perks.
Heres a good Ars Technica article on it that goes into a bit more depth:
The Web is getting its bytecode: WebAssemblyWebAssembly, or wasm for short, is intended to be a portable bytecode that will be efficient for browsers to download and load, providing a more efficient target for compilers than plain JavaScript or even asm.js. Like, for example, .NET bytecode, wasm instructions operate on native machine types such as 32-bit integers, enabling efficient compilation. It's also designed to be extensible, to make it easy to add, say, support for SIMD instruction sets like SSE and AVX.
I wonder though... how long before we see embedded viruses and malware written for WebAssembly?
5.. 4.. 3.. 2..