blog.rust.gay

Cloudflare announces tsrs, a Rust port of TypeScript

2026-11-06 · rust typescript tooling cloudflare

On October 20, 2026, Cloudflare announced tsrs, an experimental Rust port of the TypeScript compiler. Cloudflare said it is working with VoidZero and Max Schwenk of Owner.com on the project, which is being incubated inside the Oxc JavaScript toolchain. The post framed the work as a way to make type checking faster and more memory-efficient, including in WebAssembly environments, while leaving the TypeScript team in charge of the language's design and direction.

That framing matters. TypeScript tooling is a daily bottleneck for large JavaScript and TypeScript codebases: type checking sits in editor feedback loops, CI pipelines, and pre-commit hooks, and it scales with both the size of a project and the number of workers a team can afford to run. A faster implementation is not automatically a better one, but it can change the operational trade-offs of a compiler that many teams run dozens of times a day.

What Cloudflare announced

Cloudflare described tsrs as a faithful port rather than a fork. In the announcement, the company wrote that it does not want to take over TypeScript's design and that the TypeScript team should remain in full control of the language's direction. The argument is practical: TypeScript's team sometimes spends years exploring options before choosing an implementation, and a port that does not follow those decisions closely will eventually drift and become incompatible. Cloudflare said it intends to preserve the language strictly according to the original implementation.

The project is also a continuation of work the TypeScript team has already done. TypeScript was originally written in TypeScript and ran on JavaScript; the TypeScript team then ported the compiler to Go, which produced a large performance jump. Cloudflare presents tsrs as another experiment in the same direction, not as a replacement for the Go port or for TypeScript itself. The company also said it is working with Theo Browne to merge related work from tsc-rs into a single package that supports all of TypeScript's features, including the Language Server Protocol (LSP) and content mappers.

The benchmark claims and how to read them

Cloudflare published early benchmark numbers: tsrs was "up to 8x faster" and used about 70% less memory than TypeScript 7.0 when both used the same number of type check workers. The same post noted that TypeScript 7.1 beta was up to 2.5 times faster than TypeScript 7.0 in Cloudflare's comparisons, and that some of those optimizations had been upstreamed from tsrs. Cloudflare also said that, by default, tsrs ships with an adaptive configuration that depends on the machine type and uses more memory but runs even faster.

Those numbers are signals, not settled facts. They come from the project's announcement, and they depend on workload, hardware, checker configuration, and what exactly is being measured. Cloudflare said it worked with the TypeScript team to make sure the comparison used the same configuration, which is a good sign, but independent benchmarks will still matter if tsrs matures. The honest reading is that the project reports meaningful early gains on its own benchmarks, not that every TypeScript project will see an eightfold speedup.

Why Rust and WebAssembly

The most concrete technical argument in the announcement is about WebAssembly. Cloudflare said that compiling a Go program to Wasm means compiling Go's garbage collector along with it, while Rust's memory model makes interactions between a WebAssembly guest and its host more straightforward. That difference is presented as a reason Rust fits Wasm-heavy deployment targets.

The argument connects to Cloudflare's platform. Workers have supported WebAssembly for a long time, and Cloudflare recently announced native Rust support for Workers through a new Emscripten target for wasm-bindgen. If a development toolchain has a small and predictable memory footprint, it becomes practical to run that toolchain in places where a larger one would not fit: inside a sandbox on an edge platform, in a browser tab, on an embedded device, or in an IoT application. Cloudflare describes tsrs as a building block for that kind of end-to-end environment rather than only a faster local tsc replacement.

That is the part of the announcement with the clearest long-term implication. A faster compiler on a laptop is useful; a compiler that can run inside a constrained sandbox is a different capability. It is also the part that is hardest to evaluate today, because it depends on the rest of the toolchain — language service, package resolution, and all the other pieces a development environment needs — catching up.

Why not just keep the Go port?

Cloudflare anticipated the obvious question: the Go port already made TypeScript much faster, so why build another compiler? The answer in the post is not that Go is slow. It is that the two languages offer different deployment properties. Go's runtime and garbage collector come along when the compiler is compiled to WebAssembly, while Rust's memory model avoids that baggage and makes guest-host memory handling simpler. For Cloudflare, that difference is the point.

The company also framed the work as complementary rather than competitive. It said it plans to contribute performance improvements back to the TypeScript Go codebase, and it noted that the TypeScript team is experimenting with its own memory and performance improvements. In that reading, tsrs is a second implementation that tests a different set of trade-offs, not a vote against the official port.

Keeping a port honest

The hardest problem for any compiler port is not the first benchmark. It is staying compatible as the upstream language changes. Cloudflare addressed this directly and pointed to its experience maintaining Vinext, a compatibility layer for Next.js. Each morning, an agent reviews upstream changes, fetches diffs, and opens tracking issues for anything that could affect Vinext; every night, a compatibility matrix is regenerated by running the Next.js test suite against Vinext. When a test or issue reveals a gap, agents can identify the change across both codebases, build a reproduction, port relevant tests, and propose a fix.

Cloudflare said it will apply the same process to TypeScript, with the stated goal of avoiding divergent behavior. When the project finds performance improvements, it plans to contribute them back to the TypeScript Go codebase. That is a sensible strategy, and it is also an admission that the port's value depends on disciplined upstream tracking rather than on a one-time rewrite.

The approach is not a guarantee. Agent-assisted maintenance can find and reproduce differences, but conformance is ultimately measured by tests and by real projects. Diagnostic parity, edge-case type behavior, language service features, and the speed with which the port follows official TypeScript releases will all matter more than the announcement's benchmark chart.

Status, limits, and what to watch

tsrs is explicitly experimental. Cloudflare said the release has known differences from upstream TypeScript, including the order in which diagnostics are printed, and that it aims to reduce those differences to a minimum by the time a stable release ships. The project is available on npm as tsrs, and the oxc-project/tsrs repository describes it as a Rust port of the TypeScript 7 type checker.

Cloudflare also placed the project in a wider context. It noted that many attempts to port TypeScript to other languages have failed because of the complexity involved, and that only the TypeScript team's JavaScript-to-Go port had succeeded before. It added that frontier AI models can now produce large-scale ports in days, which has led to slopforks, faithful ports, and re-architected versions in Rust and C++. The existence of those projects shows demand for faster TypeScript; it does not show that any of them will stay compatible.

For readers trying to judge tsrs, the useful questions are concrete. Does it track TypeScript releases closely enough to be trusted in CI? Does it match diagnostics and type behavior on real codebases, not just benchmarks? Does the merged package with tsc-rs deliver the language service features that editors depend on? And does the Wasm story hold up outside a demo, once the full toolchain has to run in a sandbox?

Cloudflare is already the home of several Rust tools used across the JavaScript ecosystem, including Vite, Rolldown, Oxlint, and Oxfmt, and it says more than 10 million developers build on its platform. The company also said the Oxc team has begun refactoring the tsrs codebase to make it faster, use less memory, and stay maintainable, and that it is interested in deeper integrations such as type-aware lint rules in Oxlint. Those are signs of investment, but they are also promises about future work.

The reasonable conclusion is that tsrs is worth watching and not yet worth depending on. Its benchmark claims are strong enough to take seriously, its WebAssembly rationale is coherent, and its maintenance plan is more concrete than most port announcements. But the project is experimental, it has known behavioral differences, and its central promise — staying faithful to TypeScript while being substantially faster — is exactly the kind of claim that only time and conformance testing can settle.

Sources

← back to posts