TypeScript Gets a Rust Heart: tsrs Is 8x Faster — and Agents Keep It in Sync

On October 20, 2026, Cloudflare announced tsrs on its official blog — a complete port of the TypeScript compiler to Rust. This is not another community "rewrite tsc" experiment: it is driven by Cloudflare together with VoidZero and Max Schwenk of Owner.com, incubated inside the Oxc toolchain, and — most importantly — built in close collaboration with the TypeScript team. Both sides are explicit: this is not a fork; the TypeScript team retains full control over the language's design and direction.

The most interesting part of the post isn't the "Rust is faster than Go" headline number. It's the least flashy section: the tsrs team plans to reuse Cloudflare's agent-driven process for keeping Vinext in sync with Next.js — each morning an agent reviews upstream changes and opens tracking issues, each night the compatibility matrix is regenerated, and when a gap appears, agents locate the change across both codebases, build a reproduction, port the tests, and propose a fix. The sync problem that haunted tsc for a decade is being hauled away overnight by AI. Here's what happened, and why the maintenance model matters more than the language.

What tsrs actually is

In one sentence: tsrs is a Rust port of the TypeScript compiler (and language server), aiming to be a drop-in replacement for TypeScript 7 — install it, and it should behave strictly like the official implementation. The repo oxc-project/tsrs is public under Apache-2.0, with a stated goal of 100% conformance.

The cast matters, because it rules out "slopfork":

• Max Schwenk (Owner.com) — the port's original author. His motivation was a bill: Owner.com's TypeScript codebase made routine type checking expensive enough to limit how many coding agents engineers could run at once.
• Cloudflare + VoidZero — Cloudflare wants the Workers/Wasm story; VoidZero is the Oxc toolchain team behind Vite, Rolldown, Oxlint, and Oxfmt. tsrs is being "incubated as part of the Oxc JavaScript compiler toolchain," pointing at a full Rust frontend toolchain.
• The TypeScript team — collaborating closely. Cloudflare stresses "not forking" twice: language design stays with the TS team, and the port must "preserve the TypeScript language strictly based on its original implementation."
• Theo Browne — Cloudflare is working with him to merge tsc-rs and tsrs into a single package supporting all of TypeScript's features, including LSP and content mappers.

Seen against the Oxc map, the ambition is clearer. The post names Cloudflare's existing Rust toolchain assets — Vite, Rolldown, Oxlint, Oxfmt: bundling, linting, and formatting are already Rust; the missing piece was type checking. With tsrs, a full Rust frontend toolchain from parsing to linting closes the loop. The post also previews deeper integration, e.g. type-aware lint rules in Oxlint. Type-aware linting has always been a luxury — slow and memory-hungry; many rules weren't unwritable, just un-runnable. If checking itself gets an order of magnitude faster, those rules become viable. This may be tsrs's fastest path to real-world impact, arriving before "replacing tsc."

An experimental release is already installable: npm install tsrs, then npx tsrs. There's also a browser playground (tsrs-playground.void.app) for zero-cost trials.

Reading the numbers honestly: 8x faster, 70% less memory

The headline: with the same number of type check workers, tsrs is up to 8x faster and uses ~70% less memory than TypeScript 7.0. The caveat first: these are vendor benchmarks — the post itself says "Early benchmarks ... are promising." Cloudflare claims it worked with the TypeScript team to align the test configuration, and third-party coverage (RuntimeWire) flags the claims as still self-reported. Direction: credible. Magnitude: awaiting independent reproduction.

The methodology is nonetheless detailed. The command was -p <project> --noEmit --incremental false --pretty false --checkers 4 across VS Code, MUI docs, webpack, and t3code server. Notable points:

• 8.10x on MUI docs (1.29s vs 10.44s on 7.0.2) and 8.08x on t3code server — the "up to 8x" isn't a single cherry-picked number;
• only 3.83x on VS Code (1.73s vs 6.62s) — gains depend heavily on project structure, so don't read 8x as a universal promise;
• memory wins are more consistent: 1.78 GiB vs 7.68 GiB on VS Code (0.23x), with all four projects in the 0.13x–0.31x range;
• TypeScript 7.1 beta is itself up to 2.5x faster than 7.0, and the post admits "some of these optimizations were upstreamed from tsrs" — tsrs is racing upstream while also arming it.

A third-party data point: Bun 1.4.3's release notes included an independent run (64-core machine, VS Code codebase) — tsrs 0.53s / 2.64GiB vs tsc 7 (tsgo 7.0.2) 9.79s / 7.52GiB vs bun check 0.87s / 2.86GiB. But the same post adds the key qualifier: default thread counts differed (tsgo used 4 threads, bun check used all cores); with 16 threads each, tsgo dropped to 4.54s and bun check to 1.49s — "the gap is real, but it is smaller than default settings suggest." Thread count is the easiest variable to game in these benchmarks; always ask before sharing a speedup chart.

One more nuance the post discloses itself: there are actually two charts. Everything quoted above is the "same configuration" comparison — equal worker counts for fairness. By default, tsrs ships an adaptive configuration tuned to the machine type that "uses more memory but is even faster." Remember the distinction: 8x/70% is fair-mode data; default mode makes different trade-offs. When third parties compare tsrs defaults against tsc defaults, ask about memory and threads on both sides first — exactly Cloudflare's own warning that rival ports' claims often come from "larger machine types and different options."

Why Rust: wasn't the Go port good enough?

Fair question — the TypeScript team already moved the compiler from JavaScript to Go (TS 7.0), which Cloudflare describes as "10x faster and far more memory efficient than the previous version written in TypeScript." So why port again?

Cloudflare's answer isn't "faster," it's WebAssembly. Compiling a Go program to Wasm means compiling Go's garbage collector into the binary; Rust's memory model enables straightforward memory interaction between a Wasm guest and host — the key reason Rust fits Wasm better. Combined with Cloudflare's bet: Workers has long supported Wasm, and recently gained native Rust support via the Emscripten target for wasm-bindgen. When entire build-and-deploy systems run in tight loops on Workers, a small memory footprint compounds fast — enough to run fully encapsulated development systems in places they couldn't run before: in a browser tab, a sandbox, an embedded device, an IoT app.

In developer terms: a complete TypeScript dev environment with type checking, running in a browser tab without sending your code to the cloud. That's the real long-term bet behind "spend less time waiting for code to be checked."

The post also drops an era-defining footnote worth quoting verbatim: "frontier AI models can now do large-scale ports almost independently in a matter of days." Years of porting attempts produced only one success — the TS team's own JS-to-Go port. Now "slopforks, faithful ports, and completely re-architected versions" in Rust and C++ are everywhere. Porting is no longer the moat; maintaining the port is — which brings us to the actual news.

Why frontend developers should care: type checking is a hidden tax

Every frontend developer pays it: a full tsc --noEmit on a large monorepo takes minutes. Type checking is often the longest step in CI; in the editor, the red squiggles lag half a beat behind your keystrokes. The VS Code repo dropping from 6.62s to 1.73s in the official benchmark is the difference between "save and get feedback" and "save and go make coffee."

Memory matters even more practically. A 7.68 GiB peak means beefy CI runners and screaming laptop fans; 1.78 GiB means cheaper CI configs and more parallel jobs per machine — real money for indie developers and small teams.

But the biggest variable is the agent era. RuntimeWire highlighted Schwenk's original motivation: Owner.com's codebase made routine checking expensive enough to limit how many coding agents could run at once — every type checker competes with coding agents for memory and CPU. When AI writes code in 10 seconds and tsc takes 3 minutes to verify it, the bottleneck moves from writing to checking. tsrs's real user may not be "humans who find tsc slow" but "fleets of agents that find tsc hungry." A checker using 70% less memory means several times more agents per machine — exactly Cloudflare's bet on stuffing full dev environments into Workers sandboxes.

There's also an underappreciated dynamic: tsrs isn't zero-sum competition with upstream — it's an external performance lab. TS 7.1 beta is up to 2.5x faster than 7.0, partly from tsrs-upstreamed optimizations. Port projects historically followed a fork-and-diverge script; tsrs chose "race plus transfuse": sprint ahead, send optimizations back. That works precisely because of the "not forking" commitment — with language design off the table, there's no incentive to split. Whichever side wins, TypeScript gets faster.

The real news isn't Rust — it's who keeps it in sync

Every compiler port dies the same death: upstream drift. The TypeScript team ships features and fixes every release; a port that falls months behind quietly becomes a different language. Cloudflare devotes a full section to how tsrs plans to survive — and the answer isn't "hire more people," it's handing upstream sync to agents.

The process is already battle-tested on Vinext (Cloudflare's Next.js-compatible implementation). Quoting the post: each morning, an agent reviews the changes, fetches diffs, and opens tracking issues for anything that could affect Vinext; every night, the compatibility matrix is regenerated as the Next.js test suite runs against Vinext. When a test or issue reveals a gap, agents "identify the change across both codebases, build a reproduction, port any relevant tests, and propose a fix."

tsrs will apply the same process to TypeScript, "taking extreme care that we don't introduce diverging behaviors," and will attempt to contribute performance improvements back to the TypeScript Go codebase "so everyone wins." Note the human role in this loop: set the rules, review the fixes — not chase upstream commits line by line. The endgame of the compiler wars may not be a language contest but a contest of who hands upstream sync to agents first. Upstream drift killed every previous port; agents happen to be excellent at exactly this kind of high-repetition, pattern-heavy, cross-codebase diff work.

One level deeper: the agent loop solves the most grinding part of port maintenance — deciding which upstream change affects you. TypeScript ships hundreds of commits per release; human maintainers triage by experience and changelogs, and one miss can introduce silent divergence. The agent approach is inverted: don't predict, just run everything — regenerate the full upstream test suite against tsrs every night and let failures reveal what fell behind. It's "trading compute for judgment": the test matrix is ground truth, and gaps surface themselves. Morning tracking issues cover known risks; the nightly matrix covers unknown ones — each backs up the other. That's why Cloudflare can claim "extreme care": care comes from process redundancy, not human diligence. The design philosophy to copy: don't make agents "understand" upstream; make the test matrix "judge" upstream.

For vibe coding readers, this section is worth more than the 8x number: it's a reusable template for agent-maintained large ports — morning review (change triage) → tracking issues (task decomposition) → nightly matrix (regression) → gap-driven locate/reproduce/port-tests/propose-fix (autonomous repair). If you maintain anything that must track an upstream — a framework fork, a compatibility layer, multi-language SDKs — this playbook is copyable today.

Note the trajectory: Cloudflare first validated "agents guarding upstream" on Vinext — the fast-moving, community-driven Next.js ecosystem. Now the same methodology moves to the TypeScript compiler — language infrastructure with an order of magnitude higher correctness bar. Agent maintenance is advancing from peripheral tooling toward core infrastructure. If tsrs tracks TypeScript's release cadence over the next year without divergence, it becomes the first large-scale public evidence that agents can maintain critical infrastructure long-term. That would hit the industry harder than any 8x number.

Honest caveats: it's experimental

• Known behavioral differences: the post admits differences such as the order diagnostics are printed, aiming to minimize them by the stable release. The repo README says "in our testing on existing projects, we have yet to find a correctness bug in tsrs" — a self-reported claim; treat it as unverified.
• Missing features: --init and --showConfig are unsupported for now; full LSP and content mappers await the tsc-rs merge.
• Vendor benchmarks: the 8x/70% configuration was reportedly aligned with the TS team, but project selection, hardware, and tuning are Cloudflare's. Independent runs agree on direction; magnitude is thread-sensitive.
• Upstream is catching up: TS 7.1 beta is up to 2.5x faster than 7.0 and already absorbs tsrs-upstreamed optimizations. tsrs's lead is a moving target, not a one-time verdict.
• One-way contributions: the issue tracker is open for bug reports (minimal reproduction required), but PRs are closed — "we don't have the bandwidth to review them."

What developers can do now

• Try it: npm install tsrs, then npx tsrs --noEmit on your own project and compare wall time and peak memory — or start with the zero-install browser playground.
• Watch conformance: the repo's compatibility-and-evidence page tracks supported features and known gaps, bench/RESULTS.md carries continuously updated benchmark data, and the release notes log each experimental release; the stable goal is "TypeScript 7.1 + 100% conformance" — that's the bar for production consideration.
• Evaluate Wasm scenarios: in-browser IDEs, type checking inside edge functions, or JS toolchains on embedded devices — @tsrs/wasm (wasm32-wasip1) belongs on your radar.
• Steal the playbook: morning review + tracking issues + nightly compatibility matrix + gap-driven autonomous repair — apply it to any project of yours that must track an upstream. That's tsrs's most reusable gift to the vibe coding community.

One more time-horizon note: TypeScript 7.1 is still beta, and tsrs's stable release targets 7.1 — setting up a rare three-way race in the coming months: the official Go build, tsrs in Rust, and Bun's bun check, all competing on performance and conformance against the same language version. That's good for developers: competition forces more honest benchmarks (threads, memory, project selection all under the microscope) and accelerates the flow of optimizations between the three camps. The second half of the compiler wars is just beginning.

A detail worth recording: the repo README ends with "Not affiliated with or endorsed by Microsoft." That's not boilerplate — it's the legal footnote to the "not forking" pledge: tsrs is a derivative work of TypeScript under Apache-2.0, the bundled lib.*.d.ts files remain TypeScript's, and the acknowledgments specifically thank the TypeScript team. In open source, license text and acknowledgments often reveal more about a relationship's true texture than pull requests do.

tsc was slow for a decade; what finally arrived wasn't just "a faster rewrite" but a port hauled away overnight by AI — days to port, agents to keep it in sync. Rust is the truck this move happened to use; the paradigm of agent-maintained large codebases is what stays on the road.