

Google, Microsoft, Mozilla and the engineers on the WebKit project today announced that they have teamed up to launch WebAssembly, a new binary format for compiling applications for the web.

The web thrives on standards and, for better or worse, JavaScript is its programming language. Over the years, however, we’ve seen more and more efforts that allow developers to work around some of the limitations of JavaScript by building compilers that transpile code in other languages to JavaScript. Some of these projects focus on adding new features to the language (like Microsoft’s TypeScript) or speeding up JavaScript (like Mozilla’s asm.js project). Now, many of these projects are starting to come together in the form of WebAssmbly.

The new format is meant to allow programmers to compile their code for the browser (currently the focus is on C/C++, with other languages to follow), where it is then executed inside the JavaScript engine. Instead of having to parse the full code, though, which can often take quite a while (especially on mobile), WebAssembly can be decoded significantly faster

The idea is that WebAssembly will provide developers with a single compilation target for the web that will, eventually, become a web standard that’s implemented in all browsers.

By default, JavaScript files are simple text files that are downloaded from the server and then parsed and compiled by the JavaScript engine in the browser. The WebAssembly team decided to go with a binary format because that code can be compressed even more than the standard JavaScript text files and because it’s much faster for the engine to decode the binary format (up to 23x faster in the current prototype) than parsing asm.js code, for example.

Mozilla’s asm.js has long aimed to bring near-native speeds to the web. Google’s  target="_blank" href="">Native Client project for running native code in the browser had similar aims, but got relatively little traction. It looks like WebAssemly may be able to bring the best of these projects to the browser now.

As a first step, the WebAssembly team aims to offer about the same functionality as asm.js (and developers will be able to use the same Emscripten tool for WebAssembly as they use for compiling asm.js code today).

In this early stage, the team also plans to launch a so-called polyfill library that will translate WebAssembly code into JavaScript so that it can run in any browser — even those without native WebAssembly support (that’s obviously a bit absurd, but that last step won’t be needed once browsers can run this code natively). Over time then, the teams will build more tools (compilers, debuggers, etc.) and add support for more languages (Rust, Go and C#, for example).

As JavaScript inventor (and short-term Mozilla CEO) Brendan Eich points out today, once the main browsers support the new format natively, JavaScript and WebAssembly will be able to diverge again.

The team notes that the idea here is not to replace JavaScript, by the way, but to allow many more languages to be compiled for the Web. Indeed, chances are that both JavaScript and WebAssembly will be used side-by-side and some parts of the application may use WebAssembly modules (animation, visualization, compression, etc.), while the user interface will still be mostly written in JavaScript, for example.

It’s not often that we see all the major browser vendors work together on a project like this, so this is definitely something worth watching in the months and years ahead.