[ryanschneider]

> 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.

[naikrovek]

I don't think that web technologies are going to be a good solution to anything that is not the web.

The web development community haven't even solved their own problem space very well; spreading to new problem spaces will likely not suit them as much as they believe it will.

[hutzlibu]

You should consider, that you just have a bias against "web people".

But this technologie comes not from javascript webprogrammers, but from browsermakers.

People who specialize in sandboxing, performance and portability since years. And they had to do this with javascript... and now they want a better foundation, BECAUSE of the flaws of javascript.

So I don't know if they will succeed making a better jvm either, but they certainly have the expertise that they might succeed.

[naikrovek]

I have no bias against "web people", I have a bias against using the wrong tool for the job.

This REEKS of developers who are psyched about WASM and want to create solutions where no problem exists.

If they want performant code outside of the browser, use any one of the 2-3 dozen languages that already do this! WHY is a new runtime, with the inevitable serious security issues that will be exposed throughout it's life, needed for this?