On October 20, 2026, Cloudflare announced that it is working with VoidZero and Max Schwenk of Owner.com on tsrs, a project to port the TypeScript compiler to Rust. Developed as part of Oxc, a suite of JavaScript development tools, tsrs aims to speed up type checking, the process that verifies a program's types are consistent. In Cloudflare's initial benchmarks, with the number of type-checking workers held equal, tsrs achieved up to 8x faster performance and about 70% lower memory use than TypeScript 7.0.
The project is driven in part by the spread of AI agents in software development. In environments where agents repeatedly generate and modify code, type checking must run each time, putting a heavy load on both processing time and memory. If type checking could also run in memory-constrained environments and inside the browser, development tools could be used in a wider range of settings. Cloudflare's announcement and the developers' records show that the team is not simply swapping the programming language for Rust. It is also rethinking how type information is generated and retained, in order to achieve both speed and memory efficiency.
Up to 8x faster than TypeScript 7.0, but the comparison conditions matter
The up-to-8x speedup and roughly 70% memory reduction come from Cloudflare's own initial benchmarks. The comparison target is TypeScript 7.0, measured with the same number of type-checking workers. Adding workers parallelizes the work and can speed it up, but each worker consumes memory, so the relationship between performance and memory use changes with the execution conditions. In particular, the default adaptive settings use additional memory to speed up processing, so speed cannot be compared fairly while ignoring differences in worker counts or memory settings.
TypeScript itself continues to improve. According to Cloudflare, TypeScript 7.1 beta is up to 2.5x faster than 7.0, and some of that gain incorporates optimizations developed in tsrs. In other words, the performance gap between the Rust and Go versions is not fixed, and improvements made in tsrs have begun flowing back into TypeScript's Go implementation. The current gap should be understood as a measurement for specific versions and settings.
Mechanisms for reproducibility are also in place. As of October 24, the benchmark documentation defines a procedure for recording the commit of each project measured, its configuration, and the compiler hashes. The CI environment uses 8 virtual CPUs and 4 workers, disables file output and incremental processing, and runs 3 warm-up iterations followed by 10 measured runs. However, the documentation states that the saved result tables and charts are past measurements until they are updated with new data. The existence of this procedure does not mean the up-to-8x gap announced at launch has been independently reproduced.
19 GiB to type-check 37,000 files: porting to Rust alone did not solve the memory problem
Max Schwenk, who is leading the effort, explains the need for better memory efficiency based on his experience running large TypeScript projects at Owner.com. According to the development log he published on October 19, Owner.com type-checked about 37,000 files as a single program. Running TypeScript 7.0 on a single thread, memory use reached 19 GiB and the run took 80 seconds. In an environment where multiple AI agents each run type checks, the issue is not only how long one check takes but also how many can run at the same time.
The initial Rust port was faster than the Go version, but its memory use actually increased. Changing the language to Rust alone did not achieve the memory savings the team was after. The developers therefore reviewed how much data is generated during type checking and how long it is held in memory.
One key improvement is resolving a type's member information only when it is needed. TypeScript types contain member information such as properties, and building all of it up front means holding in memory information that the check never actually references. tsrs builds concrete type information only for the members the checker actually touches. By delaying computation until it is needed, it avoids generating and retaining unused type information.
The team also reworked data structure layouts to reduce the memory each piece of information occupies, and added a mechanism to release information about leaf files once their type checking is finished. This shrinks the stored data itself and avoids keeping information longer than necessary. Beyond rewriting the processing in a faster language, reconsidering which information is generated when, and how long it must be kept, is what led to the memory savings.
Parallel processing also had room for improvement. Each worker that performs type checking holds a type graph representing relationships between types, so adding workers tends to duplicate information about shared dependencies. tsrs therefore assigns files that use the same dependencies to the same worker where possible, reducing duplication. Simply splitting work more finely and adding workers can raise speed while also raising memory use, so the design treats parallelization and memory efficiency together.
That said, the effects of the individual improvements Schwenk described cannot simply be added together to derive an overall reduction rate, because the A/B tests used different versions and machines. Even so, the path is clear: starting from the first Rust port, the team improved how type information is generated and retained, and reduced memory use. Lower memory use per type check makes it easier to run multiple checks at once in environments with limited memory. However, no concrete results have been shown for how many more AI agents could actually run concurrently.
A second reason for choosing Rust: support for WebAssembly in the browser
Cloudflare cites compatibility with WebAssembly (Wasm), in addition to Rust's memory management model, as a reason for adopting the language. Go can also be compiled to Wasm, but Cloudflare points out that the runtime must include things like a garbage collector. The goal is not only to speed up type checking in native environments but also to let the TypeScript compiler run in more diverse environments, including the browser.
According to the Wasm package documentation as of October 24, the Wasm version of tsrs is the same Rust code as the native version, compiled for wasm32-wasip1. In the browser, it can read files prepared in memory and perform type checking, and it supports outputs such as JavaScript code, type declaration files, and source maps. The TypeScript standard library is bundled as well, so it can serve as a foundation for building type checking into in-browser code editors.
However, the features available differ between the native and Wasm versions. The native version supports parallel type checking across multiple workers, while type checking in the Wasm version runs on a single thread. The Wasm version also does not support file watching, LSP (Language Server Protocol), or an API server. The up-to-8x speedup measured for the native version cannot be assumed to carry over to the browser.
Based on the public repository's README and compatibility documentation as of October 24, the main differences are summarized below. Note that features described on the in-development main branch are not guaranteed to be available in every published npm package.
| Item | Native version | Wasm version |
|---|---|---|
| Type-check parallelism | Can distribute work across multiple workers; speed and memory use vary with worker count | Runs on a single thread; parallel type checking not supported |
| Speed | Cloudflare reports up to 8x faster than TypeScript 7.0 in initial measurements | No measurements supporting an equivalent speedup have been presented |
| Main constraints | Diagnostic compatibility with TypeScript and known diagnostic-ordering issues need to be checked | In addition to the native constraints, no support for watch, LSP, or the API server. Wasm linear memory is capped at 4 GiB per instance |
In the browser version, once the Wasm module has been loaded and initialized, compilation runs synchronously. The package does not automatically create a Web Worker, so callers must provide one if they want to keep type checking from blocking the UI. Wasm linear memory is limited to 4 GiB per instance, and lower limits may apply depending on the actual runtime. Being able to type-check in the browser does not mean huge repositories or every feature of a desktop editor can be handled as-is.
Separately, on September 28, Cloudflare also introduced an experimental preview of Emscripten support for running Rust applications on the web and in environments such as Cloudflare Workers. That effort is distinct from the WASI-targeted build used by the tsrs Wasm package, and the two should not be treated as the same implementation.
Speed is not enough: compatibility with TypeScript is key to practical use
For tsrs to replace the existing TypeScript compiler, the compatibility of its results matters as much as speed and memory use. The tsrs compatibility document takes TypeScript's Go implementation as the reference and states that any difference in diagnostic results is treated as a bug in tsrs. The aim is to match not just the type errors detected but also the order in which errors appear, the wording of messages, and exit codes. However fast a compiler is, if switching to it changes type-check results, it is hard to adopt in an existing development environment as-is.
In fact, the README as of October 24 lists a known issue in which errors can appear or disappear depending on the order in which checks run. A worker assignment method compatible with the Go implementation is available, but it does not guarantee deterministic results for every program. The team has set full compatibility with TypeScript 7.1 as the goal for the stable release and is working to resolve such issues.
The difference between in-development code and published packages also deserves attention. According to documents as of October 24, the main branch has been ported to match TypeScript 7.1 beta commit 3e9236361fa9. The published version 0.18.0, by contrast, corresponds to an earlier commit, b85298b6a81f, and version 0.19.0 is described as in preparation. Features and fixes progressing on the main branch are therefore not necessarily available in the published version installed locally.
Cloudflare says it will continue tracking changes made to upstream TypeScript and testing for compatibility. Future plans include integration with tsc-rs and support for features including LSP and content mappers. Extending Oxlint with type-aware capabilities is also under consideration, but these are all future development tasks, not features that are already implemented. Meanwhile, the policy of bringing optimizations discovered in tsrs back into the Go implementation could extend the benefits to developers who do not adopt the Rust version.
Anyone trialing tsrs at this stage should pin the version in use and check whether its diagnostics match those of the existing TypeScript. Then, by holding worker counts and measurement conditions constant and comparing type-check time and peak memory use, they can judge how much benefit they would see in their own environment. Those considering browser use should also verify that the single thread, memory cap, and unsupported features do not affect their actual use case.
The significance of tsrs is not just that it speeds up TypeScript type checking. By building only the type information that is needed and releasing data that is no longer required, its design also reduces the memory needed for checking. If the compatibility and runtime constraints are resolved, development environments where AI agents run type checks repeatedly, as well as browser-based development tools, should be able to use limited computing resources more efficiently.