You’ve felt it. That 3-second pause when you save a file. The coffee-break-length build times on a Monday morning. The silent rage when your CI pipeline turns a 200-line PR into a 12-minute ordeal. You’ve blamed your machine, your dependencies, your config. But you never blamed the compiler.
Maybe you should have.
Enter Perry — a native TypeScript compiler written in Rust. Not a wrapper. Not a plugin. A ground-up reimplementation of TypeScript’s type-checking and compilation engine in a language designed to squeeze every drop of performance from your CPU.
The tooling ecosystem doesn’t evolve through consensus. It evolves through someone getting fed up enough to rewrite everything in Rust.
If you’ve been paying attention, this pattern should feel familiar. SWC replaced Babel. Turbopack is replacing Webpack. Rspack is replacing Webpack again. Biome is replacing Prettier and ESLint. esbuild — written in Go, but same spirit — replaced half your build chain overnight. The JavaScript ecosystem has been quietly undergoing a Rust (and Go) takeover for years. Every layer, from bundlers to linters to formatters, has been rewritten for speed.
But there was always one layer that felt untouchable: the TypeScript compiler itself.
Because TypeScript isn’t just a tool — it’s a language. Its compiler, tsc, is the source of truth. It defines what TypeScript IS. Every type rule, every edge case, every quirk that developers have learned to navigate over the past decade lives in that codebase. Replacing it isn’t like swapping Webpack for Turbopack. It’s like rewriting the dictionary.
Perry is attempting exactly that.
The promise is seductive: native-speed compilation. We’re talking about type-checking and emitting code at the speed of a Rust binary, not a Node.js process. For large monorepos, this could mean the difference between a 30-second type-check and a 3-second one. For CI pipelines, it could mean cutting build times in half. For developer experience, it could mean instant feedback — the kind that makes you forget the compiler is even running.
Speed is the most underrated feature in developer tooling. Not because it saves time — but because it changes how you think.
When your compiler is slow, you architect around it. You split types into separate files to avoid re-checking. You disable strict mode in certain directories. You add // @ts-ignore to dodge expensive inference chains. You build habits of avoidance. A fast compiler doesn’t just save seconds — it removes the cognitive tax of working around slowness.
But here’s where the story gets complicated.
TypeScript’s type system is not a spec. It’s a living, breathing implementation. The TypeScript team doesn’t publish a formal language specification that other implementations can follow — they publish tsc, and tsc IS the spec. This means any alternative compiler must reverse-engineer compatibility not from documentation, but from behavior. Every release of TypeScript adds new type system features (template literal types, satisfies operator, const type parameters, and more). Each one introduces subtle semantic rules that tsc handles implicitly.
Building a faster compiler for TypeScript isn’t an engineering problem. It’s a chase — you’re running after a target that moves every two months.
This is the fundamental tension of Perry. The Rust implementation can be blazing fast, but if it diverges from tsc’s behavior on even one edge case — one generic inference path, one conditional type resolution — it creates a bifurcation in the ecosystem. Your code type-checks with Perry but not with tsc. Or worse: it type-checks with both, but means different things. That’s not a bug. That’s a fragmentation event.
We’ve seen this movie before. Babel and TypeScript have had subtle disagreements about decorator semantics for years. The result? Developers learn to avoid the disputed territory, and the language effectively shrinks. If Perry and tsc diverge, the same thing happens — but at the compiler level, where the stakes are higher.
On the other hand, if Perry achieves and maintains compatibility, it becomes something more than a tool. It becomes leverage. Imagine a world where your IDE, your CI, your bundler, and your runtime all use Perry under the hood. Type-checking happens in milliseconds. Incremental compilation is instant. The feedback loop between writing code and seeing results collapses to near-zero.
The best developer tools don’t ask for your attention. They disappear — and let you focus on the thing you actually came here to do.
That’s the dream. The reality is messier. Perry is early. The TypeScript type system is vast, deeply weird in places, and constantly evolving. The team behind Perry is essentially racing to replicate a decade of accumulated compiler logic while the original team keeps adding to it. It’s like building a bridge while someone keeps extending the other side.
But here’s why it matters anyway: the Rust takeover of JavaScript tooling has been a one-way ratchet. Once a tool gets rewritten in Rust and people taste the speed, there’s no going back. Nobody voluntarily returns to the slow version. The question was never whether TypeScript’s compiler would eventually get the Rust treatment. The question was when, and who would be brave enough to try.
Perry is the answer. Whether it succeeds or fails, it marks a turning point. The last fortress of JavaScript’s native tooling is under siege. And the outcome — whether compatibility holds or fractures — will shape how every TypeScript developer works for years to come.
You don’t adopt Perry on day one. But you watch it. Because the moment it’s ready, every other TypeScript tool will have to answer one question: why are you still slow?
FAQ
Q: Can Perry actually replace tsc without breaking my codebase?
A: Not yet. Perry is early-stage and TypeScript's type system is a moving target with no formal spec. Any divergence from tsc's behavior — even on obscure edge cases — creates real risk. Watch it, test it on side projects, but don't bet your production build on it today.
Q: If Perry works, what changes for the average TypeScript developer?
A: Build times collapse. CI pipelines get faster. IDE feedback becomes near-instant. But more importantly, you stop architecting around compiler slowness — no more splitting files to avoid re-checks, no more disabling strict mode for performance. The compiler stops being an obstacle and becomes invisible.
Q: Isn't this just another rewrite that'll be abandoned in two years?
A: The pattern says otherwise. SWC, Turbopack, Rspack, Biome — once a Rust rewrite proves it's faster, adoption is irreversible. Nobody goes back to the slow version. Perry might not be the one that wins, but someone will. The Rust takeover of TypeScript compilation is a question of when, not if.