By: Matt Butcher
I am often surprised when I hear folks ask, “When will WebAssembly be ready for production?” There seems to be some lurking suspicion that something is holding WebAssembly back. But the simple truth is that WebAssembly (the standard) was ratified years ago, and that WebAssembly (the technology) is broadly deployed in production already—and has been for years.
So what’s at the root of the Fear-Uncertainty-Doubt about WebAssembly?
WebAssembly Is Already Out There
If you use Microsoft’s online Office.com suite or the popular Figma graphics tool, you’ve already used Wasm in production. If you’ve used a device to watch streaming services like BBC or Amazon Prime, you’ve already used Wasm in production. In fact, you’re using Wasm in production right now. This website has been powered by server-side Wasm since its initial launch in February of 2022. Our serverless platform for developers, Fermyon Cloud, has been in production since the middle of that same year, and we currently have thousands of user-built apps running there.
We’ve noticed a growing number of applications in Fermyon Cloud hitting the usage metrics we associate with “production usage” (an algorithm we use that takes into consideration number of inbound requests, consecutive days of activity, and features activated for the deployment).
The trend is clear to us: More and more server-side Wasm apps are making it into production on Fermyon Cloud.
And we’re not the only serverless Wasm in production; Fastly’s Compute@Edge is powered by WebAssembly, and is said to have 10k users. Cloudflare also supports WebAssembly workloads in Workers (albeit in a slightly more complicated fashion). Shopify first announced their WebAssembly-based plugin system back in 2020.
tl;dr: From browsers to servers to IoT to edge to backends, Wasm is in production already.
What About Language Support?
Sometimes the perception that Wasm is not ready for prime time stems from uneven language support. Most languages already support Wasm to one degree or another. Java has been slow to officially adopt Wasm, and thus has a somewhat fragmented ecosystem. But many other langauges are far more advanced, with Python, Ruby, Rust, Kotlin, Go, and .NET all having official Wasm support. Swift, C/C++, Go, JavaScript, and TypeScript all have excellent and highly stable implementations maintaned by the open source community (and rumor is that Apple will add Swift support officially).
A variety of languages, then, are production ready. But what about the APIs…?
That WASI Thing
WebAssembly has a set of extended interfaces collectively called the WebAssembly System Interface (WASI). This bit is chugging its way through standardization, due to be finalized in 2025. But if there is one thing we should have collectively learned from the standardization of HTML, CSS, HTTP, JavaScript, and onward, standards-based implementations often stabilize and reach production readiness far sooner than the standards body can walk its lumbering gate to a final ratification. While WASI continues to add new interfaces, the core interfaces (components, file system, environments, and so on) have long been stable, and have long been deployed into production.
Not all languages stay up to the latest version of standards, just like not all browsers support the latest CSS or JavaScript features. But the majority of WASI is supported by most languages. So just like the related browser technologies, WASI can safely be used in production.
It is true that not all libraries for every language will be supported out of the box today, or ever. Again, this is a distraction from whether Wasm itself is production-ready. But it is true that because Wasm does not grant access to many low level aspects of the underlying system (a feature of Wasm’s security sandbox), libraries that attempt to do lower-level things such as dynamically loading DLLs or SOs, interacting directly with low-level IO primitives, or intereacting with processes, will simply not work. That has little to do with maturity, and everything to do with security. There’s a special case, though: concurrency.
What About Threading?
One misconception about WebAssembly is that it is not stable until support for threading is added. WebAssembly does not currently support multi-threading, and this was a design decision made early in the original planning process.
But absence of a feature does not equate to instability.
JavaScript, TypeScript, Go, and PHP are example languages that are highly mature, but have never had threading. Most other languages that support threading don’t require that developers use threading. And many new languages (Rust and JavaScript among them) implement asynchronous computing without explicit reliance on threading.
That said, threading will someday come to Wasm. Until that time, there are certain classes of applications that are unlikely to benefit from being targeted to Wasm (databases come to mind as an example). But that is okay. A huge swath of applications simply do not need threading. Again, see JavaScript and PHP as tremendously successful (and obviously production-ready) examples.
So Why Does The “Unreadiness” Perception Persist?
In the late 1990s, the XML standard was generating all the buzz. There was a core XML specification, followed by a littany of other add-on specifications ranging from the simple extension of XLink to the sophisticated transformer XSLT and even on into modeling specific domains like VoiceXML. Dozens of XML-related standards made their way through standards bodies. Some advanced slowly even though they enjoyed broad adoption even before being marketed complete. Others advanced quickly to 1.0 status (and beyond), but rallied almost no usage in the real world. The takeway here is that version numbers on standards do not always match with a technology’s readiness or usefulness.
Yet a few loud and influential parties maintain that Wasm is not ready for production. Often, they completely ignore in-production examples like Office.com, Figma, BBC, Fermyon Cloud, Amazon Prime, Fastly, and others. Instead, they point to emerging tools, as if the readiness of each and every new WebAssembly tool is somehow required before the technology as a whole can be deemed “ready.”
Others forget the lessons we learned from XML, ECMAScript (the post-hoc standardization of JavaScript that stabilized years after JavaScript was the most broadly used programming language), and others: The blessing of a standards committee does not production-ready make.
A technology is production ready, by definition, when it is used in production. Millions use Office.com and Amazon Prime players daily. Likewise, hundreds of thousands use Figma. Thousands use Fastly and Fermyon Cloud. Fermyon Spin, which has recently released its third major release, has been downloaded almost a quarter of a million times. SpinKube, a platform for running Wasm inside of Kubernetes, passed the 80k download mark in its first six months of existence. WebAssembly is used — broadly used. And that we can say with certainty.
“When will WebAssembly be ready for production?”
Yesterday.
Top comments (0)