wasm-futures-executor
wireworld-player
wasm-futures-executor | wireworld-player | |
---|---|---|
3 | 1 | |
29 | 8 | |
- | - | |
0.0 | 2.4 | |
almost 2 years ago | 7 months ago | |
Rust | JavaScript | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wasm-futures-executor
-
How to enable Bulk Memory Operations when compiling to WebAssembly?
RUSTFLAGS='-C target-feature=+bulk-memory' should work according to the readme of https://github.com/wngr/wasm-futures-executor
-
Threading for WASM target
I recommend using it through the wasm-futures-executor crate: https://github.com/wngr/wasm-futures-executor.
-
Web Crypto API
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
wireworld-player
-
Web Crypto API
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.
What are some alternatives?
yew - Rust / Wasm framework for creating reliable and efficient web applications
objectbuffer - JavaScript Object like api, backed by an arraybuffer
worktank - A simple isomorphic library for executing functions inside WebWorkers or Node Threads pools.
rinzler - An autonomous parallel processing engine for the browser.
pasts - Minimal and simpler alternative to the futures crate.
worktank-loader - WebPack plugin for WorkTank which enables you to execute whole files in a worker pool, transparently.
comlink - Comlink makes WebWorkers enjoyable.
coi-serviceworker - Cross-origin isolation (COOP and COEP) through a service worker for situations in which you can't control the headers (e.g. GH pages)