Skip to content

CLOUDFLARE 2026-10-20

Read original ↗

Introducing tsrs: a Port of TypeScript to Rust

Summary

Cloudflare, VoidZero, and Max Schwenk (Owner.com) announced tsrs, a faithful Rust port of the TypeScript compiler, incubated inside the Oxc JavaScript-compiler toolchain and developed in close collaboration with the TypeScript team. The stated goal is to make TypeScript checking faster and more memory-efficient so developers spend less time waiting — and so that complete development environments can run in more places, including in the browser. Early benchmarks put tsrs at up to 8× faster and using ~70% less memory than TypeScript 7.0 at the same worker count. The strong architectural claim is that Rust is a better Wasm compile target than Go for this workload because Go must ship its garbage collector into the Wasm binary while Rust's ownership model enables direct guest↔host memory interaction — which matters when you run whole build/deploy toolchains in tight loops on Cloudflare Workers or client-side in a browser. The project is explicitly not a fork: the TypeScript team retains sole authority over the language, and tsrs must track upstream's implementation decisions closely or drift into incompatibility.

Key takeaways

  1. Faithful port, not a fork. tsrs aims to preserve the TypeScript language "strictly based on its original implementation." The TypeScript team stays "solely responsible for deciding what that looks like" — because some TS features take years of intentional prototyping, and a port that doesn't follow those decisions closely "will eventually fall apart and become incompatible." (Source: sources/2026-10-20-cloudflare-introducing-tsrs-a-port-of-typescript-to-rust) This is a strict upstream-compatibility constraint as a first-class design goal.
  2. Performance / memory numbers. tsrs is "up to 8x faster and uses ~70% less memory compared to TypeScript 7.0 when using the same number of type check workers." Separately, the next TS release (7.1 beta) is already "up to 2.5x faster than TypeScript 7.0" — and "some of these optimizations were upstreamed from tsrs." By default tsrs ships an adaptive configuration dependent on the machine type that uses more memory but is even faster.
  3. Benchmark-methodology honesty. The post explicitly flags that other TS-port benchmarks often inflate results "due to using larger machine types and different options compared to TypeScript's defaults," and that Cloudflare worked with the TypeScript team to ensure its own benchmarks compare "the same configuration." A clean benchmark-methodology-bias caveat baked into a launch post.
  4. Why Rust over Go — the Wasm memory argument. TypeScript's own Go port already made tsc ~10× faster and far more memory-efficient, so "why isn't that enough?" The differentiator is WebAssembly: "When you compile a Go program to Wasm, you have to compile Go's garbage collector along with it. But Rust's memory management model enables straightforward memory interactions between a WebAssembly guest and host." Rust + Wasm's small memory footprint is the load-bearing advantage. (See systems/webassembly, concepts/memory-safety, concepts/binary-size-bloat.)
  5. Fully-encapsulated dev environments as the strategic payoff. Because Cloudflare already supports Wasm on Workers — and "just a few weeks ago" shipped native Rust in Workers via the new Emscripten target for wasm-bindgen — running build/deploy systems "in tight loops on Workers" makes a small memory footprint pay off fast. The end state: "run a development toolchain end-to-end in a fully sandboxed environment on Cloudflare," and with Wasm also "client-side in your browser, or on an embedded device, or an IoT application." This is the agent angle — "new possibilities when combined with agents."
  6. Why now — AI-assisted large-scale ports. Historically only one TS port succeeded ("the TypeScript team's port of TypeScript from JavaScript to Go") because of the complexity. Now "frontier AI models can now do large-scale ports almost independently in a matter of days," producing "slopforks, faithful ports, and completely re-architected versions of TypeScript in Rust or C++." There is "clearly a demand for even faster TypeScript." (See concepts/agentic-development-loop.)
  7. Consolidation of the ecosystem. Cloudflare is working with Theo Browne to merge tsc-rs (github.com/pingdotgg/ts-rust) and tsrs into a single package that supports all TS features including Language Server Protocol (LSP) and content mappers. Named-in-passing plain-text systems only.
  8. Upstream-sync maintenance model borrowed from Vinext. tsrs will be kept in sync with upstream TypeScript using the same agent-driven process Cloudflare uses for Vinext ↔ Next.js: "Each morning, an agent reviews the changes, fetches diffs, and opens tracking issues for anything that could affect" the port; "Every night, the compatibility matrix is regenerated as we run the" upstream test suite against the port; agents then "identify the change across both codebases, build a reproduction, port any relevant tests, and propose a fix." Performance improvements found in tsrs are contributed back to the TypeScript Go codebase "so everyone wins" — the upstream-while-you-integrate and upstream-the-fix disciplines applied to a whole-compiler port.
  9. Experimental today; known divergences. Installable now via npm install tsrs / npx tsrs (and a @tsrs/wasm package). The team acknowledges "some differences to the upstream version of TypeScript right now, like … the order in which diagnostics are printed," and aims to reduce them to a minimum before a stable release.
  10. Positioning in Cloudflare's OSS JS-toolchain portfolio. Cloudflare is "already the home of many free and open source Rust tools that power the JavaScript ecosystem, such as Vite, Rolldown, Oxlint, and Oxfmt." It plans deeper tsrs integrations — e.g. type-aware lint rules in Oxlint. The Oxc team is refactoring the ported codebase "to make it faster, use less memory, and make it maintainable."

Systems / concepts / patterns extracted

  • Primary system (new page): tsrs — a faithful Rust port of the TypeScript compiler, incubated in Oxc, developed with the TypeScript team, targeting Wasm-friendly speed/memory and fully-sandboxed dev environments. Clears the Systems gate as the article's primary subject (its architecture, rationale, maintenance model, and numbers are the whole body).
  • Enriched existing systems: systems/typescript (now ported to Rust as tsrs; the Rust-vs-Go-port distinction), systems/tsgo (Microsoft's Go port — the predecessor tsrs is benchmarked against and upstreams into), systems/webassembly (Rust-vs-Go Wasm memory-model argument; dev-toolchain-in-browser payoff), systems/go-compiler / Go runtime (the GC-ships-into-Wasm cost), systems/vinext (source of the agent-driven upstream-sync process reused here).
  • Named-in-passing systems (no page, no link — systems: frontmatter + plain text): Oxc toolchain, VoidZero, tsc-rs (ts-rust by Theo Browne), Vite, Rolldown, Oxfmt, @tsrs/wasm. These are single-source, mentioned-not-described; recorded as tags/prose only.
  • Concepts (map INTO existing vocabulary): concepts/backward-compatibility (strict track-upstream-or-break), concepts/memory-safety + concepts/binary-size-bloat (Rust's no-GC-in-Wasm footprint advantage), concepts/agentic-development-loop (AI models doing the port + the nightly-agent sync loop), concepts/benchmark-methodology-bias (same-config benchmark caveat).
  • Patterns (map INTO existing vocabulary): patterns/upstream-contribution-parallel-to-in-house-integration (ship the Rust port in-house while upstreaming perf wins to TS-Go), patterns/upstream-the-fix (contribute optimizations back so no divergent fork forms).

Operational numbers

  • tsrs vs TypeScript 7.0: up to 8× faster, ~70% less memory at the same type-check-worker count.
  • TypeScript 7.1 beta vs 7.0: up to 2.5× faster (some optimizations upstreamed from tsrs).
  • Default tsrs config: adaptive to machine type — trades more memory for even higher speed.
  • Upstream-sync cadence (inherited from Vinext): diff review + tracking issues each morning; compatibility matrix regenerated against the upstream test suite each night.
  • No absolute wall-clock, codebase-size, or per-machine memory figures are given; the ratios above are the only quantitative claims.

Caveats

  • Experimental release. npm install tsrs is an early/experimental build; known divergences remain (e.g. diagnostic print order differs from upstream), targeted for elimination before a stable release.
  • Benchmarks are ratio-only and config-sensitive. The post itself warns that TS-port benchmarks vary wildly with machine type and options; the 8× / 70% figures are "same configuration" against TS 7.0 specifically, not a broad representative suite. Treat as directional.
  • Compatibility is a moving target. A faithful port is only as correct as its sync process; the whole maintenance model exists because the upstream language keeps evolving and the port must not diverge.
  • Not a fork / not language authority. tsrs deliberately cedes all language-design decisions to the TypeScript team; it is an implementation, not a dialect.

Source

Last updated · 854 distilled / 2,448 read