A faster programming tool can sound like an internal developer concern. But if your business relies on a website, app or digital product, the tools used to build and maintain it can affect how smoothly your team works. A new project from Cloudflare and VoidZero is exploring one way to make TypeScript development faster and easier to run in more places.
The project is called tsrs. It is an experimental Rust port of the TypeScript compiler, developed with Max Schwenk of Owner.com and in close collaboration with the TypeScript team. Its early benchmark results are promising, but it is not a finished replacement for TypeScript. For business owners, the useful question is not whether to switch immediately. It is what the project signals about development tools, portability and the need to choose technology carefully.
What Cloudflare and VoidZero are building
TypeScript is a language used in the JavaScript ecosystem. Its compiler checks code, and developers use its tooling while building and maintaining software. Cloudflare and VoidZero say their goal with tsrs is to reduce time spent waiting for code checks and make the tooling more memory-efficient. They are incubating the project as part of the Oxc JavaScript compiler toolchain.
The project is explicitly not a fork intended to take control of TypeScript’s direction. The TypeScript team remains responsible for the language’s design. That distinction matters: a separate implementation has to keep pace with decisions made in the original project, or the two could behave differently over time.
Cloudflare says it will work to keep tsrs aligned with upstream TypeScript. The team plans to use an ongoing process to review changes, identify compatibility gaps and propose fixes. It also aims to contribute performance improvements back to the TypeScript Go codebase, so improvements can benefit the wider ecosystem.
You can read Cloudflare’s announcement and technical explanation of tsrs. The project is available as an experimental npm package, but the announcement does not present it as a stable release.
Why a Rust port could matter beyond speed
The announcement reports that, in early benchmarks using the same number of type-check workers, tsrs is up to 8x faster and uses about 70% less memory than TypeScript 7.0. Those are project benchmark results, not a promise that every development team will see the same improvement. Cloudflare also notes that TypeScript 7.1 beta is already up to 2.5x faster than TypeScript 7.0, with some optimisations contributed from tsrs.
The comparison needs context. Cloudflare says it worked with the TypeScript team to use the same configuration for its reported benchmarks, because other comparisons may use different options or larger machine types. The project also offers an adaptive default configuration that uses more memory in exchange for greater speed. Performance depends on the configuration, so a headline figure alone is not enough to choose a tool.
The other important factor is where the tool can run. Cloudflare points to Rust’s suitability for WebAssembly, or Wasm, which can let software run in environments such as a browser. The announcement explains that Rust’s memory-management model can make interactions between a Wasm program and its host more straightforward than compiling Go’s garbage collector along with a Go program.
For a business, that possibility may matter if a development workflow needs to run in a constrained or isolated environment. Cloudflare describes use cases such as running development systems on its Workers platform, in a browser, on embedded devices or in IoT applications. These are possibilities the project could support; they are not evidence that every business needs to move its development tools into those environments.
What business owners should take from this
If your business has an in-house or contracted software team, the immediate value is awareness, not a forced migration. A compiler that becomes faster or runs in more settings could eventually help teams work with shorter waits or build more portable development environments. But the source describes tsrs as experimental and says some differences from upstream TypeScript remain, including the order in which diagnostic messages appear.
That difference is a reminder that compatibility is practical, not just theoretical. A tool can appear to work while producing different diagnostics or falling behind changes in the language. For a team maintaining customer-facing software, adopting an experimental compiler without checking its behaviour could add uncertainty to an already important workflow.
Ask your developers or technology partner whether TypeScript is part of your product’s development stack. If it is, ask whether slow checks or memory limits are a real constraint, and whether the current setup is affecting delivery. If those problems are not present, there may be no reason to change anything. If they are, the team can evaluate tsrs in a controlled way rather than making it the default for production work.
This is also a useful moment to review the foundations of your digital product. A business website, store or app depends on more than the language used to build it: clear requirements, maintainable code and sensible release practices matter too. If you are planning a new project or reviewing an existing one, explore website development options or app development with those priorities in mind.
How to assess an experimental development tool
A business owner does not need to judge Rust code personally. You can still ask questions that connect a technical experiment to business needs:
- What specific problem are we trying to solve? Ask whether code-checking time, memory use or the need to run tools in a particular environment is actually slowing the team down.
- What would we compare? Have the technical team test the current setup and tsrs under the same configuration and workload. Cloudflare’s own comparison emphasises using the same configuration.
- How will we check compatibility? Ask how the team would spot differences from TypeScript and keep the tool aligned as the original project changes.
- What is the fallback? Before testing an experimental tool, agree how developers can return to the established setup if the test reveals problems.
- What would justify wider use? Set a clear technical reason to continue testing, such as resolving a measured bottleneck, rather than adopting it because a benchmark looks impressive.
These questions help keep a technical trial proportionate. The point is not to block experimentation. It is to connect a tool change to a real business need and make sure the team can manage the risks.
What to do next
- Ask your development team whether TypeScript is used in your website, app or other software, and whether its current tooling creates a meaningful delay or resource constraint.
- Treat tsrs as an experiment, not a replacement. The project is still experimental, and Cloudflare says it aims to reduce remaining differences before a stable release.
- If there is a real bottleneck, request a controlled comparison. Ask the team to use the same configuration and representative work, then report both performance and compatibility findings.
- Keep the decision tied to your priorities. Consider faster checks or new deployment environments only if they support a defined need in your business.
The broader development is worth watching because it combines performance work with the possibility of running more of the development environment in portable, isolated settings. For now, the sensible response for most business owners is to understand the opportunity, ask informed questions and wait for evidence from their own team before changing established tools.
Sources
- Introducing tsrs: A port of TypeScript to Rust — Cloudflare Blog, Oct 20, 2026
This article was drafted with AI from the sources above, then published only after passing 20 automated checks: every figure must appear in the sources, links must work, and nothing may be invented. Spotted an error? Tell us and we'll correct it.
Want us to do this for you?
We help businesses across 3 continents implement everything you just read — and a lot more.