TypeScript's new compiler and why build speed matters

The TypeScript team rewrote the compiler from scratch — in Go. When I first heard about it, my initial reaction was surprise, then something closer to relief at seeing how right a decision it was. One tool for a language being rewritten in a completely different language might sound odd on the surface, but for anyone who works across multiple languages, it feels entirely familiar.

Why Go?

The old compiler was written in TypeScript itself. A language that bootstraps itself is elegant; but the JavaScript runtime has a ceiling: a single thread and the overhead that comes with interpreted code. A compiler — a program that walks thousands of files, parses them, and runs type checking — is precisely the kind of workload that suffers most from that ceiling.

Go, on the other hand, compiles to native machine code, has real multi-threading, and is designed exactly for this kind of systems tooling. The TypeScript team chose what fits the job, not what looks the most elegant. The announced goal was roughly a ten-times speedup; on my own mid-sized project, the transition turned “waiting for compilation” from a habit into a non-event.

Why build speed matters so much

“Ten times faster” sounds like a pleasing number, but the real point isn’t the number — it’s the feedback loop.

Imagine you make a type error. If the compiler tells you in two seconds, you’re still thinking about that code; you fix it and move on. If it tells you in fifteen seconds, you’ve already switched to another tab, your focus has scattered, and when you come back you’re thinking “where was I?” The real cost of a slow compiler isn’t the seconds you spend waiting — it’s the broken focus.

This loop lives in your editor too. Auto-complete, go-to-definition, rename — they all feed from the same type engine. When the engine speeds up, the editor speeds up; writing code becomes something fluid.

The language didn’t change — only the compiler

The most common misunderstanding about this transition is this: what changed is the program that compiles TypeScript, not the TypeScript language itself. The types you write, the syntax, the type rules — all exactly the same. So there’s nothing new to learn here; it’s the same job done much faster.

That makes the transition unusually low-risk. With most tooling changes, you need to learn a new mental model, train your team, redo your configuration. Here there’s nothing to learn — your codebase stays the same, type checking just comes back sooner. In my own project, the transition amounted to a few lines of configuration change.

It’s rare for a tool to deliver a gain this large at a cost this small. Most “big” improvements come with a learning curve and a migration pain. The gain here is nearly free — and that rarity shows how well thought-out the decision was.

A polyglot lesson

The lesson I take from this goes beyond TypeScript. A team moved the tooling for a language they’d been using for years into a different language, because that language was a better fit. They stayed loyal to the problem, not the language.

This is a large-scale example of an approach I’ve advocated for years: it’s perfectly reasonable to write application logic in one language and write the tooling for that application in another. Languages are tools, not identities. To choose the right tool, you first need to be familiar with more than one — and that familiarity pays off exactly in moments like this, when the right call actually gets made.