4 ms·

Why do terminal applications need a WASM runtime? I feel like I'm not really understanding something fundamental about WASM.

voigt 3y ago
I do understand why people try this approach: 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…
- kibwen 3y ago
  > 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.
Already__Taken 3y ago
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.
baq 3y ago
Terminal is just UI. It’s completely orthogonal to WASM.
da39a3ee 3y ago
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.
aidenn0 3y ago
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.

voigt 3y ago

I do understand why people try this approach: 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…

kibwen 3y ago
> 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.

Already__Taken 3y ago

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.

baq 3y ago

Terminal is just UI. It’s completely orthogonal to WASM.

da39a3ee 3y ago

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.

aidenn0 3y ago

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.