It's basically the same thing as using a language runtime vs using a generic container for Lambda, except WASM would be lower level (you would need to ship language runtime on top of WASM but that's probably order of magnitude less overhead than a container)
Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs, but I'd much rather deploy runtime/app code only.
That's because that's exactly what they are, and that's why this claim is weird. Containers do not solve the same problem as WASM. No one is going to be taking Postgres and compiling it to WASM. They're not going to do that for redis or memcached or any of the other innumerable services that live happily inside of a container and need low-level access to a Unix system.
We may very well find that WASM replaces containers as to go to for bundling a typical web app, especially one built with a compiled language rather than one that already has a runtime. But we will still use containers for the things that containers are good at.
Overall the timeline doesn't seem implausible to me.
Right now compiling to WASM is sort of the equivalent of "but will it run Doom?" People are doing it for everything, and it's a fun experiment to stretch WASM. I could see it being useful in making some things available in the browser that otherwise couldn't be. But that doesn't mean it's going to replace containers in their rightful place. It'll be another option, and unless you're trying to solve one of the few problems that WASM was designed to solve (like running in the browser), it will be the wrong one.
Realistically containers neither. DBs are infrastructure best left to PaaS or dedicated VMs you can provision/manage better.
These projects care far more about performance than they do about ease of compilation or even of installation, because they're compiled once and run trillions of times in performance sensitive contexts. As I noted in reply to a sibling, I could see it being useful to run in a browser as a sort of learning playground, but that is not how people are going to deal with their production DBs—the bottleneck represented by WASI is not going to be worth it.
Containers just add overhead for stuff like memcached and complicate database management.
The way I see it VM -> Containers -> WASM is a logical progression in the same direction from the perspective of deploying applications.
Bare metal, VM, and containers all "look the same", like from a UX perspective. Wasm does not.
Nobody is arguing that WASM today will replace containers - 2030 is a long time away in tech.
WASIX is POSIX :)
Lower overhead.
> clever hack to get existing apps packaged up and reduce the overhead of VMs
Yeah, exactly.