On June 17, Google, Microsoft, Mozilla, and members of the WebKit project announced they will cooperate on a new binary format for web applications. It is called WebAssembly.
While these strategies are quite well done, there is a certain point where the effort to achieve even small gains is prohibitive.
There have been attempts in the past to allow a WWW site to deploy native (e.g. compiled) code to the browser. For example, Google’s Native Client. Lacking a universal standard, it was impossible to justify using the technology without asking users to use a specific browser.
WebAssembly is the result of these trends and driven by the need for advanced capabilities for applications running in browsers, browser-like environments, and likely server-side environments.
How it works
While C/C++ is the initial target language for WebAssembly, there is nothing that precludes implementation of virtually any language that compiles into the AST format.
One of the clever things about WebAssembly is that it allows for the late binding (or linking) of several WebAssembly modules once downloaded into the browser. This means there can (and will) be an ecosystem of modules that you can mash together to create applications. The late binding functionality allows a C++ module to link with and call functions in a different C module. Or a C++ module can provide a function that can be called from a Java module (assuming a Java to AST compiler).
Hackers will likely figure out how to turn the binary back into source code, but the code will be relatively safe from someone altering it or reusing it in some unauthorized manner.
While this seems like a good feature, it also means you will not easily be able to see what a 3rd party WebAssembly module is doing on your behalf once you call into it. My gut feeling is that 3rd party WebAssembly modules will come with source code that you should compile, or it will come from trusted 3rd party sources. Developers seem willing to trust CDN hosted libraries, even though they could potentially contain malicious code, but at least you can use source maps and see the code minified, unminified, etc.
It remains to be seen how secure the WebAssembly environment can be made. You’d think that modules compiled as AST binaries would be safer than a traditional binary made up of machine instructions, but it sure seems like hackers will be able to find exploits. That is, by creating the right AST binary, a hacker might be able to exercise a bug in the WebAssembly implementation.
WebAssembly is an exciting new technology that is going to improve developer and user experience, no doubt. It is likely to be adopted and well supported by the development community at large. It’s too soon to say when all the browsers will fully support it to the point we can freely deploy it and expect 100% of our users to be able to use it.