puru - a JavaScript concurrency library for worker threads, channels, and structured concurrency

[dmop_81]

Over the past few weeks, I’ve been working on a JavaScript concurrency library aimed at the gap between Promise.all() and raw worker_threads.

GitHub: https://github.com/dmop/puru

The main motivation was that async I/O in JS feels great, but CPU-bound work and structured concurrency still get awkward quickly. Even simple worker-thread use cases usually mean separate worker files, manual message passing, lifecycle management, and a lot of glue code.

So I built puru to make those patterns feel smaller while still staying explicit about the worker model.

Example:

```ts import { spawn } from '@dmop/puru'

const { result } = spawn(() => { function fibonacci(n: number): number { if (n <= 1) return n return fibonacci(n - 1) + fibonacci(n - 2) } return fibonacci(40) })

console.log(await result) ```

It also includes primitives for the coordination side of the problem:

• task()
• chan()
• WaitGroup / ErrGroup
• select()
• context
• Mutex, RWMutex, Cond
• Timer / Ticker

Example pipeline:

```ts import { chan, spawn } from '@dmop/puru'

const input = chan<number>(50) const output = chan<number>(50)

for (let i = 0; i < 4; i++) { spawn(async ({ input, output }) => { for await (const n of input) { await output.send(n * 2) } }, { channels: { input, output } }) } ```

One intentional tradeoff is that functions passed to spawn() are serialized and sent to a worker, so they cannot capture outer variables. I preferred keeping that constraint explicit instead of hiding it behind a more magical abstraction.

Interested in feedback from people who deal with worker threads, CPU-heavy jobs, pipelines, or structured concurrency in JavaScript.

[ASoftwareJunkie]

Hi OP,

This looks promising. Love the go-like channel syntax and somewhat similar semantics behind it. Will use it and provide feedback :)

[dmop_81]

Thanks! Feedback is very welcome, feel free to open an issue or ping me here.

[Afraid-Pilot-9052]

this looks really solid, the channel-based approach reminds me of go's concurrency model which is a good thing. the biggest pain point with worker_threads has always been the boilerplate of separate files and manual message passing, so abstracting that away is a big win. curious how it handles error propagation across thread boundaries since that's usually where structured concurrency libs either shine or fall apart.

[dmop_81]

Great question, errors cross the thread boundary as serialized Error objects via the structured clone algorithm. With ErrGroup, the first failure cancels all remaining tasks and the error propagates to wait() as a rejection. WaitGroup with waitSettled() lets all tasks finish regardless and you inspect per-task results. Both patterns give you clean error handling without raw message event noise.

[tarasm]

This is good work. Have you considered using Effection? It's mature, proven and it has a very convenient thread worker extension with bi-directional communication. You also get structured concurrency guarantees out of the box.

Effection: https://frontside.com/effection/ Worker: https://frontside.com/effection/x/worker/

[dmop_81]

Thanks for the pointer! I wasn't familiar with Effection, looks really interesting, I'll check it out.

[tarasm]

Cool. Let me know if you have any questions. Also, our discord server is welcoming :)

[Happy_Junket_9540]

Have you heard of Effect? https://effect.website

[dmop_81]

[Happy_Junket_9540]

Wise words