There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too).
There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries.
But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
One thing I've seen come up a lot is that people got used to treating containers as a portable unit of code, and then Apple Silicon threw a wrench in that assumption. A WASM module is the same regardless of whether you're running it on arm, amd, or anything. (Alas, the cost of this portability is that it's 32-bit)
Wasm = just a bunch of bytecode executing in a VM / a sandbox. Even with JIT, it will still be slower than the native code.
And since it is a sandbox.. either you, or your friendly wasm interpreter (via. wasi etc...) needs to provide the system access APIs for various things like storage/filesystem access, hardware acceleration via. GPU, TPU etc.. And some of the standard APIs we take for granted.
Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.
That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation.
And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.
