Cloudflare’s Rust port of TypeScript runs up to 8x faster

Cloudflare and VoidZero have taken over tsrs, a Rust port of the TypeScript compiler started by Max Schwenk of Owner.com. On October 20 they said they are building it together with the TypeScript team and incubating it inside the Oxc toolchain. An experimental build is already on npm.

The Cloudflare announcement says tsrs runs up to 8x faster than TypeScript 7.0 and uses ~70% less memory when both run the same number of type-check workers. The News Stack reports that Cloudflare director of engineering Christoph Nakazawa co-wrote the post with engineers Boshen Chen and Dimitri Mitropoulos. The stated goal is less time waiting for code to be checked, plus toolchains small enough to run in a browser. Agents are a big part of the pitch: a coding agent type-checks every change it makes, and on large TypeScript projects that step costs time and memory.

Who steers the language

“To be clear, we are not forking TypeScript,” the authors write. “We believe the TypeScript team should remain in full control of the language’s design and direction.” Their reasoning is an engineering one. The TypeScript team sometimes spends years on prototypes before it settles on how a feature should work, and “a Rust port has to follow those decisions closely, or it will eventually fall apart and become incompatible.”

Nakazawa made the same point on X: “We are not forking TypeScript – we are working with the TypeScript team and as a result 7.1 is already ~2.5x faster, too.” The blog says TypeScript 7.1 beta is up to 2.5x faster than 7.0 and that some of those optimizations were upstreamed from tsrs. From the TypeScript side, Rosenwasser said more in a Hacker News comment: “We even did our own Rust vibe port and what we currently suspect is that a lot of the speed does not just come down to language choice, and some of what is going to make TS 7.1 faster and leaner (see the charts in the blog post) actually comes from optimizations discovered in tsrs.”

To keep the port in sync, Cloudflare is reusing the process it built for Vinext, its reimplementation of Next.js. Every morning an agent reads upstream changes and opens tracking issues for anything that could affect the port. Every night the upstream test suite runs against it and the compatibility matrix is regenerated. When a gap turns up, agents build a reproduction, port the relevant tests and propose a fix. Performance improvements found along the way are meant to go back into the TypeScript Go codebase. Cloudflare is also working with Theo Browne to merge tsc-rs and tsrs into a single package that covers all of TypeScript’s features, including the language server and content mappers (the hook that lets the checker handle .vue, .svelte and .astro files). The company admits some behaviour still differs from upstream, the order in which diagnostics are printed for one, and says it wants those differences down to a minimum by the stable release.

Why Rust, after Go?

Microsoft shipped TypeScript 7.0 on July 8, 2026. It replaced the JavaScript-based compiler with one written in Go and was roughly ten times faster. The News Stack notes that Microsoft had considered Rust for that rewrite, but decided that reproducing the compiler’s existing architecture in Rust would cause serious problems with memory management and compatibility.

Cloudflare’s answer is WebAssembly. A Go program compiled to Wasm has to bring Go’s garbage collector along. Rust’s memory model allows straightforward memory interactions between a Wasm guest and its host, and Cloudflare says this is a key reason Rust fits the Wasm use case: memory efficiency. Workers have supported Wasm for a long time, and on September 28 Cloudflare added native Rust support through a new Emscripten target for wasm-bindgen. A small compiler, the company argues, lets a whole build-and-deploy toolchain run inside a sandbox on Cloudflare, and the same Wasm build could run in a browser, on an embedded device or in an IoT application.

On timing, the blog says TypeScript has seen many port attempts over the years, and the only successful one was Microsoft’s own port to Go. Frontier models, it argues, can now do large ports “almost independently in a matter of days”. Cloudflare uses that to explain the recent wave of “slopforks, faithful ports, and completely re-architected versions” of TypeScript in Rust or C++. In September, Bun’s 535,496 lines of Zig became Rust in eleven days with parallel Claude Code agents.

The numbers in agent terms

Schwenk’s own post on tsrs explains how the project started. Owner.com’s Olympus codebase has 37,000 files, and a single-threaded TypeScript 7.0 check of it took 19 GiB of memory and 80 seconds. “Even on a $3,000 MacBook with 36 GiB of memory, engineers couldn’t run several agents in parallel,” he writes. These are his labelled measurements on that codebase:

• tsgo 7.0.2, 4 checkers: 61.4 s, 36.0 GiB
• tsgo 7.1 nightly of September 29, 4 checkers: 43.4 s, 28.8 GiB
• tsrs 0.14.0, 4 checkers: 8.75 s, 6.1 GiB (7.0x faster and 5.9x less memory than 7.0.2; 5.0x and 4.7x against the 7.1 nightly)
• tsrs 0.14.0, default settings with 16 checkers: 4.24 s, 9.5 GiB

Here is what those memory figures mean in practice, ignoring the OS, the editor and everything else. On Schwenk’s 36 GiB MacBook, one full check by tsgo 7.0.2 at 4 checkers fills the machine, while tsrs at 4 checkers fits five at once. On 64 GiB the counts are one and ten. These are our own estimate, and a lower bound, since peak memory isn’t held for a whole run.

Cloudflare also warns that other ports’ performance claims often rely on “larger machine types and different options” than TypeScript’s defaults. It says it worked with the TypeScript team to make sure its own charts compare the same configuration. The tsrs default adapts to the machine and spends extra memory for speed. In the repo’s own table, its best result comes on a 16-vCPU CI machine running 16 checker threads against tsgo’s four.

Our analysis

What we checked

On October 21 we installed tsrs 0.18.0 from npm and recorded the version it reports. We also read the repository’s benchmark results, compatibility table and README, Schwenk’s post and the npm publish history.

How we check stories

The repo documents the speed and memory gains under its own conditions. We didn’t rerun them. The headline comparison is against 7.0, but the port tracks a later 7.1 development build, so the baseline and the port are on different TypeScript versions. Editor support is also further along than the merge plan suggests: the language server already ships, and what it still lacks is content mappers.

• The npm build reports itself as Version 7.1.0-dev.20260930.4. It ports a 7.1-dev commit and was published on October 19. The repo says tsgo and tsrs report the same errors on 9 of 17 projects, and it attributes the other 8 differences to changes in TypeScript between 7.0.2 and that commit.
• The repo’s same-checker benchmark ran on a 16-vCPU, 63 GB Depot CI machine against typescript@7.0.2. These figures come from the repo’s documentation; we did not measure them. With default settings (tsgo 4 threads, tsrs 16), the gain reaches 16.87x on mui-docs, from 12.66 s to 0.75 s.
• The figure The News Stack quotes, 19 GiB and 80 s, is from Schwenk’s single-threaded 7.0 run, not the multi-threaded comparison.

Repo suite, --checkers 4	Lowest	Highest
Wall-time gain	4.37x (Compiler)	11.81x (mui-docs, 12.69 s to 1.07 s)
Peak-memory reduction	2.19x (Compiler, 219 MiB to 100 MiB)	7.24x (mui-docs, 7.61 GiB to 1.05 GiB)

Trying it

Cloudflare’s instructions are two commands: npm install tsrs, then npx tsrs. In our sandbox the install pulled a 35 MB native binary through a platform-specific optional dependency (@tsrs/<os>-<arch>). Version 0.18.0 has no Windows package; the README says Windows x64 is configured for the next release. --init and --showConfig are not supported. The compatibility table marks JavaScript emit, declaration emit, --build, --watch and incremental builds as supported, and content mappers work in the CLI and in -b builds. The repo takes issues but not pull requests.

Cloudflare also plans deeper integrations, starting with type-aware lint rules in Oxlint, and says the Oxc team has already begun refactoring the codebase for speed, memory use and maintainability. For editor use, the language server starts with tsrs --lsp -stdio. It provides diagnostics, hover, go to definition, references, rename, completions with auto-imports, code fixes and formatting. It passes 4,074 of 4,546 fourslash groups (TypeScript’s language-service tests), and the docs include setup steps for VS Code and Neovim.