WebAssembly

In 1995, JavaScript emerged as a simple scripting language. No one imagined it would become the engine for sophisticated Web applications. Originally, it was mainly used to validate forms or animate a few page elements. The heavy lifting was done on servers, with browsers only handling display and basic interactions.

Everything changed with the arrival of high-performance engines like V8. JavaScript began handling programs of several thousand lines, applications that would have been unthinkable just a few years earlier. The language found itself being used far beyond what it had been designed for.

This transformation pushed Web stakeholders to seek alternative paths. Microsoft tried its hand with ActiveX, which relied on signing x86 binaries—an approach based on trust rather than genuine technical guarantees. Google then developed Native Client, which introduced sandboxing for machine code on the Web. Performance approached native levels, but developers had to follow strict constraints in their code, such as using binary masks before each memory access.

Emscripten then opened up a new possibility: compiling C or C++ to JavaScript. The system created a runtime environment in JavaScript and translated the code to a specialized subset, which gave birth to asm.js. Low-level code could finally be executed in a browser, but JavaScript remained a constraining intermediary.

It was in 2015 that the story took an unexpected turn. Engineers from Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari sat down at a table to work together. These historical competitors, who had engaged in "browser wars" for years, decided to collaborate. Their goal? Create a portable bytecode format they called WebAssembly.

The project had clear ambitions. It needed a compact representation, fast validation, efficient compilation. And above all, safe execution without performance penalty. The designers made a bold choice: formalize the semantics from the start. WebAssembly thus became the first industrial language designed with formal semantics from its inception.

The resulting architecture has some distinctive features. WebAssembly relies on a stack machine to represent computations. But thanks to its type system, compilers can analyze data flow between instructions without having to physically materialize this stack. Control flow is structured: no wild goto, but classic constructions via nested blocks.

Memory works like a large array of bytes, separated from code and the execution stack. A failing or compromised program can only corrupt its own data. This isolation ensures security: the code executes in a sandbox that prevents it from accessing the host system without authorization.

The binary format was designed for the network. Instructions fit in one byte, integers use the LEB128 format. Browsers can start compilation as soon as the first bytes are received, without waiting for the complete module download.

In 2017, the four major browsers integrated WebAssembly support. Each team chose its own implementation strategy. V8 and SpiderMonkey repurposed their JIT compilers to compile modules before instantiation. JavaScriptCore followed a similar path. Chakra preferred to translate on the fly to an internal bytecode, then compile the most frequently used functions.

WebAssembly often reaches 80 to 90% of native code performance, while maintaining the Web’s portability and security. The generated code is compact: 62.5% of the size of asm.js on average, 85.3% of that of native x86-64.

WebAssembly’s influence extends beyond the browser. Its design makes it usable in other contexts. Standalone implementations exist that transform WebAssembly into a portable format for native applications. This echoes Java’s original ambition of "write once, run anywhere."

Development continues. Zero-cost exceptions have arrived, as have threads and SIMD instructions. Integration with browser garbage collectors is underway, which will facilitate the compilation of languages like Java, C#, Swift, or OCaml to WebAssembly.

Beyond the technical aspects, WebAssembly testifies to the achievement of collaboration in the Web ecosystem. The project shows that a rigorous, almost academic approach can coexist with the realities of industrial development. This technology has redefined what can be run in a browser, without sacrificing the security that lies at the heart of the Web.