---
title: "TypeScript 7 went native."
date: 2026-07-13
url: https://remiam.co.uk/notes/typescript-7-native-compiler
tags: [Dev Tooling, TypeScript, Performance]
read_time_minutes: 5
description: "Remiam's take on TypeScript 7.0, the native Go compiler port: an 8 to 12 times faster type-check changes how a team builds, not just how long it waits."
---

# TypeScript 7 went native.

*Published 2026-07-13 · 5 min read · by Liam (Remiam)*

A compiler rewritten in Go made type-checking eight to twelve times faster. The number is not the point. What fast feedback changes about how you build is.

On 8 July TypeScript 7.0 shipped as a native compiler, rewritten in Go instead of JavaScript. Microsoft reports full-build speedups of roughly eight to twelve times. Type-checking the VS Code codebase fell from 125.7 seconds to 10.6, and opening a file with an error dropped from about 17.5 seconds to under 1.3.

A ten times faster compiler reads like a convenience, a shorter wait at the end of the day. It is more than that. Speed at this scale changes what you are willing to do. A check that takes two minutes gets run once, at the end, if at all. A check that takes ten seconds gets run constantly, and it stops being a chore and becomes a reflex.

## Fast feedback changes what you check.

When the type-checker is slow, teams route around it. They skip the pre-commit hook, they let CI be the first place types are ever checked, they merge on a green tick nobody watched go green. When it is fast, the check moves left, into the editor, into the save, into the loop you are already in. The errors you would have found on Friday you find on the keystroke. That is worth far more than the minutes saved on any one build.

## The editor numbers matter most.

The build figures get the headline, but the editor figures are the ones that change a working day. Opening a file with an error in the VS Code codebase went from about 17.5 seconds to under 1.3, roughly thirteen times faster. That is the line between a tool you wait on and one you forget is running. Memory came down too, by around a fifth on the larger projects. Here is the shape of it across a few public codebases.

| Codebase | TS 6 | TS 7 | Speedup |
| --- | --- | --- | --- |
| VS Code | 125.7s | 10.6s | 11.9x |
| Sentry | 139.8s | 15.7s | 8.9x |
| Bluesky | 24.3s | 2.8s | 8.7x |
| Playwright | 12.8s | 1.47s | 8.7x |

*Full type-check times reported by Microsoft, TS 6 versus TS 7.*

## A port, not a rewrite.

The interesting decision is that it is a port. The team moved the existing compiler to Go and kept its behaviour, rather than reimagining the language in whatever is fashionable this year. Porting is unglamorous and it is the right call. The value sits in the millions of lines that already compile, and a rewrite that quietly shifts semantics breaks all of them at once. We make the same call on client systems. When something works, you move it carefully and you do not use the migration as cover to redesign it.

## The caveats are real.

Two things to plan for. Strict mode and the earlier deprecations are now hard defaults, so a lax codebase will surface errors it had been hiding. And 7.0 ships without a stable programmatic API, with a new one expected in 7.1, so anything that drives the compiler directly, custom lint rules, codegen, some editor tooling, has to wait. For a studio the sensible order is to pilot 7 on the application code first, where the speed lands straight away, and hold the tool-chain plugins until the API arrives.

The lesson underneath the benchmark is an old one. Make the right thing fast enough and people stop avoiding it. A checker nobody waits for is a checker everybody runs.

## References

1. [Announcing TypeScript 7.0, Microsoft TypeScript devblog, 2026](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/)
2. [Announcing TypeScript 7.0 RC, Microsoft TypeScript devblog, 2026](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)