Wasmtime GitHub notifications bot (Jun 02 2023 at 11:47): Wasmtime GitHub notifications bot (Jun 02 2023 at 11:47):kajacx opened issue #6504:
Make Wasmtime work on the web
The current wasmtime Rust crate works well on desktop, but I doesn't work on the web.
Benefit
Making wasmtime work on the web would allow to have a single application with single source code in Rust, and be able to build it as a desktop application or as a web application that would run in the browser.
Implementation
On the web, the browser runs the WASM modules. This would include the Rust application that is using wasmtime to load WASM modules, and those modules as well. This means that an engine or a compiler is not needed, and calls to the module's exported functions probably need to go through the broweser. Wasmer already manages to do this with the
jsfeature,Alternatives
One alternative is to use wasmer instead of wasmtime.
Other alternative is to rewrite your entire application in TS if you want to run it on the web.
Third alternative is to use wasm_bindgen as a bridge between your Rust application and the browser, and then call the module's functions from there.
Wasmtime GitHub notifications bot (Jun 02 2023 at 16:56):jameysharp commented on issue #6504:
It sounds like you want the ability to use Wasmtime's API for embedders without any of Wasmtime's implementation of that API. The implementation is heavily tied to running under a traditional operating system and JIT-compiling native code, and I don't think there's anything there that would be useful to reuse in a browser. In addition, many aspects of Wasmtime's API and configuration options are impossible to implement in a browser, so only a small subset of the embedder API would work anyway.
I would recommend instead that you create a new Rust crate providing a WebAssembly embedding API that uses browser interfaces when built for wasm, and uses Wasmtime otherwise. That allows you to define the API in a way that makes sense for both settings. You could even offer build-time options to use other engines besides Wasmtime, if you wanted to.
Building that crate is out of scope for the Wasmtime project, but I think it would be a great contribution to the WebAssembly ecosystem. If you want to build it, I think the #wasm stream on the Bytecode Alliance Zulip would be a good place to discuss the idea.
I'm going to close this issue since I don't believe it's something that this team can address, but if I've misunderstood what you're asking for, you're welcome to re-open it.
Wasmtime GitHub notifications bot (Jun 02 2023 at 16:56):jameysharp closed issue #6504:
Make Wasmtime work on the web
The current wasmtime Rust crate works well on desktop, but I doesn't work on the web.
Benefit
Making wasmtime work on the web would allow to have a single application with single source code in Rust, and be able to build it as a desktop application or as a web application that would run in the browser.
Implementation
On the web, the browser runs the WASM modules. This would include the Rust application that is using wasmtime to load WASM modules, and those modules as well. This means that an engine or a compiler is not needed, and calls to the module's exported functions probably need to go through the broweser. Wasmer already manages to do this with the
jsfeature,Alternatives
One alternative is to use wasmer instead of wasmtime.
Other alternative is to rewrite your entire application in TS if you want to run it on the web.
Third alternative is to use wasm_bindgen as a bridge between your Rust application and the browser, and then call the module's functions from there.
Wasmtime GitHub notifications bot (Jun 02 2023 at 19:52):kajacx commented on issue #6504:
Yes, what I want is the ability to use single source code that would load and run wasm modules both on desktop and on the web. With wit bindgen support.
But you are right to say it's out of scope for wasmtime, since doing so requires none of the hard work of actually running a WASM module, and only requires gluing together calls to the browser-provided APIs.
The tough part will be making it work in a consistent and reusable way while supporting wit bindgen, because WASM without a bindgen kind of sucks.
I guess I have work to do for the foreseeable future. Thanks for taking your time to write such a comprehensive reply.
Wasmtime GitHub notifications bot (Jun 02 2023 at 19:55):sunfishcode commented on issue #6504:
@kajacx You may be interested in jco, which is a set of tools for running components built with wit-bindgen in JS environments, including browsers.
Wasmtime GitHub notifications bot (Jun 02 2023 at 20:05):kajacx commented on issue #6504:
Thanks, I have seen
jcofor the first time today. So far I have been using wasmer and wai bindgen, but I think I will be moving to wit bindgen and wasmtime instead, since wit bindgen supports more guest languages.
Wasmtime GitHub notifications bot (Jul 02 2023 at 19:03):kajacx edited issue #6504:
Make Wasmtime work on the web
The current wasmtime Rust crate works well on desktop, but I doesn't work on the web.
Benefit
Making wasmtime work on the web would allow to have a single application with single source code in Rust, and be able to build it as a desktop application or as a web application that would run in the browser.
Implementation
On the web, the browser runs the WASM modules. This would include the Rust application that is using wasmtime to load WASM modules, and those modules as well. This means that an engine or a compiler is not needed, and calls to the module's exported functions probably need to go through the broweser. Wasmer already manages to do this with the
jsfeature,Alternatives
One alternative is to use wasmer instead of wasmtime.
Other alternative is to rewrite your entire application in TS if you want to run it on the web.
Third alternative is to use wasm_bindgen as a bridge between your Rust application and the browser, and then call the module's functions from there.
Edit
I have started work on a crate that would use
js-syson the web with the same API as wasmtime, see wasm-bridge.
Last updated: Nov 22 2024 at 16:03 UTC