Cloudflare and VoidZero say their experimental Rust port of the TypeScript compiler is up to 8x faster and uses about 70% less memory than TypeScript 7.0. The benchmarks are the vendors' own, and the port is not yet stable.
On 20 October 2026, Cloudflare announced tsrs, a Rust port of the TypeScript compiler. Cloudflare and VoidZero are building it with Max Schwenk of Owner.com, and say they are working in close collaboration with the TypeScript team. The project is being incubated as part of the Oxc JavaScript compiler toolchain. An experimental release is on npm.
For a head of engineering the question is not whether Rust beats Go on a benchmark. It is whether this changes anything in your type-checking pipeline this year. Probably not yet. But it is worth understanding what is being claimed and what is not.
What Cloudflare says
The numbers come from Cloudflare's post, so treat them as the vendor's claims. Cloudflare says tsrs is up to 8x faster and uses roughly 70% less memory than TypeScript 7.0 when both run with the same number of type check workers. It says it worked with the TypeScript team to make sure the comparison used the same configuration.
Two caveats in the post matter for anyone reading benchmarks:
- Cloudflare says other recent benchmarks of TypeScript ports made various performance claims, often by using bigger machine types and different options than TypeScript's defaults.
- By default, tsrs ships with an adaptive configuration that depends on the machine type. Cloudflare says it uses more memory but is faster still. That means the default you install is not the configuration behind the headline memory figure.
There is also a moving baseline. Cloudflare says TypeScript 7.1 beta is already up to 2.5x faster than TypeScript 7.0, and that some of those optimizations were upstreamed from tsrs. The gap you would measure against the current beta is therefore smaller than the gap against 7.0. The text of the post gives no tsrs ratio against 7.1.
Not a fork
Cloudflare states plainly that it is not forking TypeScript and that the TypeScript team should stay in full control of the language's design and direction. The stated aim is a faithful port. The post argues that a port has to follow the TypeScript team's decisions closely or it will become incompatible.
That is the right risk to focus on. Cloudflare itself acknowledges there are some differences from upstream today, for example the order in which diagnostics are printed. It says it aims to reduce differences to a minimum by the time of a stable release. If your CI compares compiler output, parses it, or gates merges on it, that is the kind of difference that breaks things quietly.
How they plan to keep it in sync
Cloudflare describes the same process it uses to keep Vinext aligned with Next.js. Each morning an agent reviews upstream changes, fetches diffs and opens tracking issues. Each night a compatibility matrix is regenerated by running the upstream test suite against the port. Agents can then identify a change across both codebases, build a reproduction, port tests and propose a fix.
This is a plan, described by the people doing it. The post offers no track record for TypeScript specifically. Cloudflare also says it is working with Theo Browne to merge tsc-rs and tsrs into one package that supports all TypeScript features, including the Language Server Protocol and content mappers. That merge is described as work in progress.
Why Rust, according to the authors
Cloudflare's argument is partly about WebAssembly. It says that compiling a Go program to Wasm means compiling Go's garbage collector along with it, while Rust's memory model allows more straightforward memory interactions between a Wasm guest and host. It ties this to running development toolchains in sandboxed environments on Workers, in a browser, or on embedded devices.
That is a case for a specific use: type checking inside Wasm sandboxes, including agent workloads. If you do not run compilers in browsers or sandboxes, the Wasm argument matters less to you than the speed and memory figures.
Cloudflare also says it is considering deeper integration into its own stack, for example type-aware lint rules in Oxlint.
The context worth keeping
Cloudflare writes that only one earlier port of TypeScript succeeded, the TypeScript team's own move from JavaScript to Go, and that frontier AI models can now do large-scale ports almost independently in a matter of days. It reports seeing faithful ports, re-architected versions and what it calls slopforks. Our own reading, not Cloudflare's claim: if ports can be produced that quickly, buyers of tooling will see more of them, and will need to judge each on how closely it tracks upstream.
Cloudflare says a Rust port "has to follow those decisions closely, or it will eventually fall apart and become incompatible."
That sentence is the test to apply to tsrs over the coming releases.
What this means for your roadmap
Do not swap your production type checker on the strength of a vendor benchmark against TypeScript 7.0. Instead, install the experimental tsrs package in a branch, run it against your largest repository next to TypeScript 7.1 beta, and record time, memory and diagnostic output under the same worker settings. Check whether any tooling parses compiler output, since diagnostic ordering is a known difference (one example among the differences Cloudflare acknowledges). Revisit when a stable release exists and the merge with tsc-rs has landed.
Sources
- blog.cloudflare.com Introducing tsrs: a Port of TypeScript to Rust · 20 أكتوبر 2026
This briefing was researched and written by SKYLOGIQ's editorial pipeline: an AI writer and an AI fact-checking editor, with a human review queue for anything the editor refuses. Sources are listed above. How the Briefing is made