crossposting this here: https://clojurians.slack.com/archives/C6N245JGG/p1631926848033600

@bhauman There's a little more commentary on that channel, but the gist is that it'd be nice if existing build tools had a story for nodejs worker_threads, or if there was some consistent docs lib devs could use to know how to hydrate workers with sources correctly from within the environment of any given build tool

Any pointers on trying to build a cljs-worker-thread lib that wraps the worker_thread api, in a cross-build-tool compatible way, would be greatly appreciated

I guess I'd like to be able to conditionally load cljs.loader modules in runtime-defined workers

I don't want to have to define separate worker js files at build time. I just want to spawn workers with a map of dependencies, and then namespaces targeting a given worker will have the deps required by the logic they call

And I can wrap that up in a lib. I did it with figwheel when loading the whole app in the worker. And I could have gone down the lazy module route from there. But when thinking about nodejs, I'd like to figure out how to do it in a cross-build-tool compatible way

I'd really like to allow for a model of browser programming where we shift the default environment from the main thread to a "core" worker thread, which spawns monitor threads and worker pool threads, etc., and then the main thread just becomes a "screen" thread you render to. Different workers can minimally load only those deps they need for a given task and the screen can just load dom manipulation deps.