wasm-futures-executor VS wireworld-player

RUSTFLAGS='-C target-feature=+bulk-memory' should work according to the readme of https://github.com/wngr/wasm-futures-executor

I recommend using it through the wasm-futures-executor crate: https://github.com/wngr/wasm-futures-executor.

By the way, I built something similar (?): A Rust library that mimics the API of the `futures-executor` crate, but each worker thread is a single WebWorker.

https://github.com/wngr/wasm-futures-executor

This past year I've live streamed the development of a small web app that benefits enormously from web workers:

https://github.com/Rezmason/wireworld-player

https://rezmason.github.io/wireworld-player

As a simulation, the main thread asks a web worker to update the world state and then render the new state. By default, this happens once per requestAnimationFrame.

But there's a "Turbo" button (it looks like a radioactive hazard symbol) that allows the web worker to update as often as it can per requestAnimationFrame, speeding up the simulation around 72x while keeping the main thread 100% responsive.

The decoupling of the synchronous number crunching work from the main thread has also given me a place to experiment with much more resource intensive algorithms, like https://jennyhasahat.github.io/hashlife.html , which fills an enormous cache and can advance the sim by exponential time steps.

Modifying Hashlife to run in the main thread without freezing the app is possible, but it would have made the code much more complicated, run slower, and the other cores available to web workers would have gone unused.