The Risks of WebAssembly
Matt Butcher
webassembly
bytecode alliance
Here at Fermyon, we are enthusiastic (to say the least) about WebAssembly. But we also value openness, thoughtfulness, and caution. Intellectual honesty is the practice of examining available evidence in a way that includes not just confirming information (see the Confirmation Bias), but also information that may run counter to the thesis. Following this practice helps us all see the potholes in the road before we run over them.
When it comes to WebAssembly, we at Fermyon are well-informed. Our own roadmap is informed by the risks of Wasm. We figured it was high time to get these things out in the open, and also talk about how we plan to mitigate these risks.
In this post, I cover the following risks:
- Slow-moving standards
- Language support
- Growth of the ecosystem and community
- Destructive technical fragmentation
While the risks certainly exist, there are clear ways to move beyond each risk. WebAssembly is no longer niche, and it’s no longer a browser-centric technology. But it is still up to us, the early ecosystem, to get it up to full velocity.
1. Standards Move Slowly
It is probably a truism to say that standards move slowly. Oftentimes, the slow-moving nature of standards bodies is a good thing. We don’t want standards that were whipped up overnight by a small group of people who had a rough idea of a solution. We want robust and enduring standards. But speed can still be a hindrance.
While we don’t need a comprehensive list, it’s good to call out a few standards in flight for WebAssembly. These have been under development for over a year.
There is plenty of momentum behind these, and certainly no shortage of interested parties. Let’s look at why the standards are moving slowly.
There are two attributes of a good standard:
- It provides a specific, clear and relevant proposal to solve a problem
- It takes into account not just the present, but the (near) future
The first one is true because we all need to understand how to engage with the standard to achieve interoperability. The second one is important because a standard needs to accommodate the new things that will be built upon it.
Because standards are, by their nature, cooperative endeavors, most standards bodies also implement procedures designed to give many individuals (often representing many organizations) a voice in the process.
Many people, strong proposals, and future focus combine to make for a process to which speed is anathema. Standards are slow; and this is good.
Well, it’s good unless you’re in a hurry. And startup life is steeped in a sense of urgency. Thus, regardless of whether slowness is a virtue for standards, a startup scrabbling to create a sustainable business cannot simply wait.
At Fermyon, we have chosen to address the problems with a two-pronged approach:
- We take part in standards that are relevant
- We design our code to make the most of today’s standards
The first one explains why Fermyon is a member of BytecodeAlliance and participates in W3 work. And the second one is exhibited through the way we built Spin to take advantage of WASI (via Wagi) and the component model as they are today. We could have built a bunch of custom WebAssembly extensions, and perhaps doing so would have temporarily gotten us ahead. But long term we would merely be out of compliance with standards. Building the best software we can with today’s standards has proven a better path for us.
The risk: To be thorough and useful, standardizing is a slow and methodical process. The mitigation: Make calculated design decisions to play to today’s strengths, and defer taking a stance on standards until they begin to stabilize.
2. It’s All About Language Support
At heart, WebAssembly is a binary format and a description of how the format is to be executed. And from a language perspective, that means WebAssembly is a compile target.
- For any compiled language, the barrier to running in a WebAssembly context is whether or not programs in that language can be compiled to the Wasm binary format.
- For any scripting language, the barrier to running in a WebAssembly context is whether the interpreter can be compiled to WebAssembly.
Fermyon is building a WebAssembly platform. And what that practically means is that we can support any, but only, languages that can be executed in a WebAssembly context.
Three years ago, that meant that only C and Rust could be used to write WebAssembly. Over time, several more languages have been added.
At Fermyon, we believe that at least 15 of the top 20 languages must fully support WebAssembly plus WASI and components before WebAssembly can be rightly considered well-adopted.
There is some good news on this front:
- Language support is growing rapidly, with C#, Python, and Ruby all adding support this year (and a few more still likely to show up before 2023 dawns)
- WASI support is now table stakes for languages getting into the Wasm game
- Where a mainstream implementation language fails to do its part, alternate implementations of that language are stepping up. Go is an example, with TinyGo now surpassing Go’s WebAssembly support.
When it comes to working around this limitation, Fermyon has taken the stance that we can focus our attention on languages that are most loved. That is why we write most of our examples in Rust instead of C or Zig (both languages with excellent Wasm support).
Increasingly, we at Fermyon have become actively involved in working on languages. And over the remainder of the year, we expect to announce contributions to a few more of those top 20 languages.
The risk: 15 of the top 20 languages should have Wasm support before we can consider it mainstream. The mitigation: Prioritize working with trending Wasm languages (like Rust), contribute to the others.
3. Ecosystem is Not Optional
Niche technologies are not, by definition, major movers and shakers. That is why we don’t believe WebAssembly is niche. WebAssembly has the potential to alter the way we do browser, plugin, edge, and cloud programming. It has the potential to change the way we do dependency management, and the way we work with shared libraries. In short, it is poised to be the next wave of computing. But unless we can gather a sizable community around it, it is also in danger of being a niche technology.
What is an ecosystem? Is it just a conference and a handful of corporate sponsors? Is it a Discord server or a Twitter community? These things all help, but an ecosystem has a few higher level characteristics:
- Space for community: The sociologist of science Bruno Latour talks about the centrality of gatherings to advance the sciences. What he sees is that we needed space to discuss the things we examine. I think this is quite possibly the best definition of what, in the open source world, we call community.
- Space for competition: There must be multiple creators in the space, and they must be allowed to compete in the marketplace of ideas. This is the space in which we work to realize our individual visions.
- Space for collaboration: There must be movements within the community to collaborate together on foundational aspects of the technology. This is the space in which we work together to create something mutually beneficial.
The parties interested in WebAssembly need to focus more attention on providing and growing these spaces. That means conferences, meetups, open developer meetings, Discord servers, Twitter communities, and whatever else it takes to help others discover and participate in the ecosystem space.
One thing I have appreciated about working on WasmDay (CNCF’s one-day, twice annual WebAssembly conference) is that the organizers come from competing organizations (Microsoft, Cosmonic, Fermyon, Profian, SUSE, etc.), but we frequently collaborate (on the component model, on language support, etc), and we are working to create a space for community at these events. We certainly aren’t “the ecosystem,” but we’re working hard to contribute to a nascent and bigger ecosystem. This and other efforts are critical if we are to create a true ecosystem.
The risk: We need spaces to collaborate, compete, and commune. But those spaces must be created. The mitigation: Those interested in and participating in the ecosystem must be intentional about working together to create the write spaces for an ecosystem to thrive.
4. The Fragmentation Grenade
The last risk to WebAssembly that I’d like to point out is the one that concerns me the most. It scares me because I have seen it happen too frequently. It scares me because ego, “not invented here”, secrecy, and disdain for others can lead here. And it scares me because old school thinking about “capturing a market” often results in pursuing a course of action that results here.
Fragmentation.
This happens when a core technology is co-opted by many parties, each of whom attempts to make their implementation incompatible with the rest. Sometimes incompatibility is done in the name of speed or feature-fulfilment. “We needed to fork from the standard in order to meet customer demand.” Other times, it comes as a parry to competitors: “We diverted from the mainstream so that we could gain competitive advantage.“ Sadly, it is sometimes due to nothing more than ignorance and uninvolvement: “We didn’t know there was a standard emerging for that.”
In any case, the result is that just because two platforms use WebAssembly, there is no assurance that they can run each other’s code.
Right now, there are two well-known and understood paradigms for building WebAssembly applications:
- The in-browser case compiles WebAssembly binaries and adds JavaScript bindings to attach to the browser API
- The WASI case compiles WebAssembly binaries to something that can be executed as a system-level application (e.g. server, command line program)
A third class is rapidly on the rise:
- Compile WebAssembly binaries into a host-specific form that only bespoke hosts can execute.
The third case seems inescapable to some degree. We do, after all, want to build applications that fit into our own preconceptions about how an application should be executed. But this emerging case is the one that the component specification (in progress, but rapidly maturing) is designed to address. This standard makes it largely possible to share WebAssembly binaries across different host implementations.
But we have been noticing an unfortunate trend that some developers have chosen to work contrary to the component model, creating strong links to their own host runtimes. Going this route results in platform lock-in on one hand, and the pointless re-authoring of the same code (tooled for slightly different hosts) on the other.
We are at a crucial junction in this regard. No one vendor has captured too much of the ground floor. Fortunately, those who were best poised (Fastly, Mozilla, Microsoft) have instead opted to push toward standards of interoperability to the benefit of all. That is the correct first move. To head off the destructive fragmentation grenade, we must increase the social pressure to not go one’s own way, but to stick to interoperability standards. A key way of doing this is to work openly with each other (through groups like Bytecode Alliance, W3, and CNCF) not just to create and implement standards, but to create forums for conversation.
The risk: Some will choose to ignore standards and interoperability and build bespoke WebAssembly binaries. The mitigation: Social pressure and collaboration must happen in the open.
Conclusion
WebAssembly is likely no longer a niche technology. And it has a whole lot of potential. But that potential can still be thwarted by a few critical mistakes, bad intentions, or technological missteps.
I’ve outlined four risks. If pressed, though, I would say that one of these four is more important than the rest.
Ecosystem is not optional.
Until we can successfully build an ecosystem with a sense of community, collaboration, and competition, the other risks will persist. Conversely, the faster we foster an ecosystem, the sooner we will see finished standards, language support, and agreement on interoperation.
To that end, here are several ways we can all work on ecosystem:
Our vision is that in five years, WebAssembly will be the norm, not the niche. A new wave of applications will be able to take advantage of WebAssembly’s speed, security, and component model. To get there, every one of us has a role to play.