You've shown that wasm solves a sandboxing/security concern that containers don't.
But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success.
I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be.
The various wasm runtimes already offer an array of low level threading and networking capabilities. Higher level services like http servers can be provided by runtimes with very optimized native backends, that have excellent performance characteristics but still "appear" as regular wasm. There may be niche long term users of containers for these reasons, but it's unclear to me that the systems programming capabilities will be much of a moat for containers: if anything, I think we'll see wasm implementations competing to provide the fastest performance for the same well specified interfaces in a hot war competition.
The main counter-factor against wasm that I see is just interia. Change is slow. These runtimes are still early. Wasm language targets have been around for a while but at various quality/polish levels. Wasm components are still effectively brand new, a year and a month after release, and the specs are still undergoing major updates to figure out how exactly async is going to work & there's very few runtimes keeping pace with this radical upshift. Its happening & I believe in wasm, but this is a long change and the capabilities aren't really truly here yet.
Docker-like containers will likely exists as long as there linux servers, maybe the trendiness will leave them behind, but they are a plainly good technology to deploy and distribute application with many fantastic usecases.
I too do see a future where Wasm is way more widespread but as of now we are deploying a small app with a MySQL in single docker container. I suspect that we won't be running MySQL compiled to a Wasm container anytime soon*
* I suspect that we could with the right transpilations/interpreters but for sure we won't
But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success.
I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be.
The various wasm runtimes already offer an array of low level threading and networking capabilities. Higher level services like http servers can be provided by runtimes with very optimized native backends, that have excellent performance characteristics but still "appear" as regular wasm. There may be niche long term users of containers for these reasons, but it's unclear to me that the systems programming capabilities will be much of a moat for containers: if anything, I think we'll see wasm implementations competing to provide the fastest performance for the same well specified interfaces in a hot war competition.
The main counter-factor against wasm that I see is just interia. Change is slow. These runtimes are still early. Wasm language targets have been around for a while but at various quality/polish levels. Wasm components are still effectively brand new, a year and a month after release, and the specs are still undergoing major updates to figure out how exactly async is going to work & there's very few runtimes keeping pace with this radical upshift. Its happening & I believe in wasm, but this is a long change and the capabilities aren't really truly here yet.