The JavaScript runtime's open pull request, on a Bun maintained fork of the Safari engine WebKit, proposes shared memory threads, and its 'experimental, not working yet' label is doing more work than it looks.
A function in JavaScript is a closure: it captures variables from where it was defined and carries them around. Inside a single thread, that works fine. The trouble starts when you want the same function to run on a different core. The existing answer, the Web Worker model, forces a worker to live in its own copy of the runtime, with its own heap, and the only way to give it a function is to ship the function's source across a postMessage boundary and rebuild it on the other side. To share a real object, you serialize it, which is why the model comes bundled with structuredClone and the SharedArrayBuffer workaround.
Bun, the JavaScript runtime built by Jarred-Sumner, has an open pull request against a fork of WebKit, the browser engine that powers Safari, that proposes to retire that round-trip. The PR adds a Thread(fn) constructor that runs fn on another thread, in the same heap, with the same objects. To share an object, you share the object. There is no structured clone, no postMessage ceremony, and no SharedArrayBuffer-only escape hatch. The author describes the work as "experimental, not working yet." That label is doing more work than it looks.
Most of the design choices that defined JavaScript threading after the Spectre side-channel disclosures in 2018, including the structured-clone boundary and the decision to keep real shared memory off by default, were made upstream, in WebKit, Chromium, and Firefox together. The Bun PR does not propose to reopen those conversations in any of those forums. It proposes a different runtime, a different engine tree, and a different set of tradeoffs. The proposal is that consensus becomes optional when you control the engine under the runtime. The PR is hosted on oven-sh/WebKit, which is Bun's own fork of the upstream WebKit project. The two repositories are not the same place.
Inside the diff, the author reports that parallel JavaScript now executes through all four of JavaScriptCore's JIT tiers, that the engine no longer takes a global lock for thread transitions, and that Bun's thread test suite is passing in this configuration. The author also calls out what is not done: thread-sanitizer cleanup is pending, fuzzing has not been run, one benchmark is over budget, and a long-soak run is outstanding. Two configurations, a locked fallback and a threads-disabled build, are deliberately left in the tree as the safety net. The bring-up log is the story: the PR is unusual in how candidly it publishes its own costs.
The strategic question is why the PR is public at all. The author says it may never merge. The fork, the "experimental" label, and the fact that no third-party runtime vendor has been pulled into the review thread are connected. A design proposal in a Bun-maintained fork, with no shipped binary, gives competitors no concrete behavior to benchmark against and no API contract to embrace or refuse. It is not a feature drop. It is a relocation: the post-Spectre web-platform threading consensus is being moved, one design choice at a time, onto a server runtime that does not answer to the web platform's standards process.
What to watch next is the cost ledger, not the headline. If thread-sanitizer cleanup and the over-budget benchmark close out cleanly, the design will have answered its own safety questions on this fork. If the bring-up log grows without a corresponding safety-net path being retired, "experimental" starts to read as a permanent state. And if the proposal eventually migrates from oven-sh/WebKit toward upstream WebKit or another engine, the consensus conversation the PR is currently side-stepping will become unavoidable.