First: wasm is the perfect plug-in language, as it provides a high level of isolation and therefore security for the host app.
Second: the promise of wasm is that you can write it in any language. I think this is compelling for any application that seeks for extensibility.
Wether all this is worth the effort is probably the actual question. Maybe we will be surprised by killer plugins that wouldn’t be possible with regular plug-in systems…
> Maybe we will be surprised by killer plugins that wouldn’t be possible with regular plug-in systems…
It's less "this wouldn't be possible" and more the fact that the existence of plugins that are sandboxed and access-permissioned makes me far more likely to seek out and install plugins in the first place, since it lowers the trust barrier. It's the same reason why I browse random websites freely while also being loathe to install random binaries on my computer. Being language-agnostic is just icing on the cake.
You might be missing the fact that WASM nowadays doesn't necessarily have anything to do with web browsers. It was initially designed for running in web browsers, but in the last few years there's been a lot of activity surrounding embedding WASM runtimes in processes other than web browsers. Mostly the idea is for it to be a way to execute untrusted / customer code (e.g. "plugins") with sophisticated sandboxing, etc.
Wasm has the promise to be a single target for your plugins that could be written in node/rust/python and the consumer won't have to have that specific version of python installed. That and the possibility to sandbox a plugin so my repl function can't also upload my ssh keys would be nice.
WASM doesn't mean this has to be true, but it could be.
It's both dynamically loadable & doesn't require any external dependencies. Each WASM container has its own heap, so you don't need e.g. glibc versions to be the same, which is otherwise a PITA for plugins.
