Native executables and WebAssembly port

rhaiscript / lsp

Language server for Rhai.

Apache License 2.0

43 stars 4 forks source link

Native executables and WebAssembly port #36

Closed tamasfe closed 2 years ago

tamasfe commented 2 years ago

I started with targeting WASM initially as it can be run in the browsers, and the VSCode extension distribution is trivial.

However there are a few issues:

build times are worse (due to additional steps) and debugging is awful
it requires a shim of javascript for i/o
worse performance (no threads available)

So right now I left the WASM builds as-is, and switched to a native executable for the initial development. I will also clean up any unnecessary WASM-related build steps and javascript shims to make contributions easier.

The big question is how to port Rhai LSP to browsers. There are several options:

target WASI, we would have i/o but still no threads, and the state of WASI still seems very experimental
target WASM with a javascript layer, this is already what we had and turned out to be rather cumbersome
do not port at all, and always require the LSP to run somewhere outside of the browser or vscode extensions

schungx commented 2 years ago

The big question is how to port Rhai LSP to browsers. There are several options:

Is this necessary? I would have thought a WASM runtime is already flexible enough...

tamasfe commented 2 years ago

The big question is how to port Rhai LSP to browsers. There are several options:

I would have thought a WASM runtime is already flexible enough...

It is not, as I mentioned, there is no i/o, threading, both of which should be handled when targeting WASM.

schungx commented 2 years ago

Ah, ok... now I understand. However, I'd say that it would be a huge feat if you can make WASM work. An LSP in WASM would avoid the need to pre-package a lot of pre-built binaries for different OSs.

tamasfe commented 2 years ago

If we don't find better alternatives, I think we can do the same thing I did with taplo. Which means defining "external" functions that cannot simply be done in WASM (such as i/o), and then just use wasm-bindgen and a javascript shim over them, and also switch the runtime from tokio to the one available in javascript (as there is no threading, and no async in WASM either).

schungx commented 2 years ago

switch the runtime from tokio to the one available in javascript

Is multi-threading a necessity in an LSP? I don't know much about one so I can't guess.

schungx commented 2 years ago

Not sure if this would be useful: https://www.osohq.com/post/building-vs-code-extension-with-rust-wasm-typescript

tamasfe commented 2 years ago

Is multi-threading a necessity in an LSP? I don't know much about one so I can't guess.

It's not necessarily, it's not even possible in WASM (out of the box), but it obviously helps with performance.

Not sure if this would be useful: https://www.osohq.com/post/building-vs-code-extension-with-rust-wasm-typescript

Thanks, it looks like the same approach I outlined.

tamasfe commented 2 years ago

This was merged in #79.