Vasyl’s Dev Notes

WebAssembly is not just about the Web, and it has nothing to do with traditional assembly language. Yet lately, you might have heard people saying that WebAssembly (WASM) could replace containers and tools like Docker and Kubernetes. How did we get here? Is it just hype, or should we really consider retiring Docker for this new technology? I have dive into articles, papers, talks, and hands-on experiments to answer that question. By the end of this article, you will understand what WebAssembly is good for today — and whether it is ready to replace Docker.

A Brief History of WebAssembly

To see why WebAssembly has people so excited, let’s start with a bit of history. WebAssembly’s story actually begins over a decade ago with asm.js — a project by Mozilla to speed up JavaScript. Asm.js was essentially a “small language” — a highly optimizable subset of JavaScript that could be generated by a compiler (like Emscripten, which compiled C/C++ code into JavaScript) . In the early 2010s, asm.js let developers run near-native code (like game engines, image processing, etc.) inside browsers by squeezing as much performance as possible out of JavaScript. It was impressive: developers ported old DOS games, the Unreal and Unity game engines, SQLite databases, and more to run in Firefox or Chrome via asm.js.

(My favorite ones are https://lrusso.github.io/Quake3/Quake3.htm and https://lrusso.github.io/VirtualXP/VirtualXP.htm)

However, asm.js was still JavaScript, just written in a very peculiar way. The industry had seen similar attempts to bring native code to the browser (Java applets, Flash, ActiveX) and knew the pitfalls — often these plugins led to security nightmares. WebAssembly (Wasm) was designed to overcome those issues by starting from a clean slate. Rather than outputting quirky JavaScript, compilers could target a new bytecode format — a low-level, efficient binary instruction set — i.e., WebAssembly. WebAssembly runs on a virtual CPU that is the same everywhere, making it portable and sandboxed by design . You compile your code (C, C++, Rust, etc.) to this binary format once, and it can run on any device or OS that has a Wasm runtime, with no changes. In a way, it’s “write once, run anywhere” (just like Java promised), but with a much smaller, faster runtime and a focus on security.

WebAssembly was first announced in 2015 and became a W3C standard by 2019 . All major browsers shipped support by 2017. But importantly, WebAssembly isn’t confined to browsers. Its design — a compact, fast, and safe executable format — turned out to be useful on servers, in cloud environments, and even on tiny devices. This is where the comparison to Docker containers comes in, which we’ll explore soon.

Why Are People Comparing Wasm to Docker?

Docker popularized the idea of containers — lightweight, portable packages that bundle an application with everything it needs to run (system libraries, runtime, etc.), isolated from other apps. Containers revolutionized how we deploy software, making it easy to move applications across environments. So why do some folks say WebAssembly is “like Docker without the container”?

The short answer: WebAssembly can provide a sandboxed, portable way to run code, similar to containers, but with even less overhead. A WebAssembly module is essentially an app compiled to a universal binary. It runs in a sandbox that’s locked down by default — it can’t access anything on the host system unless explicitly allowed. In the browser, this means a Wasm program can’t access your disk or network unless the JavaScript environment permits it. Outside the browser, WebAssembly runtimes similarly ensure a Wasm module only does what it’s allowed to (for example, a runtime might let a module read a certain file but nothing else). This sounds a lot like what containers aim to do — isolate applications for security. WebAssembly just takes it to the next level by isolating at the language/runtime level and not needing a full operating system inside the sandbox.

Another reason is performance. Containers are pretty fast and lightweight compared to virtual machines, but you still need to boot up at least a minimal OS environment for each container. WebAssembly modules, by contrast, can start near-instantly. Wasm bytecode is designed to load and start quickly — in fact, a browser can start running a Wasm module while it’s still downloading (known as streaming compilation) so it doesn’t even wait for the whole file. The startup latency is measured in milliseconds or less, often microseconds , which is much better than even a lightweight container that might take hundreds of milliseconds to initialize. This makes WebAssembly attractive for serverless computing or handling bursts of tiny tasks where you need to spin up work on demand and handle it immediately.

Finally, WebAssembly offers programming language flexibility (polyglot support). Container images typically package apps written in one language (whatever is installed inside). With Wasm, you can compile many different languages to the same Wasm format. In theory, you could have services or plugins written in C, Rust, Python, or Go all compiled to Wasm and running together in the same runtime environment. This opens up new possibilities for building systems where components are written in different languages but run in one unified sandbox.

It’s no wonder Solomon Hykes (founder of Docker) famously said: “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing.”

That bold statement got people asking: is WebAssembly going to replace Docker? Before we jump to conclusions, let’s look at what WebAssembly can do today and its key strengths.

Key Advantages of WebAssembly (Wasm)

To understand where WebAssembly might shine compers, let’s break down its core adventages:

• Fast Startup and Performance: WebAssembly code executes at near-native speed, thanks to just-in-time (JIT) or ahead-of-time compilation in the runtime. There’s no heavy OS boot-up when launching a Wasm module — no “cold start” delay like you have with VMs or even container initialization. This makes it ideal for handling lots of short-lived tasks or scaling up demand quickly. If you send 1000 requests that each need a small sandboxed function to run, a WebAssembly runtime can start a fresh instance for each request with negligible overhead in microseconds, whereas spinning up 1000 container instances would be much slower.
• Security Sandbox by Default: WebAssembly was designed with a “deny by default” philosophy. A Wasm module can’t do anything outside its own memory and compute unless the host environment gives it access. This sandbox is enforced at the bytecode level and the runtime’s memory safety checks. Bugs like buffer overflows don’t lead to arbitrary code execution on the host — they just trap inside the VM. The security model is further enhanced by a capability system: the host can pass in specific interfaces or resources. For example, if a Wasm module needs to read a file or make a network request, it must call a host-provided function — it can’t just open “/etc/passwd” on its own. This fine-grained control can make the WebAssembly environment very secure, potentially more locked-down than a typical container which might accidentally include more filesystem or network access than intended.
• Portability: A WebAssembly binary (a .wasm file) is CPU-agnostic and OS-agnostic. It will run the same in a Linux server, a Windows loptop, or ARM IoT device, as long as there’s a Wasm runtime for that platform. Containers, on the other hand, package OS-specific binaries — a Docker image for Linux won’t run on Windows or vise versa without special compatibility layers. With Wasm, you do not need separate build pipelines for different CPU architectures; one .wasm could truly run anywhere (in practice, there are some runtime differences, but the goal is real cross-platform portability).
• Efficiency and Footprint: WebAssembly modules are typically very small in size (it’s a compact binary format) and require minimal resources to run. A Wasm runtime (like Wasmtime, Wasmer, or WAVM) can be a few megabytes of memory or even less for stripped-down versions, and modules themselves can run with a tight memory budget. There’s no need to ship a whole OS or dozens of packages with each instance. This is why Wasm is being explored for IoT and embedded scenarios — it can run on microcontrollers with limited RAM and CPU, where even a slim Linux container is too heavy.
• Language Flexibility (Polyglot): As mentioned, you can compile 40+ languages to WebAssembly . Engineers can write code in the language they prefer (C, C++, Rust, Go, Python, Zig, Ruby, etc.), compile to Wasm, and it can all run in the same sandbox environment. This is powerful for plugin systems (we’ll discuss soon) because it means you could let third parties extend your app using their language of choice, but you run all the extensions through a Wasm runtime for safety. It’s also useful for reusing legacy code — e.g., you could compile a 20-year-old C++ image processing library to Wasm and use it in a modern web service without having to wrap it in a microservice or container.

In summary, WebAssembly brings together a lot of what we want: speed, safety, small footprint, and portability. No wonder people are asking if it’s the “next container”. But let’s ground ourselves by looking at how Wasm is actually being used today, and where it makes sense.

How WebAssembly Is Being Used Today

1. Edge Computing and Serverless Functions: One of the first non-browser adopters of Wasm was Cloudflare, which in 2017 started using WebAssembly in their Cloudflare Workers — a platform for running small functions at the edge of the network . Normally, Cloudflare Workers were written in JavaScript, but JS can be slow for CPU-heavy tasks. WebAssembly’s fast startup and sandbox made it a perfect fit for things like on-the-fly image resizing or computing custom logic on incoming HTTP requests . With Wasm, Cloudflare could safely run user-provided code on their edge servers with minimal overhead. Fastly, another content delivery network, did something similar by creating their own Wasm runtime (named Lucet) for edge computing tasks .

In the same vein, API Gateways and proxies have embraced Wasm. Companies realized they could let users customize request handling (auth, routing, filtering) by running Wasm modules right inside the gateway. For example, Envoy Proxy (commonly used in service mesh architectures like Istio) supports Wasm modules as filters . This means you can write custom logic in a language of your choice, compile to Wasm, and plug it into Envoy to manipulate HTTP requests — all without risking a crash or compromise of the proxy, since the Wasm runs isolated. Even traditional hardware companies took note: F5 (known for load balancers) acquired a startup called Suborbital that was focused on server-side WebAssembly for extending gateway logic . The selling point across these use cases is performance + isolation. WebAssembly modules start fast enough to potentially handle each request in a fresh sandbox (scaling to zero when not in use) , and they can’t interfere with the host beyond their allowed capabilities — ideal for multi-tenant platforms.

2. IoT and Embedded Devices: On the opposite end of the spectrum from cloud servers, WebAssembly is making waves in tiny IoT devices. Why? Many IoT devices are too small to run a full Linux OS required for Docker containers — you can’t exactly run a Docker Engine on a $5 microcontroller. But these devices can run a slim Wasm runtime. Projects like the WebAssembly Micro Runtime (WAMR) by the Bytecode Alliance and Wasm3 (an ultra-light interpreter) allow devices with only a few hundred kilobytes of memory to execute Wasm modules . This means you could write your IoT application logic in, say, C or Rust, compile it to Wasm, and deploy the same .wasm binary to many different kinds of hardware — whether it’s an ARM Cortex-M chip or an x86 processor — as long as they have a Wasm runtime. It’s a bit analogous to how Java was used in mobile devices with Java ME, but here it’s leaner and with multi-language support.

For IoT developers, WebAssembly promises: no more cross-compiling for each device architecture, and safer execution (a buggy module can’t crash the whole device easily). Imagine updating the firmware of a sensor by just swapping out a Wasm module, rather than reflashing a whole image — the risk of “bricking” the device is lower. While this is still early-stage, it’s a very exciting area. (Of course, containers can’t really even compete here, since they simply can’t run on such small bare-metal devices without an OS.)

3. Plugins and Extensibility in Applications: One of the coolest emerging uses for Wasm is as a universal plugin system. Traditionally, if you wanted to let users extend your application (say, a game or an editor), you might embed a scripting language like Lua or JavaScript and have users write scripts. But not everyone likes those languages, and they can have performance limitations. WebAssembly offers a way to let plugins be written in any language (that compiles to Wasm) and run safely. There are frameworks like Extism that make this easier — Extism is essentially a library you can embed in your app to load Wasm plugin modules and call functions in them. It supports 10+ host languages (so your main app could be in Python, Go, Ruby, etc.) and dozens of guest languages for plugins . For example, a host application written in Go could use a plugin written in Rust via Extism, or a C# app could use a plugin written in Zig — it’s incredibly flexible.

Why not just use containers for plugins? Imagine every small plugin running as a separate Docker container — that would be overkill in most cases, and communicating between the main app and plugin would be complex (usually via network calls). With Wasm, the plugin runs in-process with the host (but sandboxed), and you can call functions directly. This in-process extension model is super powerful. We already see it in things like browser extensions (which could use Wasm under the hood) and even database extensions — there’s work on using Wasm for things like PostgreSQL stored procedures, so you can write a DB function in your language of choice and have it run safely in the database process .

All these use cases show that WebAssembly is not just theoretical — it’s being used in production for specific scenarios: ultra-fast edge functions, safe customization of networking, cross-platform IoT apps, and plugin ecosystems.

Now, given these strengths and uses, can it really replace containers?

Can WebAssembly Really Replace Containers?

The honest answer: Not entirely, and not yet. WebAssembly is fantastic for certain things, but Docker containers solve some problems that Wasm doesn’t fully address.

First, WebAssembly currently is best suited for applications or components that fit within its sandboxed model. If your app needs full access to the underlying OS — for example, it wants to open arbitrary sockets, bind to low-level network interfaces, access the GPU, or use special hardware instructions — a WebAssembly module might not be able to do all that (or you’d have to wire up a lot of host APIs). Containers, on the other hand, basically are OS instances; they can do almost anything a host can do (just namespaced and isolated). So for a complex microservice that relies on, say, a specific kernel feature or expects a certain file system layout, running in a container might be easier than porting to WebAssembly.

However, the gap is closing. Projects like WASI (WebAssembly System Interface) aim to provide standardized capabilities (files, networking, etc.) to Wasm modules in a portable way. This is like defining a “virtual OS” interface for WebAssembly. It’s still maturing — not all system calls or features are available yet — but it’s making progress. The Docker ecosystem is actually embracing this: Docker now has preliminary support for running Wasm modules alongside containers. For example, you can use docker run to run a .wasm module (using a Wasm runtime under the hood) — treating Wasm modules almost as lightweight containers. In fact, there’s an OCI (Open Container Initiative) specification for distributing Wasm modules, so you can publish Wasm images to container registries like Docker Hub and run them with containerd. This suggests a future where Docker isn’t replaced by Wasm, but rather Docker becomes a management tool for both containers and WebAssembly modules working together.

There are also limitations to consider: WebAssembly is stateless by default — a module runs, does its thing, and if you spin up another instance later, it doesn’t remember anything (unless you provide some state mechanism). Containerized services, on the other hand, often maintain state (databases in containers, etc.). Also, many existing applications are written with the assumption of running on an OS with certain libraries. Not everything can be trivially compiled to Wasm (for instance, software that depends on glibc Linux system calls might need adjustments to work with WASI). So there’s a lot of existing software that would need adaptations to run under WebAssembly, whereas it can be containerized as-is.

Moreover, while WebAssembly excels at the finer-grained end of running functions or small programs, containers are still very convenient for packaging whole applications (including their OS-level dependencies). If you have a Python web app, containerizing it with its virtual environment and OS packages is straightforward. To run that in WebAssembly, you’d likely need a WebAssembly Python runtime and then deal with all Python libs that might not compile to Wasm easily — not an easy task today.

Industry perspective: It’s telling that experts view Wasm and containers as complementary. Brendan Burns (co-founder of Kubernetes) and others have said they foresee Kubernetes eventually scheduling WebAssembly modules just like it schedules containers — not replacing one with the other, but using the best tool for each job. Containers might run your main services, while Wasm might be used for extension points or ultra-portable plugins inside those services. Solomon Hykes himself clarified: “Will Wasm replace Docker? No. But imagine a future where Docker runs Linux containers, Windows containers, and Wasm containers side by side.” In other words, Docker could evolve to support Wasm as a first-class citizen .

As of now, WebAssembly is ready to supplement or enhance the container ecosystem, rather than outright replace it. It shines in scenarios where you need extreme portability, fast startup, and safety — running untrusted code, scaling ephemeral tasks, supporting multiple languages in one runtime. Docker containers remain extremely useful for running long-lived services, leveraging decades of POSIX-compatible libraries, and packaging entire apps that expect an OS.

Final Thoughts

WebAssembly is often called “the future of computing” by its proponents, and in many ways it does feel like a natural evolution. It takes the sandboxing and isolation ideas of containers to a more granular level (down to the function or library), and it brings the write-once-run-anywhere ideal closer to reality by abstracting away even the operating system differences. Wasm is here to stay, and its role is growing beyond the browser — from cloud to edge to IoT.

However, it’s not a silver bullet. Docker and containers solved a very real problem of packaging and shipping software, and they won’t vanish overnight. Think of WebAssembly as another tool in our toolbox. For certain new applications, especially cloud services where you want to allow user-defined code or need super fast spin-up, designing with Wasm in mind could give you huge benefits. For existing applications that happily run in containers, there’s little reason to rewrite them for Wasm (unless you have a specific need).

In the coming years, we’ll likely see a hybrid landscape: Kubernetes clusters running some traditional containers and some WebAssembly workloads; edge networks running Wasm for quick functions; IoT devices running Wasm for modular updates; and plugin systems using Wasm to let developers in different languages extend apps. The story-driven hype around “Wasm vs Docker” will mature into a practical understanding: use Docker containers when you need a full OS environment or have legacy apps, use WebAssembly when you need lightweight safe extension and speed.

So, is WebAssembly ready to replace Docker? Not exactly — but it might be ready to replace some uses of Docker. It’s more accurate to say WebAssembly will coexist with and complement containers. They address overlapping but not identical concerns. As a developer or tech enthusiast, it’s an exciting time to experiment with WebAssembly — try packaging one of your services as a Wasm module, or using Wasm for a plugin, and see how it compares. Keep an eye on projects like WASI, WasmEdge, Wasmtime, and how Docker and Kubernetes incorporate Wasm. The ecosystem is evolving fast (as of 2025, even Microsoft and Cloudflare are heavily involved in Wasm proposals).

In the end, adopting any new technology should be driven by the problems you need to solve. WebAssembly brings some powerful solutions to the table, and in some cases it will indeed cut down our reliance on containerization. But Docker isn’t suddenly obsolete — it’s a mature and stable tool that still plays a critical role. The future is likely WebAssembly and Docker, together, making our platforms more flexible and powerful than ever.