The big benefits:
* Much easier deployment. All you need is a small .wasm file, usually hosted in a registry similar to Docker. No need for messing with cumbersome Docker files. No need for tooling that audits Docker images for vulnerabilities. No huge image downloads for each service.
* Language interop. Progress is slow, but interface types [1] will soon provide a standardized way for type-safe abstract interfaces between Webassembly instances. This makes cross-language interop seamless and very efficient.
* Much smaller applications. You can move expensive dependencies like http servers/clients, database clients, etc into the runtime and let the environment provide those. This leads to way fewer dependencies, so you don't need to constantly update your apps and aren't harassed by Dependabot PRs. More importantly: smaller attack surface and less opportunity for compromises.
* Security. Webassembly is sandboxed and has a much smaller attack surface than a whole operating system syscall sandboxing layer (aka Docker et al). Wasm also naturally lends itself to capability based security with handles that are passed around, so you can even scope permissions inside your application code. (hint: reference types)
* Easier local development. It's much easier and quicker to download and start 100 small .wasm based services than it is with (often large) Docker images / Kubernetes setups.
* Quasi-instant startup (after the wasm is compiled, or with an interpreter)
* Less resource usage. It's relatively easy to freeze and persist Wasm instances to disk when they aren't used. Or do things like seamlessly migrate them between nodes. Or snapshot and resume them locally for debugging.
* In-browser usage: you can even just run the same code in your browser anytime you want. ( the runtime I'm working on can provide a mostly complete dev environment just in the browser, which works mostly identically to server deployments, excluding obvious deficiencies like no direct network or storage access)
---
Of course things aren't just rosy. Some downsides/risk factors:
* There are quite a few proposals that are crawling through the standardization process. (GC, more control over the stack, tail calls, interface types, WASI, multi threading, module linking, ...). Several of those would be really important especially for interpreted languages.
* Language support. Rust, C and C++ work. This is not so much the case for other languages. As mentioned above, the spec leaves a lot wanting for running interpreters, and few of the popular languages can be AOT compiled. There is a Spidermonkey WASM build that makes running JS feasible, but it's of course much slower than a regular JIT enabled v8.
* Tooling and ubiquity. WASM is basically the next iteration of serverless. And there are many areas where serverless is frowned upon. I feel like this is mostly a tooling problem though that can be solved by a good ecosystem and a powerful runtime.
---
All in all I do believe WASM has the potential to be a very prominent (and hopefully the preferred) way to deploy a lot of applications, eventually.
[1] https://github.com/WebAssembly/interface-types/blob/main/pro...