Containers have two goals: reproducibility/portability, and encapsulation. WASM could replace the reproducibility but it can't replace the encapsulation.
> My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.)
Luckily a container is a place that can spin up a V8 engine. If you want to bet on WASM my bet would be on containers running WASM.
Can you explain your thoughts here? WebAssembly is sandboxed and effort must be expended to provide a mechanism for getting data through that boundary. How does that differ from “encapsulation?”
I'm referring to a different kind of encapsulation. Dependencies, tools, version management, configurations, environment variables, etc. Even if you can fully compile your code into WASM and host it on V8 you need to ship it with configuration files, set specific environment variables and so on. Containers allow you to bundle all of that together into a single unit you can share with others.
Note that it is possible to ship containers with configuration files and environment variables. Because Wasm imports can be virtualized (i.e.you could choose to fulfill a file-fetching interface completely or partially by composing two components together), it is possible to build a WebAssembly binary with what you need bundled.
Also, just because you could does not mean you should -- most of the time you don't want to inject environment variables or configurations that could contain secrets until runtime.
> My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.)
Luckily a container is a place that can spin up a V8 engine. If you want to bet on WASM my bet would be on containers running WASM.