TypeScript 7.0 ships with Go compiler: 10x faster builds

Key Takeaways

• TypeScript 7.0 delivers 8x-12x faster builds through a complete compiler rewrite in Go
• Microsoft's VSCode (2.3M lines) now compiles in 10.6 seconds versus 125 seconds in TypeScript 6
• The Go-based compiler enables developers at companies like Slack to run full type checks locally again

Microsoft released TypeScript 7.0 on July 9, 2026, marking the first stable version to include the complete Go-based compiler rewrite. Build times drop by a factor of 10. VSCode's 2.3 million lines of code now compile in 10.6 seconds, down from 125 seconds in TypeScript 6.

The rewrite began last year as an experimental native Go implementation. Anders Hejlsberg, who co-created TypeScript to bring static typing to JavaScript, led the effort. The original compiler, written in TypeScript and executed by the V8 JavaScript engine, couldn't keep pace with modern codebases.

"TypeScript 7 brings native code speed, shared memory multithreading, and a number of new optimizations that typically yield speedups between 8x and 12x on full builds," wrote Daniel Rosenwasser, Microsoft Principal Product Manager, in the announcement.

How fast is TypeScript 7.0 in practice?

Microsoft published benchmarks against several large open source projects. The numbers are dramatic.

• VSCode (2.3 million lines): 10.6 seconds, an 11.9x improvement
• Sentry (1.9 million lines): 15.7 seconds
• Bluesky (628,000 lines): 2.8 seconds
• Playwright (528,000 lines): 1.47 seconds

The impact extends beyond build times. Editor responsiveness improves across the board. File opening, code search, and auto-completion all benefit from the faster language server. The sluggishness developers blamed on their text editor was often the TypeScript Language Server struggling to keep up.

Why did Slack's developers need this?

At Slack, the TypeScript codebase had grown so large that developers couldn't run full type checks locally. The language server was too slow. Type checking happened only on the continuous integration server, which meant developers discovered type errors minutes or hours after writing code, not seconds.

TypeScript 7.0 returns full type checking to the developer's machine. That feedback loop, from writing code to catching errors, shrinks from a CI round-trip to an instant.

Why Go instead of Rust or C#?

Microsoft choosing Go raised eyebrows. The company has its own C#, widely used in enterprise development. Rust has momentum in systems programming and growing adoption at Microsoft itself. Go barely cracks the top 20 on the Tiobe language popularity index.

Hejlsberg explained the reasoning in a Microsoft video: "It's the lowest level language we can get to that gives us full native-code support on all platforms." Go also excels at concurrency, which matters for parallelizing type checking across CPU cores.

Ryan Cavanaugh, TypeScript development team lead, added three more reasons in a FAQ discussion. First, Go's syntax resembles JavaScript, making it easier to port code and maintain both versions. The old JavaScript-based compiler will need maintenance for several more years.

Second, Go handles memory allocation well for this workload. For most compilations, TypeScript can turn off Go's garbage collector entirely, avoiding the GC pauses that plague long-running processes. "Go's model therefore nets us a very big win in reducing codebase complexity, while paying very little actual runtime cost for garbage collection," Cavanaugh wrote.

Third, and perhaps most pragmatic: the team knew Go. When you're rewriting millions of lines of infrastructure, familiarity reduces risk.

What does this mean for build pipelines?

CI/CD pipelines that run TypeScript builds will finish faster. For a VSCode-sized codebase, that's nearly two minutes saved per build. Multiply by the number of builds per day, and the time savings compound.

But the bigger win might be shifting type checking back to development time. When builds take minutes, developers batch changes and run checks less frequently. When builds take seconds, they check continuously. Errors surface earlier, when the context is still fresh.

Teams running TypeScript projects on Vercel or similar platforms will see faster deployments. The compile step that once dominated build time becomes a rounding error.

The native tooling trend continues

TypeScript's Go rewrite fits a broader pattern. The web development ecosystem is migrating from JavaScript-based tools to native implementations. Bun replaced Node for many projects. esbuild and SWC replaced Webpack and Babel. Turbopack, Vite, and Rspack compete on raw speed.

The motivation is always the same: JavaScript interpreters are slow compared to compiled native code. For small projects, it doesn't matter. For codebases with millions of lines, it's the difference between staying in flow and waiting for your tools.

Frequently Asked Questions

Is TypeScript 7.0 backward compatible?

Microsoft has maintained backward compatibility in previous major versions. The compiler is rewritten, but the language semantics remain consistent. Existing TypeScript code should compile without changes.

Do I need Go installed to use TypeScript 7.0?

No. The Go compiler was used to build the TypeScript toolchain, but the resulting binaries are standalone native executables. You install TypeScript as usual via npm.

Will the JavaScript-based compiler still be maintained?

Yes. The TypeScript team stated the old compiler will be maintained for several more years, though the Go-based version is now the primary implementation.

How does TypeScript 7.0 compare to Deno's TypeScript support?

Deno includes native TypeScript compilation, but it's a runtime, not just a compiler. TypeScript 7.0 improves the standalone compiler and language server that work with any runtime, including Node, Deno, and Bun.

Source: www.theregister.com