02 Runtimes
WebAssembly
The runtime that replaced the plugins is part of the browser itself, which is the whole point of it.
The instruction set moved into the browser itself, which is the reason nobody can withdraw it.
oujouer.com collection
The standard that ate the plugins
When Adobe's Flash runtime was blocked at the end of 2020, the question was not merely what had been lost but what would replace it — not for nostalgia's sake, but for the next fifteen years of games running in a browser without an installer. The answer, already in place by then, was WebAssembly: a binary instruction format that executes inside the browser's own JavaScript engine, defined by the W3C WebAssembly Working Group and ratified as a web standard in 2019.
The crucial difference between WebAssembly and every plugin runtime that preceded it is architectural. Flash required an external process with elevated permissions; Java applets ran in a sandbox that the browser had to negotiate with via NPAPI, the plugin interface that first Chrome and then the rest eventually removed. WebAssembly runs inside the same sandbox as JavaScript, with no additional permissions and no separate install. The Khronos Group's WebGL sits alongside it to handle graphics. Together they form the substrate that the browser vendors — Mozilla, Google, Apple, Microsoft — agreed to ship as a native capability rather than a feature a third party bolts on.
The manuals outlasted the plugin. Documentation is often the last part of a runtime still legible.
oujouer.com collection
The lineage is direct and unglamorous. Mozilla's asm.js project, begun around 2013, demonstrated that a highly restricted subset of JavaScript could be compiled from C or C++ and run at near-native speed using just-in-time compilation. It was ugly and verbose, but it proved the concept. WebAssembly formalised the same idea as a compact binary format that was faster to parse, easier to validate, and language-agnostic. Unity Technologies adopted it as the successor to the Unity Web Player almost immediately, shipping WebGL and then WebAssembly export targets in their engine, which meant the ecosystem of tools that developers already knew could produce output the open web would accept.
Director shipped on disc first and on the web second, which is why it never reached Flash’s install base.
oujouer.com collection
Why the preservation community cares
For historians of browser games, WebAssembly matters in an unexpected way: it is what makes emulation of older runtimes feasible at scale, inside the browser itself. The Ruffle project — an open-source reimplementation of the Flash runtime written in Rust — compiles to WebAssembly, which is precisely why it can run inside a modern browser page without any special permissions. The Internet Archive uses Ruffle to serve Flash content from its collections, allowing a page request to load a .swf file with no plugin required on the visitor's machine. The same approach underlies the Emularity framework, which the Internet Archive uses to run console and computer emulators in the browser: the emulator binary is compiled to WebAssembly and the game ROM loads on top of it.
The crucial difference between WebAssembly and every plugin runtime that preceded it is architectural.
This is the logic that the preservation argument for emulating the runtime rather than the game depends on. A Flash game preserved as a .swf is a passive object; a Flash runtime reimplemented in WebAssembly is an active machine that can execute any such object the moment it is requested. Because WebAssembly is a genuine web standard, that machine is available in every modern browser without negotiation, without an extension prompt and without a deadline written into the operating system's update cycle.
The irony is tidy. The plugins were killed partly because they required trust and elevated access that the browser vendors were no longer willing to extend. WebAssembly earns its place by demanding neither. It is less powerful in some absolute sense — it cannot reach outside the sandbox in ways that Flash routinely did — but that constraint is the source of its longevity. No security crisis will force a browser vendor to pull it overnight. The WebAssembly specification itself is maintained openly, versioned through the W3C process, and designed to remain backward-compatible as it grows.
The preloader was the only moment the platform showed itself to the player.
oujouer.com collection
For anyone mapping the browser as a games platform across its full history, WebAssembly is not the ending of the plugin story; it is what the plugin era was trying to become. The text era, the applet era, the Flash era and the plugin era were each attempts to give the browser a capable runtime. This one arrived as part of the browser itself.