> OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen.
It's _not_ a requirement, but at least to me it seems like a pretty good _possible_ solution.
I sense you're pretty jaded about web development, and I get that, but I don't agree this is "web people" trying to do things outside the browser, but rather I see it more as "systems people" trying to bring _some_ order to the chaos.
> nearly all developers are terrible at thinking about preventing security vulnerabilities
I totally agree. Which is why you should have a solid abstraction between the sandboxed code and what it's allowed to do, which WASM seems particularly good at (by only exposing services as syscalls). In theory, sandbox escapes in WASM should be the same level of difficulty as modern kernel exploits, so still _possible_ but _pretty hard_. And if multiple runtimes are using WASM for different things, if one is exploited it can be a learning lesson for all the other WASM runtimes, vs. the bespoke scenario where each custom VM has to go through the security bug discovery process by itself.
If _think_ what you're against is some sort of future where a "WASM-based-Electron" becomes the de facto standard for modern apps, and _that_ I largely agree with. In fact, re-reading the WASI standard I do feel like they are already "baking in" too much w/ WASI-core; I was expecting the core to just focus on a simple syscall ABI, not to include syscalls like filesystem reads and writes.
Some maybe what I'm really looking for is a "wasi-minium-abi" that just standardizes _how_ syscalls are made without actually standardizing any actual syscall numbers.
In summary, I feel like syscalls are a _very_ tried and true way to specify the API/ABI for a runtime, and that I hope we see more runtimes use WASM and a syscall ABI vs. rolling their own VM, but I agree that I'm in no rush to see WASM/WASI become the "Electron 2.0" of local app deployment.