Can Bun Bring True Multi‑Threading to JavaScript?

What’s missing in worker_threads

Many assume that Node.js already has worker_threads or that browsers’ Web Workers or Bun’s Worker API provide true multithreading, but Jarred Sumner replies, “And no, worker_threads / Worker is not that.” The current “multithreading” in JavaScript is essentially a multi‑process model disguised as threads.

Each Worker creates a separate V8 Isolate with its own heap, garbage collector and global object. Communication between the main thread and a Worker can only use postMessage, which relies on the structured‑clone algorithm to copy data. Sending a 10 MB object therefore consumes about 20 MB of memory and adds serialization overhead.

The practical consequences are:

High memory cost : a Worker in Node.js often uses more than 30 MB; 20 Workers can consume several hundred megabytes.

Expensive communication : postMessage incurs serialization, transfer and deserialization costs, which become noticeable in frequent‑communication scenarios.

No shared state : threads cannot operate on the same object directly; sharing requires SharedArrayBuffer (which only stores raw bytes) or repeated copying.

This resembles two independent JavaScript processes communicating via a message queue rather than true multithreading.

The desired model

Sumner sketches a blueprint: a single global object, a single garbage collector, objects accessible across threads, no postMessage overhead, and each thread using less than 2 MB of memory.

One global object: all threads share the same heap.

One garbage collector: unified memory management.

Objects accessible across threads: a thread can read or write objects created by another without copying.

No postMessage overhead: threads communicate via shared memory directly.

Thread memory footprint < 2 MB: allows many lightweight threads.

This mirrors the thread models of Java, Go, and C++ where multiple threads naturally share a heap.

Why it’s still impossible today

The obstacle lies in V8’s design. V8 isolates each execution context with its own heap and GC to simplify safety and avoid concurrency conflicts. Breaking this isolation raises two major challenges:

Memory safety : race conditions can corrupt data; JavaScript lacks a static type system to prevent them.

Garbage collection : traditional GC assumes exclusive heap ownership; sharing a heap would require either pausing all threads or implementing a complex concurrent GC.

Consequently, SharedArrayBuffer is the closest standard feature to shared memory, but it only stores raw bytes, not objects.

Why Bun can speak about it

Node.js is tied to V8’s isolate architecture, so changing the thread model would require coordination with the V8 team. Bun, however, rewrites the JavaScript runtime from the ground up—initially in Zig and now migrating to Rust—using JavaScriptCore instead of V8. This gives Bun far more control over its runtime architecture and the ability to experiment with a new thread model without altering V8.

TC39’s progress

TC39 is advancing a proposal called Shared Structs , which would allow defining structures that can be shared across JavaScript threads, similar to SharedArrayBuffer but capable of holding structured data. The proposal also introduces Mutex and Condition primitives for concurrency control. While this is a step toward shared memory, it still requires developers to explicitly declare shared data and manage synchronization, falling short of Sumner’s vision of “any JS object freely shared across threads.”

Implications for Node.js developers

If true shared multithreading were realized, the Node.js programming model would change dramatically. Today, CPU‑intensive work is offloaded to heavyweight Workers, separate processes, or C++ addons. A lightweight shared‑thread model would let pure‑JavaScript threads handle image processing, encryption, or data parsing efficiently, with far lower memory overhead—potentially under 2 MB per thread instead of hundreds of megabytes for multiple Workers.

This would be especially significant for high‑concurrency services, where memory efficiency and reduced inter‑thread communication cost are critical.