I think native compiled code is hard for plugin distributions. You'll need to target 3 main platforms Linux/macOS/Windows. You can use github actions to do it, but it would be so easier to just compile to WASI and that's it.

Also, WASI is compelling to me because of the potential of writing plugins in different programming languages.

> WASI is compelling to me because of the potential of writing plugins in different programming languages

I think this is the future really, I've been pining for this to become a thing for so long.

I think WASI is an excellent idea. Do you know how the ABI works?

multiply that with the CPU ISA, like arm, x86 (and more if you are inclined to support power, sparc, ...)

Webassembly makes a lot of sense for plugins.

* sandboxing, so plugins don't need to be as trusted

* Easy cross-platform distribution with a single build artifact

* plenty fast (if written in a language like Rust/C++ and paired with a good runtime)

Apologies for lack of my lack of knowledge in this area, but...

Why don't plugins "need to be as trusted"? Obviously bad-actor plugins would be less effective and capable of inflicting any sort of attack on your development OS, but surely the development environment is the perfect vector for attacking the runtime environments that run your artifacts get deployed into?

Not to mention the potential for secrets-harvesting due to sloppy boot-strapping dev-env habits or other bad habits we often engage in during the early development process?

Or does WASI somehow provide protection from these issues?

It's all about reduction of surface and giving plugins access to the least amount of info. You expect a linter to only have (read) access to the code it lints. It shouldn't be able to modify files, it shouldn't have network access etc. WASI has a pluggable capability-based security system.

Some advanced linters might want network access but you can show this to the user, so they can make an informed decision about whether to trust that linter and their author with this power.

This isn't airtight security to protect against obviously-malicious authors. This is about creating a system that can deal with the reality that "trust" in an app store entails "a million shades of gray". I might trust a plugin enough to check for errors in my code, but not enough to actually modify my code.

> You expect a linter to only have (read) access to the code it lints. It shouldn't be able to modify files, it shouldn't have network access etc. WASI has a pluggable capability-based security system.

That sounds absolutely amazing. Are there any desktop apps delivered like this yet? Any operating systems or some sort of runtimes (browsers?) that support them?

I want to install apps on my desktop without worrying about it too much. Sadly currently restricted to PWAs.

> Are there any desktop apps delivered like this yet? Any operating systems or some sort of runtimes (browsers?) that support them?

Ever heard of apparmor?

That's per application security profiles, distributed with any applications on many Linux distributions.

firejails on linux as well. there are others but that's the only one I'm familiar with.

Thanks for taking the time to explain. I guess I was pretty ignorant in thinking that a plugin basically has all access to the dev-env it's written in.

I hadn't really heard of WASI, let alone understand it, but it totally makes sense why you would want to leverage this approach, along with any IDE-specific plugin interfaces/integrations.

The clue is in the first part of the GPs sentence which you latched onto: “sandboxing”.

The code is running inside a virtual machine rather than natively on the host.

No, I got that. I understand how the host is protected, but didn't understand how everything inside the "VM" was protected... @galgalesh answers that above.

I wanted to clarify the cross-platform point:

WASM + WASI means a single binary has near-native performance, but can run on any CPU architecture and any OS.

To be even more specific: Webassembly is an abstract stack machine. There are no binary executables. You distribute the code in either the text or binary (`.wasm`) format, which is then executed by a runtime.

The runtime can be an interpreter or a (JIT) compiler. The latter can get you relatively close to native performance.

not OP, but i think it makes sense. there isn't that much of a speed difference and you get free sandboxing, some memory safety, a ton of supported languages and more.

i don't know anything about WASI, but it probably solves the problem of having to interface with different native compiled code ABIs.

Either the plugin needs to be written in a common language (JS for VSCode, Python for Sublime Text) or native (Terraform does this for custom providers) but need to support many architectures.

WASI fits snuggly in between, being a common intermediate language

But JS _is_ a common intermediate Language. I guess more languages compile to JS than to WASM.

WASM actually started life as a subset of Javascript called asm.js. Code in other languages was compiled to this subset of Javascript so they could execute in the browser. Once that proved useful, they decided to skip the Javascript step and agree on a binary format that browsers could execute directly. That's WASM.

From https://en.wikipedia.org/wiki/Asm.js

> asm.js consists of a strict subset of JavaScript, to which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM).[2] Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.

> asm.js is mostly rendered obsolete with the introduction of WebAssembly (wasm), which has a bytecode format that is faster to parse. Efforts to extend JavaScript with more low-level features like SIMD.js has also been suspended since 2017. asm.js remains useful primarily as a "fallback" for wasm

It can used as an intermediate language, and since it was the only way to run code on the browser without plugins before WASM, it happened a lot.

But nowadays WASM is much more suitable for the job. JavaScript was designed as a scripting language, not a low level intermediary language.