Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News WebAssembly: A Universal Binary and Text Format for the Web

WebAssembly: A Universal Binary and Text Format for the Web

Leia em Português

This item in japanese

Lire ce contenu en français

Mozilla, Google, Microsoft and Apple have decided to develop a binary format for the web. Called WebAssembly, this format could be a compilation target for any programming language, enabling applications to run in the browser or other agents.

A couple of years ago, we discussed here on InfoQ the merits of a universal bytecode for the web (see Debate: Do We Need a Universal Web Bytecode?), outlining the difficulties in creating one. The main problem mentioned was the disagreement between the major browser makers: Mozilla was pushing asm.js, Google was behind PNaCl, Apple was working on FLTJIT, while Microsoft were not showing interest in any of them. But that has changed. All four major browser vendors have agreed on creating WebAssembly or WASM/wasm, a binary format for the web. Some call this a bytecode, but wasm is not a bytecode in the traditional sense, as Brendan Eich noted: “And WebAssembly is indeed a compressed AST encoding, not a stack bytecode. Shhh, don't tell anyone. You can still call it bytecode if you like.”

The project has been in stealth mode so far, but now it has become public with a GitHub presence and a W3C Community Group. WebAssembly is meant to allow programs written in languages other than JavaScript to run in the browser and other JS agents on the server, mobile or IoT. This format will eventually replace asm.js and PNaCl. According to the project’s design documents, which are not yet definitive, WASM uses a binary because it “provides efficiency: it reduces download size and accelerates decoding, thus enabling even very large codebases to have quick startup times.” WASM has an accompanying text format that can be used by debuggers and other tools facing the developer. Tools should be able to translate from one format into the other without any loss of information.

A first temporary step in implementing WebAssembly has been made: translating the format into corresponding asm.js code so it can already run on supporting browsers: Firefox, Edge, Chrome. There is already a polyfill prototype built for this purpose, and initial results show that the gzipped binary format is 20-30% smaller than the corresponding gzipped asm.js, and that wasm decoding is about 23× faster than parsing the corresponding asm.js source. WASM will later be natively supported by the browser’ VM.

WebAssembly will first bring C/C++ programs to the web, but later it can be enhanced to support any other language. A LLVM backend and a clang port are planned. WASM will execute in the “same semantic universe as JavaScript”, will support asynchronous calls to/from JavaScript, access all the browser APIs, and comply with the same security policies JavaScript programs are subject to. A client application could be written completely in WASM or it could have the business code in WASM and the UI in HTML/CSS/JavaScript.

Announced on the heels of JavaScript’s 20th birthday and on the same day Ecma announced the final approval of ES6, WebAssembly is not good news for JavaScript: WASM will make it possible to code for the web in any language that will compile to it. JavaScript will directly compete with other languages. Should we expect to see Java or C# compiled to WASM?

WebAssembly will benefit from lessons learned developing asm.js and PNaCl, since the respective teams from Mozilla and Google are involved in creating it. Having Microsoft and Apple supporting it is very promising for the project. The only problem remaining is time: usually projects developed by multiple large corporations take a lot of time. The standardization process is slow in such cases.

Rate this Article