That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions rather than full apps, although that is changing quickly.)
What you can however, is build apps for Wasm (or apps that combine Wasm and containers) with the same ease you currently enjoy when building pure container apps, i.e. see my comment above [0]
I think what's missing is why you'd want to do that.
If I have a rust app on a scratch image, why would I want to turn it into a wasm container?
My assumption is because wasm can run on multiple platforms (x86 and arm) so one image supports both, is that correct? Are there other reasons not as obvious?
Assuming you had code that somehow could either be packaged as a linux container, or as a Wasm binary, then the advantage of the latter would be that yes Wasm supports multiple CPU architectures out of the box, it also consumes less resources (memory, etc.), will usually have faster start times, and the Wasm security sandboxing is stronger.
Really? I would not have expected that. Is that just under the assumption that most apps have an underlying OS (like alpine) and aren't on a scratch container?
What you can however, is build apps for Wasm (or apps that combine Wasm and containers) with the same ease you currently enjoy when building pure container apps, i.e. see my comment above [0]
[0]: https://news.ycombinator.com/item?id=33324093