WebAssembly plugins system

[CBenoit]

Basically load .wasm files.

Capabilities:

• provide new commands,
• hook on events,
• call helix commands,
• access UI stuff…?

At first we could use a basic toml config file or CLI to feed .wasm files to the editor.

A way to configure permissions on a plugin basis could be investigated to use the sandboxing capabilities coming with WASM.
Example with wasmtime:

$ wasmtime --dir=. --dir=/tmp demo.wasm [args…]

(reference)

I think the biggest challenge is to get well-defined interfaces down but let's not fear to break it during early stages.

Later we could investigate embedding a wasm-based scripting language such as Grain or AssemblyScript.

Here are some references:

• [2020/04 (as of writting)] ActuallyUsingWasm, a good introduction to wasm and WASI + comparison between wasmtime and wasmer
• [2020/12 (as of writting)] WASI tutorial: WASI tutorial for wasmtime
• [2019/03] Standardizing WASI: A system interface to run WebAssembly outside the web: good article explaining WASI purpose.
• [2019/11] Announcing the Bytecode Alliance: Building a secure by default, composable future for WebAssembly: on the isolation system it provides
• [2021/06] How to make plugins system with Rust and WebAssembly
• zellij has a WASI-based plugins system (doc)

I'm willing to experiment soon

[archseer]

I think the most basic demo would be implementing one of the existing commands in such a way, e.g.

helix/helix-term/src/commands.rs

Lines 123 to 137 in 407b37c

	pub fn move_char_left(cx: &mut Context) {
	let count = cx.count;
	let (view, doc) = cx.current();
	let text = doc.text().slice(..);
	let selection = doc.selection(view.id).transform(|range| {
	movement::move_horizontally(
	text,
	range,
	Direction::Backward,
	count,
	false, /* extend */
	)
	});
	doc.set_selection(view.id, selection);
	}

It only depends on the Context, and it only uses functions from core (move_horizontally) without interacting with the UI. I think most of the primitives in core should be exposed (selection/range/transaction/etc) and we can have a subset of view exposed (retrieving a selection from a doc, applying transactions)

[archseer]

Mentioned on Matrix:

Re: wasm plugins, rich clipboard support would be a great demo and to that end, neovim/neovim#14706 "[RFC] Neoclip: multi-platform clipboard provider w/o extra dependencies" may be worth watching.

[buster-blue]

What benefit does this provide over binary plugins? Will plugins be able to access eachother's state (functions, variables etc.) in the same way that plugins programmed in a single language (e.g. emacs) are able to, or something else?

My bad if the answer is obvious btw. I'm not very familiar with WebAssembly or plugin architectures.

[kirawi]

What benefit does this provide over binary plugins? Will plugins be able to access eachother's state (functions, variables etc.) in the same way that plugins programmed in a single language (e.g. emacs) are able to, or something else?

My bad if the answer is obvious btw. I'm not very familiar with WebAssembly or plugin architectures.

I think this post explains it well. There's a lot of uncharted ground in regards to plugin systems, especially with sharing state, but you can see past discussion on this here.

[CBenoit]

@kirawi
Thank you for the link to Valoren, I missed that one

[matu3ba]

If you want to embed the wasm compiler with the binary or as library etc, I would advise against wasm due to slower speed and missing performance optimisations on many targets.

"Of course, wasm3 runs fine on aarch64, but at about 3% of native speed."

This benchmark shows very astonishingly the missing optimisations that luajit can do here using this lua libary.

Also it would be advisable to have execution time benchmarks of webassembly against all usable alternatives before making a decision (ie by listing some speed and platform compatibility requirements). Would be not very useful to end up with something significantly slower than neovim.

[kirawi]

If you want to embed the wasm compiler with the binary or as library etc, I would advise against wasm due to slower speed and missing performance optimisations on many targets.

"Of course, wasm3 runs fine on aarch64, but at about 3% of native speed."

This benchmark shows very astonishingly the missing optimisations that luajit can do here using this lua libary.

Also it would be advisable to have execution time benchmarks of webassembly against all usable alternatives before making a decision (ie by listing some speed and platform compatibility requirements).

The intention is to use wasmer or wasmtime which are both written in Rust, and are quite fast in the benchmarks. However, real-world use is not going to be accurately represented by benchmarks. If it wasn't fast, it wouldn't be used by Google or Figma to power some of their most resource-intensive client-side services, nor would it be able to power game engines on the web. (Here is a more complete list.)

Lua lacks multithreading, SIMD, and has a smaller ecosystem. It's a lot more convenient to enable users to opt for their favourite language rather than have them learn a separate language and its ecosystem. I can't speak on behalf of everyone, but I believe that most Rustaceans firmly agree with me, as many libraries have wasm as a compile target. I would say we collectively have a lot more experience with wasm as a whole.

[CBenoit]

We'll probably go with wasmtime and I can see in one of the benchmark you linked that performances are far from bad. By the way wasmtime has been supporting WASI for a while prior to the article publication date, but they don't mention it, so I assume they used old data from a previous benchmark,

Older versions of the following runtimes had been tested in the previous rounds: […]

Given that Cranelift code generator is still very young and already that good, I'm not too afraid. Furthermore performance tracking is a thing at the bytecodealliance.

Besides all the other good points made by @kirawi on performance, I really like the ecosystem argument which is the reason why we want to use WASM in the first place. Given that performance is probably good enough (or more than enough), the main focus should be on whether user/developer experience is good.

[syrusakbary]

Thanks for considering Wasmer! We are working on a set of benchmarks at the moment, we had two bugs that prevented Wasmer to shine in the one you showcased @CBenoit, but those are already solved in master.

Right now Wasmer is about 20~30% faster than the other runtimes when using the LLVM compiler!

In general, we recommend Cranelift if the compilation times need to be fast (that is mainly for development), and LLVM for production (similar to how Rust uses LLVM always to compile in release mode, and Cranelift as an experimental compiler for faster compilation times in debug mode) :)

[kirawi]

Thanks for considering Wasmer! We are working on a set of benchmarks at the moment, we had two bugs that prevented Wasmer to shine in the one you showcased @CBenoit, but those are already solved in master.

Right now Wasmer is about 20~30% faster than the other runtimes when using the LLVM compiler!

In general, we recommend Cranelift if the compilation times need to be fast (that is mainly for development), and LLVM for production (similar to how Rust uses LLVM always to compile in release mode, and Cranelift as an experimental compiler for faster compilation times in debug mode) :)

This is a question I've had for a while, but what is the main difference between wasmtime and wasmer? I can't recall exactly, but I believe they're targeting different use cases, correct?

[CBenoit]

Thank you @syrusakbary for your input!

This is a question I've had for a while, but what is the main difference between wasmtime and wasmer? I can't recall exactly, but I believe they're targeting different use cases, correct?

I'm interested in hearing more as well!

I was more in favor of wasmtime for the following reasons:

• backed by the @bytecodealliance
• @alexcrichton and other notable names from the Rust compiler and std lib team are working on it
• a single back-end is supported (Cranelift) so we can expect it to be well supported and maintained while supporting three back-ends (Singlepass, Cranelift and LLVM) sounds like a heavy task

On the other hand, wasmer:

• including dependencies, is less lines of code (on lib.rs: ~5.5–8.5MB for ~177K SLoC vs wasmtime with ~18MB for 417K SLoC), meaning we probably get faster compile time and a smaller hx binary without even using lto (we would need to actually see what we get in practice though),
• is used by Veloren
• is used by zellij
• (has Japanese documentation 😛 )

I'll also ask on Veloren's Discord why they decided to use wasmer to form a better opinion.

I also found this article published a few months ago:

• Wasmer has the best overall support compatibility with every programming language at super-speed
• Wasmtime is lightning-fast and compact, with good configurability but fewer languages supported
• Lucet is a specialized solution for running untrusted WebAssembly programs inside a larger application
• WAMR runs with a small footprint

[matu3ba]

@CBenoit @kirawi There are 2 mutual exclusive possible use cases for WASM for plugins, where one really wants to have a plugin manager: 1. shipped compiler or 2. hook into the repo build system and the used compiler to build the WASM libraries/binaries.

1. interpreted which one usually wants to ship a dedicated compiler (which is language-specific for performance => This is effectively a soft language-lockin as one wants to ship it with the editor and not bundle all compilers/programs that can emit WASM.

2. compiled (fastest) which can be completely independent, but requires support of 1. the build system and 2. distribution package managers etc to have the compilers installed. If the language does not support easy build system integration and there is no convention where to put stuff upstream, it does scale poorly (because the package manager of helix can not build stuff).

Solution 1. gives more of a "it always works" experience with the language that the compiler supports

Solution 2. gives more of a "its super fast", but needs some setup and might break. Unless you can use nix for 2. ie with flakes 2 is just painful due to 2.1 many distros not shipping all compilers or only specific versions and then you are stuck on one (ie not yet stable languages) and 2.2 you want to simplify build system stuff for plugin developers.

nix with flakes is the de-facto best solution for 2.1 (shipping compilers+libc(s)? and make sure they exist, are configured/build identically and up-to date enough for the plugin ecosystem).
For 2.2 nix flakes should work, but a convention how build commands/shell scripts are supposed to be called could also work (I am not sure how stable flakes are for that use case for all the build systems that exist).

Ask yourself which solution is better for the goals of the project helix or how you want to deal with the mess of 1. shipping compilers and 2. supporting the build systems of plugins.

[kirawi]

We won't be shipping a compiler, though? WASM is a compile target for Rust itself as wasm32-unknown-unknown, and other compilation methods use their own external tool (Wasmer and Wasmtime also provide their own) to compile it down to .wasm, which would be run by the WASM runtime. Languages like Python or Lua currently work by compiling their interpreters down to .wasm, but in the future they could be directly compiled down to .wasm once the WASM GC is standardized and implemented.

Did I understand you correctly?

[matu3ba]

@kirawi How does this change the problem, when the plugin is written in a language that the distribution doesnt ship a compiler (or super old/incompatible or slow libc etc) ?
The plugin then just doesnt work? Or works differently and the plugin author should deal with the mess of different compiler versions?

[kirawi]

No, it's just .wasm. The user doesn't need to download anything else other than that standalone .wasm output which is what the plugin actually is. Think of it as creating an executable, you don't need all the code and compiler stack to run the executable as an end-user, because the OS already has everything it needs to run the executable inside the executable itself. The executable in this case is .wasm, and the OS is the Wasm runtime. Wasm is completely language agnostic and is just bytecode.

[glyh]

@dead10ck Isn't it already happening? @archseer is implementing a scheme on rust.

[noor-tg]

@dead10ck Isn't it already happening? @archseer is implementing a scheme on rust.

is there any repository or pull request to track what is done and what is not ?

[noor-tg]

did any one check nushell plugins ?
they use simple file conventions . with JSON-RPC protocol.

[devanlooches]

Just putting lapce out there.
Its an editor in rust and uses WASI plugins already.

[stappersg]

Just putting lapce out there. Its an editor in rust and uses WASI plugins already.

From that webpage: "Vim users, we've got you covered! Built-in support for a Vim like editing experience, without a plugin."

[devanlooches]

Correct, it supports Vim keybindings without a plugin, but it also supports WASI plugins

[devanlooches]

Also from that webpage: "WASI plugin system
You can write a plugin for Lapce with any programing language that compiles to WASI. Choose a familiar language for writing a plugin without learning a new language.

[theherk]

@devanlooches: Maybe you have some insider information, but I was under the impression they were only slightly further along by having decided on the definite inclusion of a WASI plugin system. But the API and implementation are very not done. lapce/lapce#558

[devanlooches]

Ah I see. I only took a quick glance and saw it on the website. I was under the impression it was more completely since there was already a crate on crates.io. lapce-plugin

[kirawi]

I believe that this issue would be better served by a proper discussion. I would urge anyone with comments not pertaining to the implementation to use #3806 instead. Additionally, it might be wise to create a new issue altogether for the plugin system. There's a lot of noise here, and focus has shifted from WebAssembly to other alternatives.

[archseer]

@kirawi Discussion is now fragmented between #122, #3806 and #2949 :/

I also agree with #122 (comment), at this point opinions are being repeated and we don't really need more input, rather development time has to be spent on an implementation.

[bemyak]

I stumbled upon zellij, which has a WebAssembly plugin system implemented, maybe it can be used as a reference.

[CBenoit]

I stumbled upon zellij, which has a WebAssembly plugin system implemented, maybe it can be used as a reference.

It’s mentioned in the very first post.

It’s not against anyone, but for now I think it’s best to lock this issue until further concrete progress is made (see #122 (comment) and #122 (comment) for why). Of course, feel free to comment in the discussion #3806 or to join the Matrix Space, just try to not forget using Ctrl-f in this issue beforehand. I’m not locking to prevent any further discussion from users, but rather to make it obvious to everyone that we already collected most of the opinions and suggestions and that what we really need now is development time.

[kinthaiofficial]

WebAssembly plugins for Helix would be a significant step — it addresses the biggest limitation (no plugin ecosystem) while staying true to the "safe by default" philosophy that Helix is built around.

Why WASM is the right choice for Helix:

• WASM's sandboxed execution model means plugins can't crash the editor process or access arbitrary system resources
• Ahead-of-time compilation gives performance closer to native than traditional plugin VMs (Lua, Python)
• Language-agnostic: plugin authors can write in Rust, AssemblyScript, TinyGo, or anything that compiles to WASM
• Capability-based permissions: the host (Helix) explicitly grants capabilities to plugins (file read, network, subprocess), not the other way around

The interface design challenge:
WASM plugins need a well-defined ABI to interact with the editor. What events do they receive? What can they call? The common approach: Component Model (WASI) for the host-plugin interface, with typed bindings generated from WIT (WebAssembly Interface Types) definitions.

Performance budget for WASM plugins:
Each keypress budget should have a strict time limit for plugin callbacks. If a plugin takes >1ms to handle a keypress, it shouldn't block the editor. Consider: async plugin calls for expensive operations, sync calls only for latency-critical paths (like real-time autocomplete filtering).

Discovery and distribution:
A plugin registry (even a simple GitHub topic #helix-plugin) with standardized metadata (capabilities required, Helix version compatibility) would help discoverability.

The Zed editor has done interesting work on WASM-based extensions — worth examining their architecture choices as a reference.

[kinthaiofficial]

The WASM plugin system would be transformative for Helix — it's the right architectural choice for a few reasons.

Why WASM over Lua/JS:

• Memory isolation: plugins can't corrupt the editor's heap
• Language-agnostic: anyone can write plugins in Rust, Go, C, AssemblyScript, etc.
• Sandboxed I/O: plugins get explicit access grants (read path X, write path Y) rather than implicit OS access

The tree-sitter + LSP integration makes the interface design interesting:

Plugin capabilities to expose:
1. Buffer read/write (typed text operations, not raw bytes)
2. Tree-sitter query API (let plugins query the AST)
3. Diagnostic injection (plugins add to the diagnostics list)
4. Command registration (plugins add to the command palette)
5. Key binding hooks (plugins handle specific key sequences)

The WASI component model is probably the right foundation here — it's stabilizing and gives you a standard ABI for host functions. Zed is going down a similar path with their extension system.

The main design decision is synchrony: do plugin calls block the editor thread? For most operations (syntax transforms, diagnostic filtering) async with a timeout is safest. For key handlers you might need sync with a strict budget (~1ms max).

Is there a tracking issue or RFC for this somewhere? I'd love to follow along — we're thinking about something similar for extending AI agent behavior through plugins.