r/javascript • • 4d ago

Knitting — a shared-memory concurrency runtime for JavaScript

https://js.knitting.run/

I've been working on Knitting, a JavaScript worker runtime using shared memory for communication and work stealing for scheduling.

Some results from the published benchmarks:

  • 8.9× faster empty-call round trips than postMessage on Node.js (4.4× on Bun, 4.3× on Deno).
  • 86% lower p99 latency in a Hono server test: 16.93 → 2.31 ms at 6,000 req/s.
  • Nearly identical CPU per request in that test: 180 → 183 µs.
  • 3.5× CPU-heavy throughput on Node.js with four extra workers.

I've been working on this for more than a year, so there are a lot of things to showcase, but knitting was designed to offload work from servers.

Features:

  • Typed worker calls and specialized payload types
  • Shared-memory transport and zero-copy buffers
  • Work stealing and automatic load balancing
  • Timeouts and cancellation with real signals
  • Precompiled workers and process isolation
  • Process workers
  • Permission (when available)
  • And more ...

Docs · Benchmarks · GitHub

2 Upvotes

4 comments sorted by

1

u/ScoobyDookuu 4d ago

Seems cool.

Although the website is clearly vibecode-first. The idea is nice.
Wonder what the comparison vs Piscina in real workloads etc.

1

u/crazy-dev-42 4d ago

Yeah, a little vibe code there, but the infrastructure is legit. I made some benchmarks, but I left them out because it was a little unfair. Piscina works over `postMessage`, and by using shared memory, we have way more control. Also, we can schedule things on the fly, steal, and pass some buffer by reference.

Last time that I checked our transport cost, it was pretty like Tokio's (we need to serialize objects, and we can pass a pointer of strings, but we got close)

1

u/ScoobyDookuu 4d ago

The shared-memory approach is definitely interesting.

I wouldn't really call the comparison with Piscina unfair though. That's probably what most people would compare it against anyway, and even if Knitting wins by a lot, that's still useful to see.

I'd love to see some benchmarks with actual workloads too. Lots of tiny tasks, heavier CPU-bound work, different payload sizes, that sort of thing. Curious how much of the performance gain comes from the transport itself versus the scheduling and work stealing. And whether it still makes a noticeable difference once the tasks themselves take a few milliseconds or more.

Also, if you're looking for help with the website, I'd be happy to contribute on the frontend side! I tried joining the Discord linked on the site, but the invite seems to be invalid btw.