TypeScript 7 Rewrites Its Compiler in Go for 10x

Let me set the scene. This is Microsoft — the company that spent the better part of the 90s trying to fork, embrace-extend-and-extinguish, or otherwise diplomatically relocate the open web to Redmond — telling you that they have made JavaScript faster by replacing it with Go. There's a version of that sentence that would have read as a threat in 1998. In 2025, it reads as a legitimate engineering decision, and the numbers are hard to argue with. I'm not sure whether that's a sign of how much Microsoft has changed or how much the rest of us have. Probably both.

TypeScript 7 just hit release candidate, and the headline is real: the TypeScript compiler has been rewritten from TypeScript itself into Go, and the team is claiming roughly 10x speed improvements. The Better Stack team ran the actual Playwright repository through both versions to check. The old TypeScript compiler chewed through approximately 1,400 files and completed in around 6 seconds. The TypeScript 7 RC finished the same job in 0.87 seconds. Same errors found. Same files processed. Same output, different runtime.

If you were compiling C code in 1994 and someone handed you a machine that ran it in one-seventh the time, you would have assumed they'd stolen it from a military lab. That's roughly the sensory category this falls into — not a incremental shave, but the kind of improvement that changes what you're willing to do. Build steps you were working around because they were too slow become steps you just run. That matters, especially in CI pipelines where developer patience expired around the third unnecessary five-minute wait.

Why JavaScript was always the wrong tool for this job

The TypeScript team's diagnosis is straightforward, and they're right: JavaScript was never designed for the kind of heavy, CPU-bound work that a type checker does. It's a scripting language that got extraordinarily good at a lot of things, but parallel computation across multiple cores was never on the spec sheet. As the Better Stack walkthrough explains: "the JavaScript compiler was single threaded, [but] Go can actually spread that type checking across multiple cores at once."

Go, by contrast, was built for exactly this kind of work. The Go rewrite decision was announced about a year ago, and the team's approach was disciplined: they ported the existing TypeScript implementation essentially line by line, preserving the type checking logic structurally before optimizing. The behavior is identical. The performance is not.

TypeScript 7 exposes two new flags that put the parallelism directly in your hands. The --checkers flag controls how many parallel type checker workers run at once, defaulting to four. The Better Stack demo showed that doubling it to eight on the Playwright codebase shaved roughly another third off the time — though with the expected tradeoff of higher memory usage. The --builders flag handles parallelization of project reference builds, letting you run multiple projects simultaneously.

The Better Stack presenter notes that combining both flags — four checkers and four builders, for example — means "you can have up to 16 type checkers running at once." That's a claim worth flagging: the multiplicative math comes from the video walkthrough rather than the official TypeScript 7 documentation, and the actual parallelism model depends on how checkers and builders interact at the process level. Check the TypeScript 7.0 RC announcement before tuning those numbers for production. What's not in dispute is the direction: you have real knobs now, and they do real things.

There's also a --single flag for enforcing single-threaded mode, useful for debugging or resource-constrained environments. In single-threaded mode on the same Playwright codebase, TypeScript 7 still ran in roughly 2 seconds — which is still three times faster than the old compiler running at full capacity. The native Go compilation overhead is doing that much work before parallelism even enters the picture.

The watch mode problem nobody talks about

Rewriting a compiler is one thing. Rewriting a compiler's watch mode — the component that monitors your filesystem for changes and re-runs type checking incrementally — is a different category of unglamorous. The Go standard library doesn't include built-in file watching APIs, which meant the TypeScript team had to solve this from scratch.

Their solution was to look at the Parcel bundler's file watcher, which Microsoft already uses in VS Code. The catch: it was written in C++. So they ported the relevant pieces of that into Go as well. That's a compiler rewrite that required a secondary C++-to-Go port of a file watching library as a dependency. The TypeScript evolution story is full of these unglamorous dependencies stacked on top of each other, and this one is no exception. The result, per the Better Stack walkthrough, is watch mode that works smoothly and outperforms the old implementation. Getting there took considerably more work than the headline number implies.

On breaking changes: the real news is TypeScript 6

Here's where I want to be precise, because the Better Stack framing is accurate but the implications are easy to misread.

If you're on TypeScript 6 and upgrading to 7, the answer is: there are essentially no breaking changes. The compiler rewrite preserved behavioral compatibility with TypeScript 6, which was the explicit goal of the Go port. The only language-level change in TypeScript 7 itself is that template literal types now preserve Unicode code points rather than splitting on UTF-16 code units. Previously, if you ran a type-level string operation on an emoji, TypeScript would split it in half — producing types corresponding to the high and low surrogate pair of the UTF-16 encoding. TypeScript 7 splits on whole characters instead.

The Better Stack presenter's reaction to this fix: "I would honestly be incredibly impressed if any of you have ever come across this in your time using TypeScript." I cannot improve on that. If this was a bug blocking your production code, you have been living an extremely niche existence, and I respect it.

If you're on TypeScript 5, the upgrade story is more involved — and the work is really in getting to TypeScript 6 first. TypeScript 6 removed the ES5 compilation target, dropped baseUrl, deprecated AMD, UMD, and SystemJS module systems, and updated various defaults toward modern ECMAScript. The Better Stack walkthrough suggests that TypeScript 6 made strict: true the default, but that characterization deserves a caveat: as of publicly available TypeScript documentation, strict mode has not been on by default in prior versions, and it's worth verifying exactly what TypeScript 6 changed on this front before adjusting your tsconfig expectations. The broader point holds — TypeScript 6 was where the past got cleaned out, and TypeScript 7 is where the speed lands.

One more timing note

The Better Stack video describes the stable TypeScript 7 release as expected "within about a month." That was accurate at time of recording, but given the gap between when this was filmed and when you're reading it, treat that as directional rather than a hard date. The stable programmatic API — the layer that tooling authors build on — is coming in TypeScript 7.1 rather than 7.0. A compatibility package lets you run TypeScript 6 and 7 in parallel in the meantime, which is a thoughtful provision for the ecosystem.

I've spent a lot of words in this job documenting the gap between what a technology promises and what it actually delivers. The compilers that were going to change everything and shipped as footnotes. The rewrites that introduced three new problems for every one they solved. The performance claims that held up on a MacBook Pro M3 and nowhere else.

TypeScript 7 is not one of those stories. Microsoft shipped the thing. It works. The numbers are real. A company that once treated JavaScript as a competitive threat to neutralize has spent years building the most widely adopted type system in the JavaScript ecosystem, and has now rebuilt its engine from the ground up because the old one wasn't fast enough. There's a timeline where that sentence is science fiction. In this one, it's the release notes.

Mike Sullivan covers the technology industry for BuzzRAG.