By ByteBot
Bun has opened a pull request that would give JavaScript something Brendan Eich never intended it to have: true shared-memory multithreading. The PR introduces a new Thread(fn) primitive to JavaScriptCore — Bun’s underlying JS engine — that runs a closure on a separate OS thread sharing the exact same JavaScript heap. No postMessage. No serialization. No separate module files. Just threads, in JavaScript, reading and writing the same objects in parallel. The PR itself says “It may never merge.” Hacker News noticed anyway, with 107 comments and climbing.
What new Thread() Actually Means for Bun JavaScript Multithreading
The proposed API is deceptively simple:
const t = new Thread((a, b) => {
return expensive(a, b);
}, x, y);
await t.asyncJoin(); // non-blocking, returns result
Functions are real closures that capture surrounding scope — not stringified code sent to a worker via postMessage. The thread runs on the same heap, with the same objects, under the same module graph that has already been parsed and executed. Spawning one costs roughly 150KB to 1MB while active. For comparison, a Web Worker runs in a separate heap, requires re-parsing your module graph, and consumes 5 to 15MB per instance.
The PR also ships a full set of synchronization primitives: Lock with hold() and asyncHold(), Condition for wait/notify coordination, ThreadLocal for per-thread values, and Atomics extended beyond typed arrays to ordinary JavaScript objects. The engine guarantees memory safety regardless of user-level races — data races produce stale values, not a corrupted heap.
Web Workers Were Never the Real Solution
Web Workers are useful, but the gap between “useful” and “correct” is wider than the documentation suggests. Consider a simple shared cache. With Workers, you need a dedicated cache-server worker, a message protocol, and serialization overhead on every read/write. With the proposed Thread model, it collapses to this:
const cache = new Map();
const lock = new Lock();
// Any thread can safely read/write:
lock.hold(() => {
hit = cache.get(key);
});
This is the Java/Go model for concurrency — shared heap, programmer-managed synchronization. It enables parallel AI inference on the server, document indexing, image processing, and any workload that currently requires forking Node.js child processes or spinning up workers with hand-rolled SharedArrayBuffer protocols. Benchmarks in the PR show a flat JavaScript variant running at 0.85x Java speed at 32 threads. The threading overhead itself is minimal. The JavaScript object model is the bottleneck, not the threading machinery.
This matters particularly as JavaScript moves further into server-side AI and compute-heavy territory — a shift already underway. If you followed the TypeScript 7.0 RC story and its 10x build speed gains via Go’s native parallelism, the pattern is clear: the JS ecosystem is pushing hard against single-threaded performance limits.
The GC Problem Nobody Is Glossing Over
The garbage collection situation is a real limitation, and Bun’s PR does not hide it. When threads are running, concurrent GC marking is disabled. Collections run stop-the-world: all threads pause while the collector marks. For applications with high allocation rates — which describes most real-world JS — that means latency spikes under load. V8, Node.js’s engine, addressed this with its Orinoco concurrent collector years ago. JavaScriptCore, with multiple threads now mutating the same heap, has not yet extended that solution here. The PR explicitly lists concurrent marking as future work.
An experienced VM developer in the HN thread called the current state “cheating” — presenting multithreading without the concurrent GC to back it up. That is a fair critique. The serial performance regression clocks in at only 0.45%, which is excellent, but latency at collection time is a separate problem from raw throughput.
The Trust Problem and the Defense
Bun ships fast, sometimes controversially so. In May 2026, Jarred Sumner used Claude to rewrite 960,000 lines of Zig to Rust in six days. The resulting code contained 13,044 unsafe blocks where typical Rust projects of comparable size average around 73. That history matters when a 60,000-line PR appears with prose that reads like unedited AI output — one reviewer counted 62 em-dashes in the description alone. Some developers have begun preparing migrations back to Node.js. However, not everyone is dismissing the work.
Filip Pizlo, the Apple/WebKit researcher who published “Concurrent JavaScript: It can work!” in 2017 — and whose design is the theoretical foundation this PR builds on — appeared in the HN comments. His verdict: “Very impressed that any LLM can do this.” The technical substance, whatever its provenance, is grounded in real prior research. Pizlo’s 2017 proof-of-concept showed the approach was feasible without killing JSC’s JIT optimizations. Bun’s PR follows that blueprint.
Why This PR Matters Whether or Not It Ships
JavaScript’s single-threaded model was a deliberate choice in 1995, made for a world of single-core CPUs and simple DOM interactions. That world no longer exists. AI server workloads, real-time game backends, and parallel data processing are now routine JavaScript territory — and the existing workarounds (Workers, SharedArrayBuffer, child processes) all carry significant complexity overhead.
Moreover, this PR demonstrates that shared-memory threading in JavaScriptCore is technically feasible at scale — 93 tests passing, zero ThreadSanitizer races, a 0.45% worst-case serial regression. The GC work remains unfinished. The stability questions around Bun’s development practices are legitimate. But “may never merge” is not the same as “does not matter.” The conversation about what JavaScript’s concurrency model should look like in 2026 — not 1995 — is worth having, and Bun just forced it onto the agenda.
