cargo-wasi VS wasm-bindgen

There are many options, but what worked best for me is compiling with cargo-wasi and loading the resulting Wasm file with browser_wasi_shim. Using wasm32-wasi instead of wasm32-unknown-unknown requires a bit more work (the communication with JS has to be set up manually), but gives the flexibility of having just a Wasm file that can be dropped in and loaded dynamically. (There's wit-bindgen for generating wrapping code according to an interface definition but I didn't have much success with it.)

I use cargo-wasi to build it:

> I couldn't figure out a way to to get emscripten wasm code to play nice with wasm32-unknown-unknown

There is good news there, some people plan to work on making Emscripten and Rust work well in Wasm:

https://github.com/rustwasm/wasm-bindgen/pull/4014#issuecomm...

That said, WebAssembly’s ecosystem is still fragmented. Tools like Emscripten (C/C++), wasm-bindgen (Rust), and JSGo (Go) serve different languages, but this complicates the standardization of interactions with web APIs, limiting broader WASM integration with web development.

> Here's an example of Bevy WebGL vs Bevy WebGPU

I think a better comparison would be more representative of a real game scene, because modern graphics APIs is meant to optimize typical rendering loops and might even add more overhead to trivial test cases like bunnymark.

That said though, they're already comparable which seems great considering how little performance optimization WebGPU has received relative to WebGL (at the browser level). There are also some performance optimizations at the wasm binding level that might be noticeable for trivial benchmarks that haven't made it into Bevy yet, e.g., https://github.com/rustwasm/wasm-bindgen/issues/3468 (this applies much more to WebGPU than WebGL).

> They're 10k triangles and they're not overlapping... There are no textures per se. No passes except the main one, with a 1080p render texture. No microtriangles. And I bet the shader is less than 0.25 ALU.

I don't know your exact test case so I can't say for sure, but if there are writes happening per draw call or something then you might have problems like this. Either way your graphics driver should be receiving roughly the same commands as you would when you use Vulkan or DX12 natively or WebGL, so there might be something else going on if the performance is a lot worse than you'd expect.

There is some extra API call (draw, upload, pipeline switch, etc.) overhead because your browser execute graphics commands in a separate rendering process, so this might have a noticeable performance effect for large draw call counts. Batching would help a lot with that whether you're using WebGL or WebGPU.

I already knew that there was a good quality library unicode-segmentation in Rust, and Rust has a great WebAssembly toolchain called wasm-bindgen.

The binding of Rust (WASM) and JavaScript is done with the help of wasm-bindgen and wasm-pack -- https://github.com/rustwasm/wasm-bindgen/tree/main/examples/without-a-bundler

Another strange issue could be seen in the strict class heritage organized definition of the DOM, which can not be handled very well by rust because of a still unsolved bindgen issue (#210).

For a much simpler but less flexible approach there's wasm-pack for creating JS packages from Rust, and wasm-bindgen for easy interop. Both have very good documentation.

We encountered quite a few hurdles on our journey. For one, we had to build our own yew-webtransport and yew-websocket integration from scratch by adding WebTransport definitions to wasm-bindgen (pull request link). We also had to add WebTransport support to the h3 crate (pull request link). co-created by @ten3roberts

Go with your WebAssembly module idea. Since it sounds like your chess engine does not draw a UI, it shouldn't be too difficult. wasm-bindgen will be your best friend.