worktank
wireworld-player
worktank | wireworld-player | |
---|---|---|
1 | 1 | |
34 | 8 | |
- | - | |
6.6 | 2.4 | |
29 days ago | 7 months ago | |
TypeScript | JavaScript | |
MIT License | - |
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.
worktank
-
Web Crypto API
Workers are awesome but you are right, working with them can be painful without the right tooling.
Personally I've written my own libraries for abstracting all this away and I've having a blast working with workers now, maybe check them out:
- WorkTank [1]: This abstracts away the difference between browser workers and Node worker threads, it makes it easy to make worker pools, and it can transfer simple functions to a worker at runtime too.
- WorkTank loader: This abstracts away loading asynchronous function from a worker basically, you just add ".worker" to your file name and that file and all its dependencies are transparently replaced moved to a worker, all the rest of the app (TS types for example) doesn't even notice anything happened, it just works.
You might want to check out the more popular "comlink" library too, although it didn't work for me for whatever reason and it doesn't support worker pools I believe.
[1]: https://github.com/fabiospampinato/worktank
[2]: https://github.com/fabiospampinato/worktank-loader
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?
wasm-futures-executor - Executor for asynchronous task based on wasm web workers.
objectbuffer - JavaScript Object like api, backed by an arraybuffer
worktank-loader - WebPack plugin for WorkTank which enables you to execute whole files in a worker pool, transparently.
main-thread-scheduling - Fast and consistently responsive apps using a single function call
rinzler - An autonomous parallel processing engine for the browser.
comlink - Comlink makes WebWorkers enjoyable.