In an ambitious move to accelerate JavaScript and TypeScript developer workflows, Cloudflare and VoidZero have joined forces with Max Schwenk of Owner.com to develop tsrs, a faithful Rust port of the TypeScript compiler. Being incubated as part of the broader Oxc JavaScript compiler toolchain, the project is moving forward in close collaboration with the official TypeScript team. The overarching objective of this new initiative is to help developers minimize the time they spend waiting for code compilation and type checking, enabling a more seamless building experience. By making TypeScript significantly faster and more memory-efficient, the engineering teams hope to unlock new possibilities for running complete development environments in unorthodox places—most notably, directly inside the web browser.
Crucially, the creators of tsrs have emphasized that they are explicitly not forking TypeScript. The project leads firmly believe that the core TypeScript team should maintain absolute, uninterrupted control over the language’s design, features, and strategic direction. Having successfully guided TypeScript’s massive adoption across the entire JavaScript community over many years while preserving a cohesive long-term vision, the official team’s authority remains unchallenged by this new effort. The maintainers of tsrs note that while the official TypeScript team can move rapidly on many fronts, certain complex features require years of deliberate exploration and prototyping to determine the optimal implementation. A faithful Rust port must respect and closely follow those deliberate decisions; otherwise, it risks structural failure and eventual incompatibility. Consequently, tsrs is designed to strictly mirror the original implementation, leaving the responsibility of defining the language entirely in the hands of the official TypeScript creators.
Performance and Memory Improvements
Early benchmark results for the Rust-based port have proven exceptionally promising. When operating with an identical number of type-checking workers, tsrs achieves speeds up to eight times faster while consuming roughly 70 percent less memory than TypeScript 7.0. At the same time, the upcoming official version of TypeScript is also slated to introduce major performance gains. The TypeScript 7.1 beta release, for example, is up to 2.5 times faster than its predecessor, a leap made possible in part by upstreaming several optimizations originally developed within the tsrs project. The engineering teams intend to uncover and contribute even more optimizations as development continues.
In the broader developer tooling ecosystem, various independent TypeScript ports have recently circulated performance claims that often rely on heavy machine types and configurations deviating from standard defaults. To ensure absolute transparency and fairness, the tsrs team worked directly with the official TypeScript team to guarantee that comparative benchmarks evaluate identical configurations. By default, tsrs ships with an adaptive configuration tailored to the host machine type, sacrificing a modest amount of memory to deliver even higher execution speeds.
Developers interested in experimenting with the experimental release can install the package directly from npm using standard installation commands and run it locally to evaluate its performance on their own codebases.
Why Now?
Over the years, the developer ecosystem has witnessed numerous attempts to port TypeScript to alternative programming languages. Due to the immense complexity inherent in the language’s type system, historically only one such port has achieved widespread success: the TypeScript team’s own port of the compiler from JavaScript to Go.
However, the technology landscape has shifted dramatically with the advent of frontier AI models capable of assisting with large-scale code migration projects in a matter of days. This capability has recently spawned a wave of various experimental iterations, ranging from rough ports and faithful reproductions to fully re-architected versions of TypeScript written in systems languages like Rust and C++. This surge in activity underscores a persistent, industry-wide demand for faster tooling that can keep pace with modern codebase sizes.
Why Rust?
A natural question arises as to why a Rust port is necessary given that the official Go port already made TypeScript tenfold faster and far more memory-efficient than the legacy JavaScript-based version. The motivation extends far beyond raw compilation speed alone. Rust offers distinct architectural advantages, particularly when it comes to running workloads via WebAssembly.
The integration of Rust and WebAssembly boasts a long and stable history, anchored in the fundamentals of Rust’s memory management model. When compiling a language with automated garbage collection—such as Go—to WebAssembly, the runtime garbage collector must be bundled directly into the output binary. Rust, by contrast, relies on ownership and borrowing principles that allow for clean, predictable memory interactions between the WebAssembly guest environment and its host. This efficiency makes Rust a superior choice for lightweight, performance-critical WebAssembly deployments.
Cloudflare Workers have provided robust support for WebAssembly for quite some time, and recent engineering milestones have added native support for Rust inside Workers through a new Emscripten target for wasm-bindgen. When development and deployment systems are executed in tight continuous loops on edge infrastructure, minimizing the memory footprint translates directly into operational efficiency. This optimization makes it feasible to run fully encapsulated development environments in constrained environments where they were previously impractical. Combined with modern agentic workflows, developers can execute complete end-to-end toolchains within fully sandboxed edge environments, client-side browsers, embedded hardware, or Internet of Things applications.
How the ‘tsrs’ Port Will Be Maintained
To ensure long-term stability and prevent fragmentation, the tsrs project is consolidating its efforts. The team is actively working with Theo Browne to merge tsc-rs and tsrs into a unified package that comprehensively supports all features of TypeScript, including the Language Server Protocol and content mappers. Furthermore, the maintainers are adopting a successful synchronization strategy already proven through their work on vinext, an alternative implementation designed to stay tightly aligned with Next.js.
Under this maintenance model, automated agents review daily upstream code changes, fetch diffs, and generate tracking issues for any modifications that might impact compatibility. A continuous testing matrix runs the official TypeScript test suite against tsrs on a nightly basis. When discrepancies or test failures arise, agents can identify the divergence across both codebases, construct a reproduction, port the relevant tests, and propose a corrective patch. This disciplined synchronization process ensures that tsrs remains strictly aligned with upstream behavior without introducing unwanted divergence. Any localized performance enhancements discovered during this process will be actively contributed back to the official upstream codebase so that the entire community benefits.
While minor operational differences currently exist—such as variations in the precise ordering of diagnostic message outputs—the project aims to reduce these discrepancies to an absolute minimum ahead of a stable release.
What’s Next
Cloudflare already serves as a prominent host and supporter of numerous open-source Rust utilities that underpin the modern JavaScript ecosystem, including Vite, Rolldown, Oxlint, and Oxfmt. With millions of developers relying on its platform, the company has a vested stake in making foundational developer toolchains faster, more portable, and easier to deploy across diverse environments. Future experimentation will explore deeper integrations of tsrs into the existing stack, such as powering type-aware linting rules within Oxlint.
Ultimately, the goal for tsrs is to operate as a healthy, well-maintained open-source project that complements rather than competes with official TypeScript development. The Oxc team has already begun refactoring the underlying codebase to optimize speed, reduce memory consumption, and ensure long-term maintainability. With the official TypeScript team simultaneously exploring its own performance and memory enhancements for the compiler, the collaborative momentum between independent contributors and core maintainers promises to deliver faster, more efficient tools for the entire JavaScript and TypeScript community.
Leave a Reply