Quick update on this:
The first official alpha release of inmesh is out: net.clojars.john/inmesh {:mvn/version "0.1.0-alpha.1"} - “One step closer to threads on the web” - GitHub - johnmn3/inmesh
Now spawn, in, and future all provide:
- simple implicit binding conveyance as well as explicit binding conveyance
- derefability (synchronous results) in workers and returning promises in the main thread
-
yieldfor converting async functions into synchronous ones
For now, you have to declare some configuration details in an ns loaded by the screen/main thread. By the beta releases though, I’d like to provide some automation so that you only need to declare configurations for advanced scenarios.
In general, spawn can take a half-second of overhead to launch, depending on loaded libs.
in usually takes 4 or 5 milliseconds of overhead for small invocations.
future usually takes 8 to 10 milliseconds of overhead for small invocations
Also, inmesh now comes with a wrapper for js/IndexedDB, providing a synchronous db-get call, similar to the synchronous API of js/localstorage. js/localstorage isn’t available in webworkers, so having this synchronous interface is super convenient for libs and frameworks that expect synchronous access to storage.
As such, the repo now also provides a standard dashboard demo built on re-frame/mui-v5/comp.el/sync-IndexedDB, with application logic (reg-subs & reg-event functions) moved into a webworker, where only react rendering is handled on the screen thread, allowing for buttery-smooth components backed by large data transformations in the workers.
)
Issues and PRs are welcome. It’s a pretty early alpha and the APIs are subject to change. Might provide a pmap before the beta. Happy hacking!