Browser support

[alardev]

Currently it seems that Wasmtime supports being built against wasm32-wasip2 target. Unfortunately this probably leaves wasm32-unknown-unknown out as it does not support WASI features.

I was wondering if in theory Wasvy could run in bevy web builds as that would allow modding bevy games that run in the browser too.

perhaps using WASMI could be considered for web support?

https://0x53a.github.io/wasm-in-wasm/
https://github.com/0x53A/wasm-in-wasm

i found this awesome example of loading the WASM module implementing the specified WIT as a good example of how it could be done, additionally WASMI state that they are heavily inspired and can be used as a loose drop-in replacement for Wasmtime.

I am motivated in trying to build a WASMI version of Wasvy as a proof-of-concept, although I am kinda hoping that there is a way to build wasvy for web using wasmtime too.

Any additional information would be helpful.

[MarcGuiselin]

I'm very interested in browser support! That'd be an amazing feature.

Currently it seems that Wasmtime supports being built against wasm32-wasip2 target.

Where did you find this information? If that's the case we might be able to support that on the web with a wasip2 shim such as the one here. Potentially there's no need to switch to wasmi.

perhaps using WASMI could be considered for web support?

Problem with Wasmi is that they are lagging behind the wasi spec and only support preview1 at the moment. But that's not necessarily a deal-breaker for me, especially if Wasmi matches Wasmtime in terms of features.

Wasmi on native will be slower that Wasmtime due to its nature as a wasm interpreter. But that's not a big issue, we could opt to just use wasmi exclusively for web.

Some other alternatives to consider

Wasmer has really good support for browser apis, and if their benchmarks are to be believed, better performance than wasmtime. But refactoring Wasvy to use Wasmer would be a somewhat big task.

Using jco, another bytecode alliance project. This would probably involve writing a bevy system runtime in typescript using the interfaces jco provides then piping data to and from wasvy.

For both of these alternatives the overhead of js to wasm calls might prove to be too high to make this viable for realtime systems. But running wasm in wasm has higher runtime costs, so it's a tradeoff either way we decide to go. Benchmarks are key.

[alardev]

Thank you for your quick reply!

Where did you find this information? If that's the case we might be able to support that on the web with a wasip2 shim such as the one here. Potentially there's no need to switch to wasmi.

I've reread the docs and it seems that in practical terms it's not useful when you compile it to wasm32-wasip2 as shown here. The cranelift and winch can be compiled to wasm and they can cross-compile to bytecode, but the wasm sandbox forbids execution of the said code.

Problem with Wasmi is that they are lagging behind the wasi spec and only support preview1 at the moment. But that's not necessarily a deal-breaker for me, especially if Wasmi matches Wasmtime in terms of features.

Wasmi on native will be slower that Wasmtime due to its nature as a wasm interpreter. But that's not a big issue, we could opt to just use wasmi exclusively for web.

Yes, I've realized that it's a pure software approach essentially running a wasm VM inside an existing wasm sandbox... and while wasmi has improved a lot since 0.32 it still is far too slow for anything performance heavy, such as physics etc.

Wasmer has really good support for browser apis, and if their benchmarks are to be believed, better performance than wasmtime. But refactoring Wasvy to use Wasmer would be a somewhat big task.

Wasmer is an interesting project, however it's divergent from the Bytecode alliances and the general spec imo. I don't see it as a future-proof solution. However, while working on a port of the linked example above I realized that the wasm_runtime_layer coupled with wasm_component_layer can abstract the wasm backend engine quite well and currently they support the following: Wasmer, wasmi, js_wasm_runtime (browser V8) and wasmtime too!

So what I've done is I've ported the example to work with bevy web. Currently i've successfully tested with wasmi, however I'll try out the js_wasm_runtime as it's the most performant option for browsers along with wasmer. If all goes well I will probably try create a wasm_runtime_layer modloader for bevy.

[MarcGuiselin]

I've reread the docs and it seems that in practical terms it's not useful when you compile it to wasm32-wasip2 as shown here.

Okay I see. That's unfortunate, but what I expected. You seemed to be suggesting wasmtime could be run in a web context and I was surprised, but I took you at your word. Just a misunderstanding on my part.

Wasmer is an interesting project, however it's divergent from the Bytecode alliances and the general spec imo. I don't see it as a future-proof solution.

Yes, they are still unfortunately pushing for their alternative wasix. I just remembered that they had good primitives that perfectly matched web apis (and worked with them) back when I was experimenting on a different project a while back. Without component model support (and thus wasi support after wasip1), I agree it's not future-proof. But the runtime itself is solid.

I realized that the wasm_runtime_layer coupled with wasm_component_layer can abstract the wasm backend engine

Currently i've successfully tested with wasmi, however I'll try out the js_wasm_runtime as it's the most performant option for browsers along with wasmer

That's awesome! Nice job, and good finds! I didn't even know those runtime abstraction crates existed. Makes me wish we used those from the beginning so we could experiment with different runtimes as you are now doing.

It'd be perfect if we could wrap everything together and have it work straight out of the box with no configuration for Bevy, whether that be on native or web. Looking forward to seeing what you build! This is exciting stuff!