How Running Code in the Browser Actually Works

An in-browser compiler needs two guarantees: the main page must never freeze, and the code it runs must be contained. Both come from the same primitive — the Web Worker. A worker is a separate thread with its own heap and no access to the page's DOM, which makes it a natural sandbox: expensive or hostile code runs out-of-sight, and the main thread can kill it.

One worker per run

The compiler creates a dedicated worker for every execution. Code runs only inside that worker, so it cannot touch the page's state, and because workers are process-isolated at the browser level, a runaway loop cannot block scrolling or typing. This is why a browser playground should never eval on the main thread — the single biggest architectural choice, and the boring one that prevents all the horror stories.

The async wrapper and top-level await

User snippets often want top-level await: fetch something, then log the result. The runner takes your source and wraps it in an async function built with new Function at the worker side, giving the snippet a real event loop to work with. Snippets then complete on their own schedule, and their console output is pushed back to the main page as the run progresses.

The 10-second kill switch

Every run is bound to a hard timeout. If the snippet has not finished in ten seconds — an infinite loop, a hung await, or plain slow work — the worker is terminated. Because the worker is a thread the browser can destroy, the page keeps responding even while the snippet is being killed, and a status message explains that the run timed out rather than leaving a mystery.

worker = new Worker(runnerUrl)
worker.postMessage({ code })
output = []
worker.onmessage = ({ data }) => output.push(data)
setTimeout(() => worker.terminate(), 10_000)

Capturing console output truthfully

The worker's console is patched so console.log and friends are forwarded as structured messages. The formatter handles the cases that JSON.stringify mangles: circular references are printed as Circular, BigInt values are printed with their n, and Error objects are rendered with their message and stack. What you see is what a careful console does — including the difference between a thrown Error and a logged value.

TypeScript: transpile fast, don't type-check

TypeScript in a browser runner cannot run a full type-check cheaply, so the compiler uses the TypeScript compiler API merely to transpile: transpileModule strips the types and emits ES2020 JavaScript. It reports no diagnostics, meaning type errors are not treated as run failures — exactly the behavior of ts-node's transpile-only mode or esbuild. Imports surface as syntax errors rather than being resolved, because a browser worker has no module graph nor server to fetch from.

Dart: a real sandbox via DartPad

Dart takes a bigger machine. The runner loads Google's DartPad SDK, which ships its own worker bootstrap, a lazy DDC incremental compiler that hot-reloads like an IDE, and a second sandboxed iframe where the compiled Dart (which runs as JavaScript) executes. The iframe is created with restricted sandbox flags, keeping Dart code away from the page. Two checks gate the whole pipeline: Web Workers and WebAssembly must be available, or the runner fails with a clear explanation instead of silently misbehaving.

Why this stays client-side

Try it

Open the Compiler and run a JavaScript, TypeScript or Dart snippet. Type top-level await, an infinite loop, or a circular object, and watch the sandbox, the 10-second kill switch and the circular-aware console work in one place.