What’s Stopping WebAssembly from Widespread Adoption?
WebAssembly (Wasm) has been around for five years. That’s a relatively long time in the cloud native space — just three fewer years than Kubernetes has been around, for instance.
Wasm, a binary instruction format for a stack-based virtual machine that allows developers to “build once, run anywhere,” is widely seen to have game-changing potential. So why is it taking so long to be adopted by organizations?
Some of the reasons for slow adoption could be traced to upheaval within the Wasm ecosystem itself.
The AssemblyScript Schism
Recent weeks have provided a clear demonstration of the issues inside the WebAssembly world. AssemblyScript, a language designed specifically for using WebAssembly in the browser, announced that it has removed support for WASI, the Wasm system interface that makes it easier for it to be used outside of the browser.
The details of precisely why AssemblyScript has decided to move away from WASI are unclear, but there appears to be an uneasy mix of technical and personal disagreements.
The WASI project’s proposals focus on WebAssembly’s interoperability with languages like Rust and C++ at the expense of JavaScript; this would ultimately harm AssemblyScript (because of its TypeScript nature) and force it to make significant changes to the project.
AssemblyScript authors claimed in a “standards objections” section in their online documentation that the WASI subgroup of the World Wide Web Consortium (W3C) has “expanded its scope” and “devised its own proposals that … compete with established or currently devised web standards.”
Added to this, the authors also claim that “our representatives have been systematically discriminated and their concerns silenced.”
Alongside this, AssemblyScript also takes aim at the Bytecode Alliance, a group of major tech organizations — including cloud providers Amazon, Google and Microsoft — that have thrown support behind WebAssembly and WASI.
“We’d like to caution the public to keep an eye on potential anti-competitive practices that would indicate the need for antitrust legislation to step in,” AssemblyScript’s authors warned.
There’s some useful context here that’s easy to miss: data suggests that interest in AssemblyScript is declining. Only 17% of respondents in the “State of WebAssembly 2022” survey released in June by Scott Logic said they want to use AssemblyScript a lot in the future, a drop from 26% in the 2021 survey.
Although for AssemblyScript this decline might be symptomatic of its treatment in the wider Wasm project, it’s hard not to see how this is really just a story of changing preferences as developers turn their attention towards languages like Go and JavaScript.
And on the anticompetitive accusation, while the list of Bytecode Alliance members underscores that it represents some exceptionally powerful interests, there’s no reason to believe that what’s happening is more a case of betting on what’s likely to win out rather than forcing through a particular agenda.
Tyler McMullen, chief technology officer at Fastly, an edge cloud platform company that is a member of the Bytecode Alliance, expressed his disappointment about the conflict to The New Stack. But he highlighted that the sticking point centers on a “single, nuanced, technical detail — whether strings are allowed to contain certain invalid code points.”
He also stressed that the decision about this “technical detail” was not made by a single individual or company: “The proposal was vetted and voted on by a large group of people from across the industry, including each of the major browser makers.”
Oscar Spencer, director of engineering at Suborbital, a company that works on open source platform tools, and co-author of the Grain programming language, echoed McMullen’s disappointment but also spoke to the possible impact of the move.
“It’s going to cause a lot of fragmentation,” he said. “Things like this are hindering the development and advancement of standards, which is a little problematic for having this one cohesive ecosystem.”
Tracing WebAssembly’s Trajectory
Conflicts and disagreements like these make it challenging for the wider software community to really understand how and why Wasm should be used.
Although initially intended for the browser, that use case today feels much less urgent. Far more attention and interest come from Wasm’s potential outside of the browser, such as running it on the server (with suggestions that it could be a replacement for or combined with Docker), or bundling code together to run across multiple applications.
Spencer offered his perspective on Wasm’s trajectory: “What we ended up seeing … is that JavaScript engines actually are very, very fast. And just rewriting your existing apps in WebAssembly sometimes didn’t actually make them any faster, just because JavaScript engines have had decades at this point to get really freaking good.
“With that, I think we saw less of a use case for writing entire apps in WebAssembly on the browser and it’s [now] a lot more of, ‘Hey, I need to have this background task that’s really quick.’”
This isn’t to say that Wasm has disappeared from the web. Instead, it has evolved to find a niche: unlocking speed and performance.
Andy Wingo, a software engineer at Igalia, a global open source consultancy, gave The New Stack an insight into this type of work. He cited the example of a recent project he worked on for a widely used, browser-based spreadsheet in which he was trying “to improve the efficiency of strings going between JavaScript and WebAssembly.”
This type of project — which he characterizes as “specialized one-to-one relationships between big stakeholders and browser vendors” — is, he argues, one of the most common contexts in which Wasm is being used today.
This is a useful perspective: it’s an important reminder that despite the level of hype and interest in a new technology, often its immediate impact and even relevance is rooted in very specific use cases. Going on to reference the use of Wasm at companies like Fastly and Shopify, the e-commerce platform, Wingo suggested that, for both of those companies, the Wasm solution is being driven by vendors.
“I perceive these things being driven from desires from the platform holders and generating excitement among users,” he said. “But it’s not users immediately driving features.”
Wingo’s perspective can be explained by a point that McMullen made: the fact that Wasm isn’t supported on every platform. “One of the reasons it’s not yet supported everywhere is that it’s hard to embed. One of the major reasons it’s hard to embed is because there’s no standard model of interaction,” McMullen said.
So, it would seem that despite clear interest from the industry and a strong narrative — run anything and run it fast — beneath it all is considerable complexity and disagreement.
Looking at Wasm as an Outsider
For an outsider, WebAssembly might look strange. While the hype around Wasm only seems to have increased as it has become unmoored from its origins, in moving away from the browser it has also become more fluid and flexible, and therefore much harder to pin down as a technology.
This is perhaps one of the reasons that there is such tension when it comes to the development of standards — there’s a lack of clear consensus, with different groups pulling in different directions.
This isn’t good news for users and prospective Wasm developers, of course. “People have a very basic understanding of WebAssembly in general without knowing why,” Wingo said.
This isn’t meant to be dismissive; instead, it speaks to the gap between the narrative behind WebAssembly (you can run any code in the browser! It has both security and performance advantages!), and the challenge in applying it successfully to particular projects.
This is something echoed by Spencer, who told The New Stack that he believes most people who try Grain come to it simply as a way to explore Wasm. Most users, he said, “want to mess around with doing something in WebAssembly,” but find other languages associated with Wasm, like Rust or C++, too daunting. These, he said, are people “who are just trying to dip their toes in the water.”
Although there’s an undeniable logic to this as far as building a programming language is concerned — helping people onboard onto something that has a reputation for being complicated — data in the Scott Logic survey interestingly contradicts Spencer’s reading.
Among developers that have used Rust with WebAssembly at least sometimes, 24% have some interest in using Grain in the future. Among the remainder of survey participants, only 7% have an interest in using Grain in the future. It would seem that while Grain is delivering on its desire to be easy to use, it’s actually being picked up by those looking for an easier way to solve particularly complex engineering problems.
“Many languages have had wonderful ideas, but they have ultimately been dismissed as esoteric or too difficult to learn and, consequently, have struggled to rally a large community around them,” reads the Grain project’s homepage. “Grain hopes to bring new life to these ideas and present them in an accessible form that’s easy to use and understand.”
Grain’s existence, then, might be seen as speaking to one of the biggest problems inside the WebAssembly ecosystem — the fact that there’s not really an easy way to just get started and to actually see how it can help solve problems.
This is a problem that seems to come up across the internet. On Quora, for example, Julian Jensen — CTO at Licorice, an IT support software company — responded to a Quora question about whether WebAssembly is hard to use.
“Almost every article on the topic you’re likely [to] find invariably features an excessively simple function loaded and executed in the browser,” Jensen answered.
He emphasized his point further: “This type of example in no way resembles anything you’re ever likely [to] write or need in the real world. It also fails to touch on any of the pain points you’ll run into when you try to make something intended to be actually useful.”
Jensen’s opinion might be strong, but it still highlights that despite the level of interest in WebAssembly, its ecosystem hasn’t quite developed in a way that makes learning easy.
But more than that, it also highlights one of the main challenges for Wasm: how can it be presented in a way that’s easily understood by a wide swath of developers without being so simple it becomes meaningless?
The WebAssembly Component Model
The problem comes back to standardization. Without it, accomplishing the very things it promises isn’t as easy as you’d expect from a technology that’s so hyped.
Currently, hope for the future lies in the WebAssembly Component Model. The fact that it has not yet been agreed and finalized by the working group responsible for it is, according to Spencer, “the only thing that’s really stopping … a huge explosion in WebAssembly.”
McMullen echoed that notion. The Component Model, he said, is vital in ensuring that “standard model of interaction” that, in turn, will make it easier to broaden its support.
The purpose of the Component Model is to simplify the use of WebAssembly outside of the browser. By codifying rules and specifications on how different things work together, it should remove some of the cognitive load (and additional code) required to actually put WebAssembly to work.
“The crux of the Component Model,” McMullen said, “is making it possible to share and connect code safely and efficiently across languages and ecosystems. But beyond that, it’s about the interfaces that WebAssembly code exposes and expects. By defining those interfaces in a higher level way, we can start agreeing upon patterns and standards that work across languages and platforms.”
Despite its clear importance to the entire Wasm project, the details of the Component Model are still being hashed out by the W3C WebAssembly Community Group — a process that could take some time. Spencer noticed that, despite best intentions, there are plenty of opportunities for “bikeshedding,” or spending too much time arguing minor details, in this deeply democratic process, which could slow things down.
So how long will the whole process take? Spencer said he “wouldn’t be shocked” if the group didn’t reach the implementation phase until Spring 2023.
McMullen offered a robust defense of delays. “Most industrial standards are not written to the same rigor as WebAssembly and its companion standards,” he said. “It requires extremely high precision wording and is ultimately written in math, which allows us to make strong proofs about the correctness of them.
“The Component Model, in particular, is attempting to define a standard that will work across languages, async models, threading models and industries while maintaining high efficiency and very strong security guarantees.”
Despite slow progress, both Spencer and McMullen acknowledged its importance to Wasm users — today’s and the future’s. “It’s all about the tooling,” Spencer said. “That’s all developers care about at the end of the day.”
Will Wasm Have a Proprietary Future?
The future of WebAssembly — beyond the browser at least — seems to reside in the Component Model. But we should also look beyond it to the wider software market.
“There’s going to be venture-backed competition to occupy this space,” Wingo predicted. “Some of this might trickle down to standards but I think a lot of this is going to be proprietary lock-up.”
This is perhaps a natural evolution of what the likes of Shopify and Fastly are doing now; the question is how easy will it be for vendors to package up WebAssembly into edge compute solutions. If the wider WebAssembly project can help engineers become more comfortable with the technology, this will naturally influence how vendors will deliver such solutions.
This isn’t necessarily the way those inside the Bytecode Alliance see it. McMullen talked about seeing it as a “meta-ecosystem.”
“We’re definitely not trying to ‘one ring to rule them all’ them in any way,” he said. “We want to see a massive diversity of not just languages, but platforms and industries.”
Figuring out Where Wasm Fits
However venture capitalists choose to play their hand, and however the core development groups behind the project’s different forks choose to go forward, Wasm will remain an important and valuable technology that has the capacity to be game-changing in the right scenario.
What’s challenging is resisting the urge to abstract and transform its impact and value into a silver bullet for everyone in software engineering.
“Ultimately WebAssembly is just a compiler target,” Spencer said. “At the end of the day it’s an implementation detail, and if WebAssembly does its job right in a few years it’s not going to be as huge of a buzzword as it is — it’s just the way that things work.”
That future sounds simple and is a reasonable goal for the project. What WebAssembly is showing us today is that actually getting there takes a lot of argument, exploration, experimentation and consensus building.
The Cloud Native Computing Foundation is currently conducting a short Wasm survey that investigates many of the topics discussed in this article:
- Hype: Because it’s focused on the cloud native market, there will likely be a tilt towards the belief that WebAssembly will have a long-term impact as opposed to being just a fad.
- Challenges: Are a lack of skills or tooling the biggest barriers when using Wasm? Would clearer use cases and standards increase adoption?
- Runtimes: To what degree are performance differences and a lack of a consistent developer experience between runtimes a concern?
