> Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent process
This sounds like J2EE application servers for WASM instead of Java byte code.
It's exactly what it is, except there is also a browser implementation without plugin. Which also means that WASM/WASI is not a total replacement for containers: just like there as JVM image there will be WASI images. The argument of size given in the article isn't very convincing, when images like Alpine exist.
The problem addressed in the post is more about getting around Rust slow build time than phasing out containers. There's a lot of buzzwords (WASM, Rust, Cloud, etc.) but at the end of the day nothing that isn't easy to do with a modern "boring" stack like .NET.
The model they describe is pretty much exactly how .NET Azure Functions works. (which is however currently switching to a slightly different hosting model)
> The argument of size given in the article isn't very convincing, when images like Alpine exist
For a lot of uses you can go even smaller than Alpine. Static executables for example don't require standard Linux tools to operate. I expect WASI would be similar. Just drop the runtime and your Wasm files into a scratch container.
True. A static executable doesn't even need Linux in the first place, that can be done with a unikernel. It's a tradeoff about familiarity, size, performance, documentation and technical level.
This sounds like J2EE application servers for WASM instead of Java byte code.