Porting TypeScript to Rust: how a fast port transforms the development
The initiative to reimplement the TypeScript compiler in Rust, known as tsrs, represents a collaboration between Cloudflare and VoidZero. They work closely with Max Schwenk from Owner.com. The project incubates as part of the Oxc toolchain. The central objective is to reduce code verification wait times. This allows developers to focus on building applications. This speed and memory efficiency opens the path to full development environments, accessible even in the browser.
Breaking news
DeepSeek Releases Open‑Source Inference Engine, Matching Nvidia’s Offerings
Beam moves app windows between Macs
AI Coding Tools Create a Midas Problem: Free Code Makes Features Worthless
Welsh data breach: Weak password and forgotten account expose 3,300 peopleRespecting the TypeScript Team's Authority
It is essential to clarify that this is not a fork of the TypeScript source code. The TypeScript team must remain the sole authority on language direction and design. This team has maintained a long-term vision, guiding TypeScript adoption in the JavaScript community. We do not want to change this dynamic. While the TypeScript team can advance quickly on some aspects, other features require years of exploration. Any Rust port must closely follow these decisions, or it will become incompatible over time. We must maintain fidelity to the original TypeScript implementation. The final decision belongs exclusively to the TypeScript team.
Initial Results of the Rust Port
The initial results of the Rust port are promising. Comparisons show tsrs is up to 8 times faster. It consumes approximately 70% less memory compared to TypeScript version 7.0. This assumes the same number of workers for type checking. It is visible that the next version of TypeScript, beta 7.1, brings significant improvements. It is up to 2.5 times faster than 7.0. Some of these optimizations were integrated back into tsrs. The team hopes to find more. Recently, various benchmarks for TypeScript ports with varying performance claims have emerged. This is often due to using larger machine types and different options. Working with the TypeScript team ensured the presented benchmarks compare the same configuration. By default, tsrs comes with an adaptive configuration. It depends on the machine type, using more memory but running faster.
Try the Experimental Version
You can try an experimental version by installing the tsrs package from npm. Use the command `npm install tsrs` and then run `npx tsrs`.
Why Now?
Over the years, there have been many attempts to port TypeScript to other languages. Due to complexity, only one port succeeded: the TypeScript team's port from JavaScript to Go. However, frontier AI models can now perform large-scale ports almost independently. This takes just a few days. We have witnessed the emergence of „slopforks”. These are faithful ports and fully restructured versions in Rust or C++. There is a clear demand for a faster version of TypeScript.
You might think the Go port already made TypeScript 10 times faster. It is also much more memory efficient. But it is not just about speed. Rust offers unique advantages, especially in the WebAssembly context. The Rust + Wasm story has always been strong. One fundamental reason lies in Rust's language design. When compiling a Go program for Wasm, you must also compile Go's garbage collector. Rust's memory management model allows simple memory interactions between WebAssembly guests and hosts. This is a key reason why Rust is a superior choice for Wasm use cases: memory efficiency.
Why Rust Specifically?
Cloudflare Workers have supported Wasm for a long time. A few weeks ago, we announced native Rust support in Workers. This came via the new Emscripten target for wasm-bindgen. When running full build and deployment systems in tight loops on Workers, the benefits of a small memory footprint are quickly visible. This means you can run these tasks so efficiently that it becomes possible to run fully encapsulated development environments in places where it was previously impossible. The combination with AI agents opens new possibilities. You can run a full development toolchain from start to finish in a fully isolated environment on Cloudflare. With Wasm, you can run these environments safely in the browser, on an embedded device, or on an IoT application.
Cloudflare Workers and Wasm
How will the tsrs port be maintained? First, we are working with Theo Browne to merge tsc-rs and tsrs. This creates a single package supporting all TypeScript features. This includes the Language Server Protocol (LSP) and content mapping. Second, we have had great success keeping Vinext synchronized with its upstream, Next.js. We explained this process in a recent article. Each morning, an agent reviews changes. It pulls diffs and opens tracking issues for anything that could affect Vinext. Each evening, the compatibility matrix is regenerated. This involves running the Next.js test suite against Vinext. When a test or issue reveals a deficiency, agents can identify the change in both codebases. They build a reproduction, port the relevant tests, and propose a fix. We will apply the same process for TypeScript. We take extreme care not to introduce divergent behavior from the upstream version.
Maintaining the tsrs Port
When we hit performance improvements, we will try to contribute them back to the TypeScript Go codebase. This way, everyone benefits. Finally, we acknowledge there are still some differences from the upstream version. For example, the order in which diagnostics are displayed. Our goal is to minimize these differences before release.