Here is the whole idea in one paragraph. You open a web page. You click a button that says "Join the grid." Your browser downloads a small WebAssembly kernel, spins up one worker per CPU core, and starts pulling work units from a coordinator somewhere on the internet. Every other person who clicked that button is doing the same thing, and together those tabs form a compute grid: the coordinator splits a big job into independent pieces, hands them out, checks the answers, and aggregates them into one global result. No install, no account, no signup. Close the tab and you are gone, and the grid does not care. The browser is the most widely deployed runtime in history, sitting on billions of mostly idle CPUs, and joining a distributed computation costs exactly one click.
That is the pitch. Now the catch, because this series is only worth your time if I am honest about it.
The honest catch
This idea probably loses to the cloud. If you need a lot of compute, you can rent spot instances for cents per hour, and they come with properties browser tabs will never have: they stay up, they are yours, and you can trust the results they return. A grid of volunteer browsers has none of that. Nodes vanish mid-computation because someone closed a tab. Nodes lie, because anyone can open dev tools and submit whatever bytes they like. To trust an answer from a stranger's machine you have to pay for it, and I will show you the real invoice later in the series: verifying untrusted work cost me between 2.5x and 2.9x the raw compute, measured, not estimated. Add browser sandboxing overhead and wildly uneven hardware, and the cloud wins the general case comfortably.
So why build it? Because the general case is not the only case, and the narrow ones are genuinely interesting. Volunteer and citizen-science computing has worked for decades (SETI@home, Folding@home, BOINC), and its biggest historical friction was the install. A browser grid removes it entirely: reach beats raw price when your compute is donated. Education is another one, because a distributed system you can join from your phone and watch heal in real time teaches more than any diagram. And underneath both sits a primitive with a life of its own: verifiable computation over nodes you do not trust. That problem is worth solving carefully even if the business case never shows up.
The series ends with a scorecard on exactly this question, and I will not spoil the verdict beyond what I have already told you. The point of the series is not "browser compute will change everything." The point is that building a real one, end to end, forces you through some of the best problems in distributed systems, and I have the receipts from actually doing it.
Why pi, of all things
Workload number one is estimating pi with a Monte Carlo method, and it earns its place. The method is almost embarrassingly simple. Take a square with a quarter circle inscribed in it. Throw random darts at the square. The fraction that lands inside the circle approaches the ratio of the areas, which is pi over 4.
inside = 0
repeat count times:
x = random() # uniform in [0, 1)
y = random()
if x*x + y*y <= 1.0:
inside += 1
pi ≈ 4 * inside / count
Convergence is slow, on the order of one over the square root of the number of darts, so a precise estimate needs billions of throws. For most purposes that makes Monte Carlo pi a toy. For this project it makes it perfect, because it has exactly the shape a browser grid needs:
- Embarrassingly parallel. Every dart is independent. A million darts on your laptop and a million on mine never need to talk to each other.
- Tiny I/O. A work unit is just
(seed, count)going out and{inside, total}coming back. A few bytes buy seconds of CPU work, which matters when your interconnect is a WebSocket over someone's home wifi. - Reproducible on purpose. Seed the random number generator and a work unit becomes a pure function: the same
(seed, count)produces the same{inside, total}, bit for bit, on any honest machine.
That last property looks like a footnote and is actually the keystone. If honest machines must produce identical bytes, then a machine that produces different bytes has told on itself. Checking work from strangers collapses into comparing answers, and that one design decision carries the entire trust story later in the series. The next part is where I make it real, in Rust compiled to WebAssembly, with a golden test vector pinned both natively and in the browser.
The thesis I am carrying into this
There is a second thread running through the series, and I want to name it up front: serverless-first is the right default for an early build.
Look at what this system needs. The kernel runs in visitors' browsers. The page that delivers it is static files on a CDN. The workers, the WASM, the consent screen, the local dashboard: all of it executes on machines I do not pay for, delivered by hosting that costs almost nothing and scales without me thinking about it. For a surprisingly long stretch of this project, "the infrastructure" is a directory of static assets.
Until it is not. Somewhere a global counter has to live. Someone has to hold the queue of work units, notice that a node died, and add up the verified results, and that someone must exist continuously in a way static hosting cannot provide. The most interesting infrastructure decision of the whole build is what to do at that moment: how small you can keep the one stateful thing, where it should run, and what happens when the obvious serverless answer meets a stateful WebSocket coordinator that cannot be horizontally scaled. That collision gets its own part, and it is the one where the thesis is genuinely tested rather than assumed.
Where the series goes
Eight parts, each one a real phase of the build with real numbers:
- This one. The idea and the honest catch.
- A deterministic pi kernel in Rust and WebAssembly, and why seeded randomness is the secret weapon.
- One browser, every core: Web Workers and a measured 10.7 billion darts per second on a 16-core machine.
- Where does a WebSocket coordinator live? Serverless-first meets its hardest case.
- Two browsers, one pi, and a grid that heals when you close a tab mid-work.
- Trusting math from strangers: redundancy, byte-equality, canary units, and catching a subtle liar.
- It was never about pi: making the grid workload-agnostic and running a prime counter through the unmodified core.
- Shipping it, the live numbers, and the honest scorecard.
By the end there is a real deployment you can visit, with billions of verified darts thrown by real strangers' browsers, and a clear-eyed answer to whether any of this is a product. Spoiler embedded in the framing already: the value is not where I expected it to be, and I think the honest accounting is more useful than the fantasy.
Next up: Estimating pi with Rust and WASM, where a seeded PRNG quietly sets up everything that follows.