WebAssembly 3.0 dropped, and the developer community has some thoughts. Business as usual on the internet, right? Sure, but this update to the specification also dredges up ongoing questions about the purpose and identity of WebAssembly (Wasm) that are worth revisiting.
Born from the ashes of Mozilla’s asm.js and Google’s Native Client in 2015, two years later all major browsers (more on Safari below) now support Wasm, which in browser politics time is basically instantaneous. But since then, this W3C maintained specification seems to have stalled. As Hacker News user Diego Moita philosophically notes:
Wasm is and will always be the greatest technology of the future. It will never be the greatest technology of the present.
But things seem to be advancing in the Wasm world. The newest release includes a number of features developers have been clamoring for including garbage collection, exception handling, and multiple memories. Yet, the persistent complaints make me wonder what it will take for Wasm to truly succeed and achieve widespread adoption. What the Wasm 3.0 release highlights for me is its ongoing identity crisis. Is it a faster JavaScript? A way to run legacy code? A universal runtime? If developer discussions are any indication, the jury is still out, and this has broad implications. In this post I’ll discuss developer sentiment around Wasm 3.0 with an eye toward what this release can tell us about this project’s future.
Why Wasm?
What makes Wasm so exciting to many of the developers I know is its array of potential use cases, which include games, peer-to-peer applications, music streaming services, and image recognition—all through the magic of in-browser compute.
But client-side compute has its fair share of skeptics. In some respects, Wasm is what happens when browser engineers admit that maybe, just maybe, JavaScript wasn’t the answer to every computational problem on the web. I enjoy Sean Terretta’s explanation that, to his way of thinking, Wasm succeeds in moving browser development beyond JS and plugins without fully committing to serving as a virtual machine:
document browser, document reader, printed paper, paper form, return to sender… those are all in the same concept space*
“virtual machine” is clearly not
that said, I love WASM in the browser, high time wrapping media with code to become “new media” wasn’t stuck solely with a choice between JS and “plugins” like Java, Flash, or Silverlight
it’s interesting to look back at a few “what might have been” alternate timelines, when the iPhone was intended to launch as an HTML app platform, or Palm Pre (under a former Apple exec, the “pod-father”) intended the same with WebOS. if a VM running a web OS shows a PDF or HTML viewer in a frame, versus if a HTML viewer shows a VM running a web OS in a frame…
we’re still working on figuring out whether new media and software distribution are the same.
Questions about what sorts of compute tasks are appropriate for the browser are far from new. For instance, two years ago my colleague Stephen O’Grady noted Wasm’s implications for the PaaS market:
The broadest market impact … would come from WASM PaaS-like abstractions capturing workloads at scale. While vendors like Cosmonic and Fermyon were built around WASM … and others like Cloudflare, Fastly and Vercel have spun up that capability—or in Fastly’s case, hired an entire team out of Mozilla—there are some obstacles between WASM and a role of outsized importance.
As Wasm’s role continues to evolve, some developers express reservations about running executables directly within the browser. Hacker News user prewett articulates this sentiment specifically as it relates to online video editing:
I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more.
The exciting breadth of Wasm’s potential applications (inclusive of video editing) makes it crucial to observe how, or if, the Wasm 3.0 release will finally meet its promise of revolutionizing interactive workloads.
Wasm 3.0 Major Updates
Before digging into the updates it’s worth taking a step back to acknowledge what these improvements suggest about the health of the community. Wasm benefits from an active working group and vendor support which is a strong signal to the market that Wasm isn’t going anywhere. While I draw from the internet’s squeakiest wheels in terms of excitement and criticism, let’s not lose sight of the tremendous investment so many have put into improving the Wasm specification, which the 3.0 release demonstrates. So, without further ado, here are three of the most talked-about updates.
64-bit Memory
Wasm just jumped from a 4GB memory limit to a theoretical 16 exabytes. This is huge for applications like Figma where “files with over a million layers” can now fit in memory. As Jacob Miller, a PM at Figma, wrote on Hacker News:
I’m definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma.
The new limits make previously impossible web applications suddenly feasible. However, some developers are less sanguine and instead emphasize the “theoretically” part of this announcement. The Front-end Fire podcast’s hosts, for instance, express special skepticism about this claim, noting that Wasm 3.0’s modules are actually limited to 16GB by the browsers. As one host explains, this is “still a lot of memory, but it’s not in the exabytes.” In other words, because the platform limits memory, the specification’s limits are practically meaningless. René Hickersberger extends this complaint to note the performance sacrifice this entails, explaining:
Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn’t necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time).
Garbage Collection
Previously, if you wanted to use a garbage-collected language with Wasm, you had to ship the entire garbage collector with your code, but no more! Many developers are ecstatic about this change because it will improve the language support story for Wasm dramatically. As Reddit user andreicodes explains:
GC should open [the] floodgates for many more languages to become viable for WASM in the browser. Previously you realistically would use Rust, C, C++, and AssemblyScript for it. And while many other languages had ports, they would bundle the whole runtime along with your code to make it work. This meant larger downloads and longer initialization times. I suspect the languages like Go, Python, Java, etc will have low-overhead WASM runtimes pretty soon thanks to this work.
And, while we’re on the subject of programming languages, there’s a Rust story here. Throughout the discussions I encountered online, Rust kept coming up as the golden child of Wasm development. As Christopher Joel notes:
Don’t sleep on the Rust toolchain for this! You can have DOM-via-Wasm today, the tools generate all the glue for you and the overhead isn’t that bad, either.
With Rust’s popularity continuing to grow, Wasm’s ties to the Rust community are another strong signal of Wasm’s deepening toehold.
Multiple Memories
This feature is probably the most esoteric, so I will just quote the announcement: “a single module can now declare (define or import) multiple memories and directly access them, including directly copying data between them.” Questions regarding precisely what “multiple memories” entail has garnered a range of reactions on Hacker News that tend to span the theoretical to the aspirational to the tongue-in-cheek. Here are a few:
Benji York, Sr. Staff Software Engineer and Tech Lead at Cribl, says:
Stray thought: the way Zig uses first-class allocators might make it interesting for doing things with multiple memories
Andre Weissflog shares this aspirational musing:
I wonder if the multiple-memories feature will somehow allow [us] to avoid the extra copy that’s currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn’t accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back.
Multiple WASM memories and Clang’s/LLVM’s address space feature sound like they should be able to solve that problem, but I’m not sure if it is as trivial as it sounds…
Finally, Joshua Sheard jokes:
The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.
The Wasm 3.0 release announcement includes several additional updates, but the three above have been the buzziest among the developers I follow.
Father, What Am I?
Wasm 3.0 boasts technical achievements that are genuinely impressive. The GC support alone changes the game for many languages, and the 64-bit memory support makes entirely new categories of applications possible. But the community’s reaction shows that technical excellence isn’t enough. Developers want Wasm to be a first-class citizen on the web, not just a very fast second-class one. So let’s chat about some things I’m hearing developers say is holding Wasm back: poor developer experience, the DOM, Safari, and the component model.
While many developers complain about the difficulty of using Wasm, there is a general consensus that better DevX would go far toward improving adoption. Illustratively, Alabhya Jindal shares his frustration with poor DevX:
The WebAssembly community should really focus more [on] the developer experience of using it. I recently completed a project where I wrote a compiler targeting it and found the experience to be rather frustrating.
Another significant point of contention is the DOM. If there’s one thing that unites Wasm developers, it’s their shared frustration with DOM access—either a desire to have it, or annoyance that so many of their fellow developers misguidedly want it. Here are a few examples from Reddit. While New-Anybody-6206’s says: “Let me guess, the DOM is still nowhere to be found?,” user Rusky exasperatedly explains “The DOM is never going to be, and never needed to be, part of WebAssembly itself.”
The crux of the DOM debate as it relates to Wasm has to do with balancing the ease of opinionated features with the freedom of a low-level, portable, and safe specification. Currently, Wasm has opted for the latter, and by all signs will continue on this trajectory. While this choice is strategic for interoperability at a browser-level, workaday developers are disadvantaged by this choice because it makes implementation significantly more challenging. I asked Sunil Pai, Principal Systems Engineer at Cloudflare, for his thoughts on what the Wasm 3.0 release signals for its ever-present DOM woes. He characterized this tension as just one more point of evidence that:
System engineers don’t give a damn about browsers and UI engineers.
The DOM situation accesses the larger question I’m trying to answer, which is what Wasm is for? When developers clamor for the ability to touch the DOM, they do so because without this ability Wasm reneges on the promise of client-side compute as a means to revolutionize web development. As Hacker News user Connor Edwards laments:
When is Wasm finally going to be able to touch the DOM? It feels like that was the whole point of Wasm and instead its become a monster of its own that barely has anything to do with web anymore.
If Wasm isn’t about the web, presumably by means of browsers, then what platform is it tailored for? Relatedly, if as a technology Wasm isn’t intended to be leveraged by web developers as a JS alternative, then who is the intended practitioner persona?
While we’re on the subject of browsers, Wasm continues to lack full support on Safari. Although Can I Use would suggest the contrary, savvy developers have pointed out that Safari is missing support for JavaScript Promise Integration (JSPI), a feature enabling Wasm applications to interact with asynchronous JavaScript APIs, specifically those that return Promises, as if they were synchronous. Developers bemoan that Wasm can’t be widely adopted until Safari fully supports JSPI. Redditor GrandMasterPuba points to the lack of browser support: “Look at all those Red X’s on Safari,” while Hacker News user quix0t3 declares, with all the pathos of someone who’s been hurt before:
steve job’s ghost will prevent Wasm adoption.
Finally, I was surprised to see no mention of the component model in this release. The component model is ambitious, complex, and exactly the kind of thing that makes developers simultaneously excited and terrified (see, for example, this inflammatory r/rust post: “Is the Wasm’s Component Model/ Wasip2 is already dead?”). Moreover, it is widely considered the “the backbone of WASI,” advanced by the Bytecode Alliance among others.
My colleague Rachel Stephens spoke with Luke Wagner, Distinguished Engineer at Fastly, about Wasm’s component model which is, according to Luke:
sort of like a lovechild between containers and modules. They have the isolation of the containers, but they have kind of the developer experience and ergonomics of a module.
What interests me about the component model in regards to my guiding question of what Wasm even is, is that it represents Wasm’s attempt to shift from a way to run C in the browser to creating a universal runtime for everything everywhere.
So What Now?
WebAssembly 3.0 represents both triumph and tribulation. The technical achievements are undeniable—garbage collection that finally makes high-level languages viable, 64-bit memory that enables previously impossible applications, and multiple memories that open new architectural possibilities. Yet the community’s reaction reveals a deeper truth: Wasm’s greatest challenge isn’t technical, it’s existential. Eight years after its inception, developers are still asking fundamental questions about what Wasm is supposed to be. Is it a turbocharged JavaScript replacement for web developers? A universal runtime that transcends the browser? A way to port legacy applications to the web? The answer appears to be “yes” to all of the above, which is both its greatest strength and most paralyzing weakness.
The real test for Wasm won’t be whether it can add more features or support more languages. It will be whether it can finally decide what it wants to be when it grows up. Until then, developers will continue to wrestle with a technology that’s simultaneously too ambitious and not ambitious enough, too web-focused and not web-focused enough, too low-level and not low-level enough. Wasm 3.0 doesn’t resolve these tensions—it amplifies them. And perhaps that’s exactly where WebAssembly needs to be right now: in the messy middle, figuring itself out, one specification update at a time.
Disclaimer: Google, Cribl, Cloudflare, and Fastly are RedMonk clients.