You might be thinking that container is similar to a VM, but it is not. WebAssembly is suppose to be something akin to a universal “web ISA” (Instruction set architecture with its own assembly instructions, thus, “WebAssembly”) which all modern browsers support. This means that technically, one is able to compile a binary once and run anywhere, something that is not entirely possible with containers.

Since you're asking for WASM in general.

How do you run a Python program using docker in the browser?

How do you run a Ruby function from a Scala library with docker?

Containers take seconds to start so a container must always be running. Wasm starts in microseconds and most Wasm platforms scale to zero by default because they do not suffer from cold starts.

Wasm also offers incredible density characteristics. The same application hosted in a container has a much larger footprint than the Wasm equivalent, ~hundreds of MBs to GBs compared to a typical Wasm app that is typically <10MBs and often KBs. Wasm is based around a linear memory model such that it supports binpacking by the runtime. Where a system may be able to run hundreds of containers, thousands of Wasm instances can be run by a single Wasm runtime.

The typical cost savings for using a Wasm-based serverless platform vs a container-based one is significant. This is dependent on the language and workload, but I generally expect +30% efficiency.

Containers are not secure by default and are generally not considered an appropriate sandbox. Wasm was designed to run in the web where sandboxability is a critical requirement and first principle of the design. For serverless, this means a single Wasm host may be multi-tenant. This is why Fastly, Shopify, and Cloudflare use Wasm for serverless workloads ($$$ + safety).

On the magic box concern, Wasm is pretty different from the other serverless approaches (isolates, BEAM, JVM-based, etc) that can be a bit more “magical”. A Wasm component can be inspected prior to compilation, the binary itself is a declarative definition of the capabilities needed to run as function imports. Those imports are standardized via WASI. This is one of several reasons why a Wasm binary is more portable than a container where it can run on any CPU architecture, operating system, and environment with different capabilities.

From a local development perspective, it’s so much easier to use a Wasm component that uses interfaces like the blobstore. For development I can use implementations I have in my local dev environment, e.g. a local FS, but in production I can use the same abstraction to connect to S3. This gives you serverless without requiring the entire services stack.