WebAssembly (WASM) is a compilation target for many programming languages – you can compile things like Go to WASM, Rust to WASM, Python to WASM, etc. It also provides an execution environment for these binaries, one that is memory-safe, sandboxes, and can optionally be run inside a browser.
WASM works both on the server-side (as a contained execution and common runtime target) and on the client-side (as an alternative to JavaScript for fat client applications in the browser).
The question: Will WASM be more successful serverside or clientside?
I believe clientside.
Serverside, WASM competes with Docker containers as a packaging and execution target. Containers are successful because they allow developers to package more of the runtime environment into the artifact – environment variables, a Linux filesystem, commands, and natively generated binaries that work the same inside and out of a container. WASM has none of this as a packaging format. As a runtime environment, containers have namespace isolation: user, process, network, mount, and IPC. While it's plausible that you can hook WASM into container orchestrators (see krustlet), I don't see enough of an improvement to change the status quo. Edge functions often use WASM runtimes for startup time, but I imagine lightweight VMs like Firecracker are a much better fit.
Clientside, WASM opens up new opportunities. You can run a Python interpreter or JavaScript in WASM in the browser. You can run an entire operating system in the browser. Here's Windows 2000. You can run machine learning inference on devices using Tensorflow.js. These are entirely new experiences that bring web compatibility to many programs. But, of course, the business model for clientside WASM isn't precisely clear and will need to be much different than traditional software.