Heralded as the fourth standard of the web, WebAssembly, or Wasm for short, has sparked heated discussion since its origins. Wasm is an assembly-like programming language, a compact binary format, and a compilation target for C, C++, C#, Go, JavaScript, Python, Rust, and others that runs at near-native speeds in a web browser. It is well-established in web development and has been inching closer to mass use outside the browser.

Wasm’s compactness, speed, portability, and security have developers excited about its possibilities on servers as well as clients, and even its potential to supplant Linux containers. But will this technology become a mainstream platform that disrupts today’s established container ecosystem?

People close to the Wasm vs. containers discussion are probably sick of seeing this 2019 tweet from Solomon Hykes, co-founder of Docker and co-founder of Dagger, replastered on every sensationalist Wasm article and presentation slide:

If WASM+WASI existed in 2008, we wouldn’t have needed to have created Docker. That’s how important it is. WebAssembly on the server is the future of computing.

The devil is in the details. What Hykes meant to say was that if Wasm had existed back then, the need for containers like Docker wouldn’t have been as acute. Yet, that did not happen, and we live in a universe where Docker containers reign. Replacing mission-critical Linux-based containers is not a trivial act. As Hykes explains:

That tweet of mine was widely misunderstood. It was interpreted as WebAssembly is going to replace Docker containers. I did not think then that it would happen, and lo and behold, it did not happen, and in my opinion, will never happen. Now that Docker exists and is a standard, WebAssembly and WASI, as cool as they are, are very different. It’s not at all a replacement. It has a very different shape.

Most agree that WebAssembly beats containers in the browser, edge computing use cases, sandboxed plugins, and certain serverless functions. While some are more confident about the transformative potential Wasm will have, outlooks are split on Wasm as a long-term replacement for server-side containers or stateful, long-running server processes. Below, we’ll dive deeper to compare where exactly Wasm beats containers, and where it doesn’t.

Where Wasm beats containers

Some developers see Wasm getting extensive use across applications, especially where containers are too clunky. “Wasm is just as adept in embedded IoT as it is in massive cloud infrastructure,” says Matt Butcher, co-founder and CEO of Fermyon. “Wasm is an excellent technology for serverless functions, IoT, edge computing, and plugin-style extension mechanisms,” he says.

On the edge

One area where Wasm shines is edge computing. Here, Wasm’s lightweight, sandboxed nature makes it especially intriguing. “We need software isolation on the edge, but containers consume too many resources,” says Michael J. Yuan, founder of Second State and the Cloud Native Computing Foundation’s WasmEdge project. “Wasm can be used to isolate and manage software where containers are ‘too heavy.’”

Whereas containers take up megabytes or gigabytes, Wasm modules take mere kilobytes or megabytes. Compared to containers, a .wasm file is smaller and agnostic to the runtime, notes Bailey Hayes, CTO of Cosmonic. “Wasm’s portability allows workloads to run across heterogeneous environments, such as cloud, edge, or even resource-constrained devices.”

This makes Wasm suitable for constrained use cases like small, embedded devices. One particular scenario is manufacturing IoT — for instance, MachineMetrics is deploying wasmCloud on the factory floor to process machine data more securely and efficiently.

Performance-critical workloads

Wasm has a clear role in performance-critical workloads, including serverless functions and certain AI applications. “There are definitive applications where Wasm will be the first choice or be chosen over containers,” says Luke Wagner, distinguished engineer at Fastly, who notes that Wasm brings cost-savings and cold-start improvements to serverless-style workloads. “Wasm will be attractive for enterprises that don’t want to be locked into the current set of proprietary serverless offerings.”

In the AI space, Wasm is ideal for cross-platform inference on heterogeneous devices. Containers are very heavy and not portable across GPUs, says Yuan, making them unfit for applications like LlamaEdge, a Wasm-based local runtime and API server for large language models (LLMs).

Component-based architectures

Some look to the WebAssembly System Interface (WASI), a proposed specification from the ByteCode Alliance, as the foundation for an ecosystem of modular components. “We’ll see new types of architectures evolve that capitalize on the size and speed of Wasm components,” says Cosmonic’s Hayes. She points to Wasm’s small footprint, its runtime agnosticism, and its fast cold starts, which significantly reduce latency compared with containers.

Add to that Wasm’s secure-by-default settings, and it has a big leg up on containers. “Containers are generally not considered the right choice for safe sandboxing and isolation of arbitrary user code,” says Hayes.

“We do expect many workloads to be migrated from containers to Wasm,” says Fastly’s Wagner. This is especially true for greenfield workloads, some of which we are already seeing today. “Based on the current standardization efforts around the WebAssembly Component Model, enterprises will choose Wasm as a way to modularize their services while avoiding the overhead of a traditional microservice architecture,” he says.

If, as some advocate, component-based architecture becomes a dominant development paradigm, containers might play less of a role. “Wasm’s big promise is a new way of building applications by assembly components that are each isolated in their own sandbox,” says Fermyon’s Butcher. “As this technology matures, Wasm may not replace containers feature for feature, but there’s certainly potential for Wasm to supersede containers simply because containers won’t add value to component-based applications.”

Plugins for server-side apps

Plugins for existing systems are another strong Wasm use case, Yuan says. Hykes also sees Wasm as being great for highly sandboxed plugins for server-side applications. In fact, developers of plugin frameworks like Istio WasmPlugins, Shopify Functions, and Envoy extensions have already opted for Wasm. And a handful of frameworks on the market make it easy to generate and run such plugins.

Web apps and services

Of course, browser-based web applications are Wasm’s bread and butter. And it’s an area that containers don’t really touch. Wasm on the browser is well-established and well-supported, meaning the barrier to entry is much lower. As such, Wasm already powers countless high-performance web apps.

For example, Adobe actively integrates Wasm into web-based versions of Photoshop, Express, Lightroom, Acrobat, and other applications. “Wasm is designed around running short-lived programs very quickly, efficiently, and securely,” says Colin Murphy, senior software engineer at Adobe. “As it matures, it will continue to grow its applicability in other areas of computing, such as web services.”

“Wasm on the browser is finally making real headway,” says Hykes. “I think that’ll go mainstream finally.” He notes how Dagger’s back-end engineers are writing front-end code in Go and compiling it to Wasm. “Back-end engineers are disempowered in general since they can’t do front-end development. This is a way to empower them.”

Where containers beat Wasm

All that said, there are places where containers will continue to rule. “Stateful, long-running compute and appliances like databases are unlikely to be replaced with Wasm,” says Cosmonic’s Hayes.

Similar to how containers did not entirely replace virtual machines, the evolution toward Wasm will not be complete. “To jump to the conclusion that WebAssembly will unseat containers is equally as reductive,” says Butcher. This means we’ll likely see Wasm apps running alongside the thousands of apps already running in containers on Kubernetes.

Large-scale server processes

“Wasm is not great for long-running server processes,” Butcher says. “The sweet spot for containers is packaging and executing existing long-running servers (like Postgres or WordPress or your company’s enterprise Java app). I don’t foresee Wasm challenging that space in the next decade.” He credits this to a lack of threads, weak socket support, and the fact that many of the supported languages are not optimized for Wasm.

Wasm can’t easily replace containerized workloads that rely on features of a particular OS or CPU that are not yet supported by Wasm, notes Fastly’s Wagner. The same goes if the workload uses a language that doesn’t have full Wasm support. However, Wagner believes these concerns will dissolve as the Wasm ecosystem matures.

Others aren’t so sure. “Wasm’s security model doesn’t grant access to many of the low-level operating system primitives that server applications access and there’s no reason to expect this to change,” says Butcher. “The vast majority of large code bases can’t simply be compiled to WebAssembly. Code must be rewritten. While some would claim that this is a temporary situation, I don’t think it is.”

Even Cloudflare, a poster child for the next generation of cloud platforms that seemed to replace containers, uses containers at the core of its Workers platform. “If you’ve used AI inference on GPUs with Workers AI, spun up headless browsers with Browser Rendering, or enqueued build jobs with the new Workers Builds, you’ve run containers on our network, without even knowing it,” says the Cloudflare blog.

The takeaway is that containers complement and coexist with other development approaches. And most likely they will continue to do so.

Linux-based cloud-native systems

Linux has proliferated, and containers are intrinsic to this operating system, making them challenging if not impossible to displace. “If you’re talking about replacing containers, you have to talk about replacing Linux,” says Hykes.

“Containers are now a core feature of Linux. Not just the kernel, but the operating system layer, the standard stack around it, and the standard way you run Linux in the data center in the cloud,” Hykes notes. “They will always be there. The only question is, ‘Do you add a layer on top?’”

While containers could certainly host Wasm components, it’s hard to envision Wasm becoming a general-purpose, server-dominating platform the way Linux is today. “At the moment, I don’t see that happening because there’s no obvious reason to switch to this new platform en masse,” says Hykes.

Others agree that a wholesale replacement of today’s current container stack isn’t worthwhile. “I think in most of today’s cloud-native applications, Linux containers are the right tools, and they should not be replaced,” says Second State’s Yuan. “Wasm is for new use cases where isolation is needed, but containers cannot go.”

Other situations where execution time must be minimized make Wasm a nonstarter. “There will also usually be a modest runtime overhead executing Wasm versus native code, and for some workloads, any overhead at all may be unacceptable,” says Fastly’s Wagner. “In those instances, Wasm will not replace containers.”

Wasm and containers

Kubernetes seems inextricably intertwined with the future of cloud infrastructure. While some have predicted that Wasm could replace container-based runtimes by 2030, many disagree. Instead of Wasm replacing the current container paradigm, they see it becoming embedded into this fabric.

Yuan is reluctant to say that Wasm will replace containers — rather, he views them as complementary technologies. To his point, the Bytecode Alliance and CNCF are making strides to ensure that Wasm complements Kubernetes, such as by developing projects that allow containers and Wasm modules to be run side by side in the same cluster.

Others see a future in which Docker runs Linux containers, Windows containers, and Wasm containers side by side. Hykes believes this is a feasible model yet admits demand is low. This is in part because adoption of WebAssembly on the server has not been widespread, says Hykes. It remains a niche use case.

“In order for it to blow up, it’s missing a mainstream use case, a reason everyone must use it on the server, and a way to easily use it,” Hykes says. “It’s really hard to get people to adopt a new platform. You better have a use case.”

Outlooks for Wasm

In the long term, entirely new markets and computing paradigms will likely be made possible with Wasm. “Many of the silos between data center, edge compute, mobile, and IoT will be broken down because of the breakthrough in portability and composability that WASI enables,” says Adobe’s Murphy.

In addition to the applications mentioned above, Wasm spans sectors, too. “We’re seeing wasmCloud being adopted in a wide variety of use cases in banking, manufacturing, telecommunications, digital services, gaming, and more,” says Cosmonic’s Hayes. For instance, TM Forum’s WebAssembly Canvas Catalyst team has demonstrated a proof of concept for replacing Kubernetes using wasmCloud to manage its open APIs.

Refactoring would take work, but it would unlock efficiency gains that the container-era did not require for entry. “Docker and Kubernetes were innovative in so many ways, and if you refactor your applications to take advantage of them, then they are amazing,” says Murphy. “In most cases, however, applications were simply containerized with minimal refactoring.” This typically equates to slow start times and high memory requirements.

So, what will the future bring? Expect smaller and faster Wasm to elbow out containers for an increasing number of greenfield applications. But replacing the existing container ecosystem wholesale? That seems far-fetched. Both Wasm and containers promise to play prominent roles in cloud and enterprise computing for years to come.