In an ambitious new collaborative effort aimed at accelerating the modern web development experience, Cloudflare, VoidZero, and Max Schwenk of Owner.com have joined forces to develop tsrs, a high-performance Rust port of the TypeScript compiler. Being incubated as part of the broader Oxc JavaScript compiler toolchain, the project is being carried out in close cooperation with the core TypeScript team. The overarching mission behind this initiative is straightforward yet impactful: to help software developers spend less time waiting for their code to be checked and significantly more time building applications. By making the TypeScript compilation process both faster and remarkably more memory-efficient, the developers hope to unlock new possibilities, such as bringing complete, robust development environments directly into the web browser and other resource-constrained environments.
To prevent any confusion within the developer community, the project leads have been explicit about their intentions: they are not forking TypeScript. The project team firmly believes that the official TypeScript team should retain absolute control over the design, evolution, and overarching direction of the programming language. Over the years, the TypeScript maintainers have successfully cultivated a long-term vision while guiding the language’s massive adoption across the entire global JavaScript community, and the creators of tsrs have no desire to disrupt that dynamic.
While the official TypeScript team is capable of moving quickly on many fronts, certain complex features require years of intentional exploration, philosophical debate, and prototype development before the ideal implementation can be determined. A faithful Rust port must track these careful decisions closely; otherwise, it risks fracturing, drifting out of alignment, and ultimately becoming completely incompatible with the upstream language. Consequently, the maintainers of tsrs stress that the project must preserve the TypeScript language strictly based on its original implementation, leaving the TypeScript team solely responsible for defining what those standards look like.
Performance and Memory Improvements
Early benchmarks of the new Rust port of TypeScript have delivered exceptionally promising results. Under standardized testing conditions using identical type check worker counts, tsrs has demonstrated speeds up to eight times faster while simultaneously consuming approximately 70 percent less memory compared to TypeScript 7.0.
These architectural gains are already bleeding back into the official ecosystem. The upcoming release of TypeScript 7.1 beta brings substantial performance enhancements of its own, making it up to 2.5 times faster than its predecessor. Notably, several of these core optimizations were originally upstreamed from the tsrs codebase, and the collaborating teams are actively looking for further opportunities to share optimizations.
In the broader landscape of modern tooling, developers have frequently encountered competing performance claims regarding various experimental TypeScript ports. These discrepancies often arise because different projects benchmark against larger machine types or alter compiler options away from standard defaults. To maintain transparency and accuracy, the creators of tsrs coordinated directly with the official TypeScript team to ensure that their published benchmarks utilize identical configurations.
Out of the box, tsrs ships with an adaptive configuration tailored to the host machine type. While this adaptive mode leverages additional memory resources, it pushes performance even further, unlocking maximum execution speeds for developers working on high-powered hardware.
For developers eager to test the experimental software, the tsrs package is currently available for evaluation via npm. Developers can install and test the package using standard command-line workflows, providing feedback to help refine the tool as it matures toward stability.
Why Now?
The pursuit of faster compilers is not entirely new. Over the years, the developer ecosystem has witnessed numerous attempts to port TypeScript into alternative languages. Due to the immense complexity involved in matching the intricate behavior of the TypeScript compiler, only one such port has historically achieved widespread success: the TypeScript team’s own port of the codebase from JavaScript to Go.
However, the technological landscape has shifted dramatically with the advent of frontier artificial intelligence models. Today’s advanced AI systems possess the capability to assist with large-scale code migration projects almost independently within a matter of days. This technological leap has catalyzed a new wave of experimentation, resulting in various "slopforks," faithful ports, and completely re-architected interpretations of TypeScript written in Rust or C++. These developments underscore a persistent, industry-wide demand for even faster TypeScript tooling.
Why Rust?
A common question raised by engineers when evaluating these initiatives is why a Rust port is necessary given that the official Go port already made TypeScript roughly ten times faster and significantly more memory-efficient than the legacy version written in JavaScript.
The rationale extends far beyond raw execution speed. Rust brings distinct architectural advantages, particularly when it comes to running workloads inside WebAssembly. The integration story between Rust and WebAssembly has always been robust, rooted deeply in Rust’s unique memory management model. When a developer compiles a Go program to WebAssembly, they are forced to bundle Go’s built-in garbage collector alongside the application binary. In contrast, Rust’s ownership-based memory model allows for streamlined, predictable memory interactions between a WebAssembly guest and its host environment. This fundamental difference makes Rust an exceptionally strong fit for memory-constrained WebAssembly use cases.
Cloudflare Workers have supported WebAssembly execution for quite some time. Recently, Cloudflare expanded this capability by introducing native Rust support in Workers through a new Emscripten target for wasm-bindgen. When development teams run entire software build and deployment systems in tight, continuous loops on edge infrastructure, the financial and operational benefits of a minimal memory footprint compound rapidly. It enables organizations to execute these heavy workloads so efficiently that fully encapsulated development systems can now operate in environments where they were previously impractical.
When combined with autonomous agents and automated workflows, this capability unlocks entirely new paradigms. Developers can execute complete toolchains end-to-end within fully sandboxed environments right on Cloudflare’s edge network. Simultaneously, the power of WebAssembly makes it entirely feasible to run those exact same development environments safely on the client side inside a web browser, on resource-constrained embedded devices, or within IoT applications.
How the tsrs Port Will Be Maintained
Sustaining a faithful port of a fast-moving compiler requires deliberate maintenance strategies. To streamline efforts, the project is collaborating with Theo Browne to merge tsc-rs and tsrs into a unified package. This consolidated project will support the complete feature set of TypeScript, including advanced components like the Language Server Protocol and content mappers.
Furthermore, the maintainers are drawing inspiration from their successful approach to maintaining Vinext, an open-source project that keeps Next.js running seamlessly on Vite. As outlined in previous technical documentation, the team utilizes automated agents to review upstream changes, fetch code diffs, and open tracking issues every morning for any modifications that might impact compatibility. Nightly runs regenerate the comprehensive compatibility matrix by executing the official test suite against the port. When a discrepancy or test failure is identified, automated agents assist engineers by pinpointing the relevant changes across both codebases, building precise reproductions, porting necessary test cases, and proposing robust fixes.
This exact maintenance methodology is being applied to the TypeScript port to ensure strict behavioral parity with upstream TypeScript. Whenever performance improvements are discovered during this process, the team intends to contribute those optimizations directly back to the official TypeScript Go codebase, fostering an environment where the entire community benefits.
While minor differences currently exist between the upstream compiler and the port—such as the exact formatting order in which diagnostic messages are printed—the development team is actively working to minimize these variances ahead of any official stable release.
What’s Next?
Cloudflare has long served as a prominent home for free and open-source Rust tools that underpin the modern JavaScript ecosystem, including projects like Vite, Rolldown, Oxlint, and Oxfmt. With more than 10 million developers building applications on its platform, Cloudflare maintains a vested interest in making foundational developer toolchains faster, more portable, and easier to deploy across diverse environments. Moving forward, the team plans to experiment with deeper integrations of tsrs throughout its internal stack, exploring use cases such as type-aware linting rules within Oxlint.
Much like the philosophy behind Vinext, the ultimate goal for tsrs is to foster a healthy, well-maintained open-source project that enhances developer workflows without creating friction for the TypeScript language itself. The Oxc team has already commenced extensive refactoring work on the codebase to optimize speed, reduce memory consumption, and ensure long-term maintainability.
With the official TypeScript team actively experimenting with its own internal memory and performance enhancements for the tsc compiler, the broader community stands to benefit from a renewed focus on performance. The collaborative momentum between Cloudflare, VoidZero, Owner.com, and independent contributors marks a significant step forward in the ongoing quest to build the fastest and most efficient developer toolchains possible.
