updates for feedback

Signed-off-by: Eric Gregory <eric@cosmonic.com>

Author: ericgregory

_posts/2026-01-22-ten-years-of-webassembly-a-retrospective.md

@@ -4,23 +4,23 @@ author: "Eric Gregory"
 github_name: "ericgregory"
 ---
 
-In April of 2015, Luke Wagner made the first commits to a new repository called `WebAssembly`, adding a [high-level design document](https://github.com/WebAssembly/design/commit/12ee148fb5cfa33331dbffadae06752b1759a7bf) for a "binary format to serve as a web compilation target."
+In April of 2015, Luke Wagner made the first commits to a new repository called `WebAssembly/design`, adding a [high-level design document](https://github.com/WebAssembly/design/commit/12ee148fb5cfa33331dbffadae06752b1759a7bf) for a "binary format to serve as a web compilation target."
 
 Four years later, in December 2019, the World Wide Web Consortium (W3C) [officially embraced WebAssembly (Wasm) as the "fourth language of the web"](https://www.w3.org/press-releases/2019/wasm/). Today, Wasm is used in web applications like [Google Earth](https://web.dev/case-studies/earth-webassembly), streaming video services like [Amazon Prime Video](https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types) and [Disney Plus](https://medium.com/disney-streaming/introducing-the-disney-application-development-kit-adk-ad85ca139073), and game engines like [Unity](https://docs.unity3d.com/6000.0/Documentation/Manual/webassembly-2023.html). Wasm runs on countless embedded devices, and cloud computing providers use Wasm to provide Functions-as-a-Service (FaaS) and serverless functionality.
 
-The road to standardization (and understated ubiquity) would require the teams behind the major browsers to unite behind an approach that Wagner looks back on as "super hacky—*hilariously* hacky." 
+The road to standardization (and understated ubiquity) would require the teams behind the major browsers to unite behind an approach to solve a problem that many had tried, and failed, to solve before.
 
 For the ten-year anniversary of the project (well, ten and change), I spoke to many of the co-designers who were there at the beginning. They were generous enough to share their memories of the project's origins, and what they imagine for the next ten years of WebAssembly.
 
 ## The trusted call stack
 
-In March of 2013, a group of Mozilla engineers including Wagner, Alon Zakai, and David Herman released [Asm.js](http://asmjs.org/). The open source project operated as a subset of JavaScript, embedding a static type system into a dynamically typed language (that is, JavaScript) to enable *better*-than-JS performance for compiled code running in the browser. "Super hacky," in Wagner's words.
+In March of 2013, a group of Mozilla engineers including Wagner, Alon Zakai, and David Herman released [Asm.js](http://asmjs.org/). Asm.js defined a subset of the existing JavaScript language that implicitly embeds enough static type information to allow a browser's existing JS engine to achieve much better performance once the optimizer knew to look for it. "Super hacky," in Wagner's words.
 
 Meanwhile, Google was developing [Native Client (NaCl)](https://developer.chrome.com/docs/native-client/) and its successor  [Portable Native Client (PNaCl)](https://chrome.jscn.org/docs/native-client/nacl-and-pnacl/#portable-native-client-pnacl), to sandbox and run native code in Chrome. 
 
-JF Bastien was on the Chrome team at the time, where he helped finalize the design for NaCl and ship it. According to Bastien, NaCl was a secure sandbox, but it wasn't portable, and didn't "fully respect the ethos of the web." The successor, PNaCl, treated the browser as a plugin host rather than an integrated environment. "There were a lot of interesting ideas in there," Bastien says. "But it was perceived as trying to stomp on JavaScript, where really what we needed was *performance*."
+JF Bastien was on the Chrome team at the time, where he helped finalize the Armv7 version of NaCl. According to Bastien, NaCl was a secure sandbox, but it wasn't portable, and didn't "fully respect the ethos of the web." 
 
-PNaCl placed the program's call stack in its own memory space—a reasonable choice for sandboxing, but one that made it difficult for JavaScript to call PNaCl code or vice versa. The connection between PNaCl and the rest of the browser relied on message passing, which required an entirely separate API surface for graphics, audio, and networking. This created an obstacle to broader adoption. If PNaCl was going to serve as the basis for a multi-browser approach to native code on the web, what standards body would govern the APIs?
+NaCl and PNaCl used an out-of-process isolation model, which effectively required asynchronous calls. This simplified the security model, but posed challenges for interoperability with JavaScript, and required consensus-building on new APIs for functionality like graphics, audio, and networking. If PNaCl was going to serve as the basis for a multi-browser approach to native code on the web, what standards body would govern the APIs?
 
 Asm.js took a different approach, which Dan Gohman—then at Mozilla—describes as a "trusted call stack," where compiled code and JavaScript could share the same stack. 
 
@@ -56,13 +56,13 @@ Bastien recalls internal resistance to the name. "We know it's going to be used
 
 This writer has certainly used the "neither web nor assembly" line more than once, and so did several of the Wasm co-designers I interviewed, but Wagner gently pushes back on the characterization. 
 
-"I disagree on both counts," he says. "An assembly language isn't a well-defined concept. It's just a language that's rather low-level, that's not bits and bytes. WebAssembly is that—low-level enough, but not machine code—so I feel like it *is* assembly. And then people say it's not 'web' because it's being used outside the web. Well, what's the definition of the web? Is it only things in browsers, or is it those things defined by open standards that interoperate with each other? I would say it's the latter."
+"I disagree on both counts," he says. "An assembly language isn't a well-defined concept. It's just a language that's low-level enough that you can compile your other languages to it, but it's not yet pure machine code. WebAssembly is that—low-level enough, but not machine code—so I feel like it *is* assembly. And then people say it's not 'web' because it's being used outside the web. Well, what's the definition of the web? Is it only things in browsers? The W3C paints a much broader picture of the [open web platform](https://www.w3.org/standards/) that I think covers a lot more of the places where WebAssembly runs today and where we want it to run in the future."
 
 ## "Ship as fast as you humanly can before this whole coalition falls apart."
 
 With the Chrome and Firefox teams on the same page, the co-designers turned to the teams at Apple and Microsoft. 
 
-Microsoft's Chakra team, which powered the Edge browser's JavaScript engine, had already implemented Asm.js optimizations—Wagner had personally relicensed Mozilla source code to make adoption easier. After some "intense Q&A" (in Wagner's words), the Chakra team got on board. At Apple, JavaScriptCore team lead Fil Pizlo was instrumental in securing buy-in.
+Microsoft's Chakra team, which powered the Edge browser's JavaScript engine, had already implemented Asm.js optimizations—Wagner had personally relicensed Mozilla source code to make adoption easier. After some "intense Q&A" (in Wagner's words), the Chakra team got on board. At Apple, JavaScriptCore team lead Fil Pizlo (the same Fil of [Fil-C](https://fil-c.org/)) was instrumental in securing buy-in.
 
 The four browser engines—Mozilla's SpiderMonkey, Google's V8, Microsoft's Chakra, and Apple's JavaScriptCore—would ship WebAssembly support within months of each other. Bastien, who chaired the WebAssembly Community Group during this period, helped set up the organizational structure and operating pace for the W3C standardization process. Before Wagner's first public commit, the team hashed out the basic shape of the project in a shared Google Doc. Wagner then transcribed those agreements into public markdown files. 
 
@@ -88,13 +88,13 @@ Gaming had been part of the conversation from the beginning—early demos fe
 
 ## "Name an API in the world and it's in scope."
 
-Asm.js answered the hardest questions for the WebAssembly MVP: What is the security model? What features are in scope? When someone proposed adding coroutines or stack switching, the response was simple, according to Gohman: "That's not in Asm.js. Out of scope. End of story." 
+Asm.js helped answer the hardest questions for the WebAssembly MVP: What is the security model? What features are in scope? When someone proposed adding coroutines or stack switching, the response was simple, according to Gohman: "That's not in Asm.js. Out of scope. End of story." While the team allowed "a few things that weren’t first-class in Asm.js," in Bastien's words, Asm.js served as a guiding light.
 
-The next phase of WebAssembly's evolution offered no such constraints. With the core spec shipped and browsers onboard, attention turned to running WebAssembly outside the browser—on servers, at the edge, in embedded systems. This meant defining WASI, the [WebAssembly System Interface](https://wasi.dev/), and eventually the [Component Model](https://component-model.bytecodealliance.org/introduction.html). Together, these specifications could allow Wasm binaries to communicate with one another. These "Wasm components" would be able to securely interoperate regardless of the language they were written in.
+The next phase of WebAssembly's evolution offered no such scaffold. With the core spec shipped and browsers onboard, attention turned to running WebAssembly outside the browser—on servers, at the edge, in embedded systems. This meant defining WASI, the [WebAssembly System Interface](https://wasi.dev/), and eventually the [Component Model](https://component-model.bytecodealliance.org/introduction.html). Together, these specifications could allow Wasm binaries to communicate with one another. These "Wasm components" would be able to securely interoperate regardless of the language they were written in.
 
 The design space was suddenly vast.
 
-"What surprised me most is how hard it was to figure out what to do for Wasm outside the browser, if not copy POSIX," Wagner says. The Unix-style approach was tempting—just give WebAssembly modules access to files, sockets, and processes in the familiar way. But Wagner saw a trap. "If you just copy POSIX, you're just going to have to reimplement containers but with Wasm on the inside,"  which is not an unambiguous win: it provides portability, but imposes execution overhead.
+"What surprised me most is how hard it was to figure out what to do for Wasm outside the browser, if not copy POSIX," Wagner says. The Unix-style approach was tempting—just give WebAssembly modules access to files, sockets, and processes in the familiar way. But Wagner saw a trap. "If you just copy POSIX, you're just going to have to reimplement containers but with Wasm on the inside,"  which is not an unambiguous win: it somewhat improves portability, but imposes execution overhead. And if it's not a significant improvement, why do a bunch of work on it?
 
 Gohman, who went on to lead much of the WASI design work, recalls the early days as intimidating. "You add WASI to the mix and it's like, now we're going to add APIs to everything," he says. "Graphics, networking, input devices—everything you can do from a browser, but also now we're in servers too. We're going to talk about databases. Name an API in the world and it's in scope for WASI."
 
@@ -118,7 +118,7 @@ Titzer is now Associate Research Professor in the Software and Societal Systems
 
 Bastien agrees. "AI coding agents are are pretty insecure right now, especially third-party plugins. Forget just injection, right? Like, I'm going to run a bunch of code I don't trust. Wasm is a pretty interesting fit." 
 
-Meanwhile, some of Wasm's innovations gleaned outside the browser context may return home. Wagner sees the Component Model reaching browsers, along with a proliferation of WASI interfaces. "I think there's at least a decade of Component Model evolution," he says, "where each addition unlocks more use cases. More and bigger kinds of software should just be [Wasm] components."
+Meanwhile, some of Wasm's innovations gleaned outside the browser context may return home. Wagner sees the Component Model improving the quality of web developers' experience compiling their language of choice to run in the browser, either mixed into their existing mostly-JS web app, or implementing the whole web app itself.
 
 Today, WebAssembly runs in billions of users' browsers, as well as edge networks, clouds, and embedded systems. The project has achieved standardization and understated ubiquity. It's almost certainly running in one of your most commonly used apps, on one of your everyday devices, right now. What and where could Wasm be in ten years? The fundamentals of the architecture, going all the way back to Asm.js, stuck a toe in the door of a vast possibility space.