Offloading work to web workers in deployments using a bundler

[kmdouglass]

Summary

Is it possible to use Wasm from inside a web worker when using wasm-bindgen to build a JS + Rust/Wasm app that is deployed via a bundler?

Additional Details

I am working on a mixed JS + Rust/Wasm project that is deployed using Webpack 5. Recently I added a feature that requires a few seconds of computation time from inside Wasm. Currently, I use wasm_bindgen to expose a Rust struct to JS that contains the Rust application state. I call a method on this JS instance which in turn calls the Rust function that performs the calculation. I'd like to offload this computation to a webworker to avoid blocking the UI, possibly by passing the data necessary for the computation to the web worker and then calling a Wasm function inside the web worker. This would mean having the Wasm module instantiated in both the main thread and the worker.

I've been researching how to do this for several days, but still am a bit confused about what is and isn't possible. I've tried the following:

1. I naively tried to create a web worker from JS and import the Wasm bindgen JS glue from the worker, but this fails. I'm not certain why, but I believe it's because I would need to import the glue code using importScripts. However, I can't seem to use importScripts because the bundler can place my wasm-pack-built package anywhere.

2. I tried spawning a web worker from inside Rust. To do this, I learned that I could import the worker.js script at compile time and pass it as a blob URL to the worker constructor: https://users.rust-lang.org/t/creating-a-web-worker-from-rust-wasm-using-a-bundler/104866

Here, however, I don't know how to instantiate the Wasm module inside the worker, again because I think the bundler can effectively place it anywhere. I did try to call import { ... } from "my_app" inside the worker to instantiate the Wasm module, but this fails for some unknown reason.

3. I've toyed around with the approach described here where a Rust closure is passed to a web worker by sharing the Wasm memory object, but I don't see how to get this object from the JS glue that wasm-pack outputs.

---

I've read that in the wasm_bindgen guide that

Setting up a threaded environment is a bit wonky and doesn't feel smooth today. For example --target bundler is unsupported and very specific shims are required on both the main thread and worker threads.

Am I stuck rewriting my deployment to not use a bundler, or is there something I am overlooking?

Apologies if I have made a mistake somewhere in my reasoning; I'm relatively new to a lot of the ecosystem around Wasm.

[daxpedda]

Setting up a threaded environment is a bit wonky and doesn't feel smooth today. For example --target bundler is unsupported and very specific shims are required on both the main thread and worker threads.

Am I stuck rewriting my deployment to not use a bundler, or is there something I am overlooking?

Take this with a grain of salt because I've never used bundlers and I'm unfamiliar with the part of the code in wasm-bindgen that handles this. But I've seen some reports of people failing to do this already, so I think there is nothing you are overlooking, this is just simply not supported right now.

[kmdouglass]

Thanks for your reply, @daxpedda .

This morning I found the wasm_bindgen_rayon crate which deploys a small demo app that seems to match my use case: use Rust/Wasm in web workers in a JS app that is bundled and deployed with Webpack5.

In the coming week or two I'm going to try to make a minimal example that does this.

If I manage to do this, then I think my understanding of the wasm_bindgen --target option will have changed slightly, at least in this context:

• --target bundler means to create the Wasm bindings for an app that is deployed by a bundler and that calls Wasm from the main thread
• --target web means to create the Wasm bindings for an app that may or may not be deployed by a bundler and which can, support calling Wasm from a web worker

Or do you think this conclusion is not justified?

[kmdouglass]

I just saw that #3720 is closely related to this discussion as well.

[daxpedda]

Or do you think this conclusion is not justified?

Again, unfortunately I'm clueless about bundlers, but that sounds sensible to me!

[kmdouglass]

Based on help from others here, on the Rust language form, and the demo project in wasm-bindgen-rayon, I can indeed confirm that it is possible and actually straightforward to deploy a JS + Rust/Wasm app with support for WebAssembly threads via a bundler. I made a minimal example here: https://github.com/kmdouglass/playground/tree/main/wasm-threads-bundler

@daxpedda I think that the wasm-bindgen guide might be worth updating or amending. As was mentioned in #3720 , there's nothing special about the web build target, and the fact that one of the primary targets is named bundler can mislead one into thinking that only this target can be used with a bundler.

Do you have any suggestions for where in the docs this information might best go?

[daxpedda]

Unfortunately I don't, but I'm also hesitant to review any PRs regarding bundlers because I just don't know anything about that target.
So you will have to wait until another maintainer more comfortable with that chimes in.

I still very much appreciate you looking into this! Thank you!