Microsoft Just Shipped the Last TypeScript Written in JavaScript. That's the Whole Point.

The Macro: TypeScript’s Weight Problem Is Everyone’s Infrastructure Problem

Somewhere around 2018, TypeScript stopped being a preference and became an assumption. If you were starting a serious JavaScript project, you were probably starting it in TypeScript. The friction had dropped, the tooling had matured, and the alternative, which was shipping runtime errors you could have caught at compile time, looked increasingly indefensible.

That shift created something interesting. TypeScript isn’t competing with other type systems anymore, at least not directly. It’s competing with its own weight. As codebases scale into the hundreds of thousands of lines, the JavaScript-based compiler becomes the bottleneck. Build times slow. CI pipelines bloat. Engineers start skipping full type checks locally because they don’t have ten minutes.

Here’s what I think most people get wrong: they treat this as a TypeScript problem when it’s actually a success problem. You don’t rewrite your compiler in Go unless you’ve already won the market. The fact that Microsoft is doing this now, at peak TypeScript adoption, tells you the language has become critical infrastructure. That’s not a crisis. That’s a mandate.

This is the problem Microsoft is actually solving with the Go rewrite announced earlier this year. According to Visual Studio Magazine, they’re targeting 10x native performance gains with TypeScript 7.0. ByteIota reports the stable native compiler is aimed at early 2026. The timing matters too. The market research is messy (projections range from $21.7 billion in 2023 to $55 billion by 2032), but the direction is unmistakable. Developer tooling at scale is valuable, and infrastructure that millions of engineers depend on daily is only getting more valuable. Microsoft isn’t chasing a trend here. It’s protecting an investment that’s already too big to fail.

The Micro: One Release to Close the Old World and Open the New One

TypeScript 6.0 is, in the most literal sense, a bridge release. Microsoft has been explicit about that framing. The JavaScript-based compiler lives on through the 6.x series. TypeScript 7.0, the Go-native version, is where the architecture changes. So 6.0’s job is to prepare every codebase that will eventually need to make that jump.

What that looks like in practice: strict mode is now on by default. ESM-first configuration replaces the old CommonJS defaults. The compilation target moves to ES2025. These aren’t minor tweaks. For teams running legacy TypeScript configs, some of this will break things. That’s intentional. The deprecations here are specifically targeting patterns that won’t survive the native port, so the message is clear. Fix it now or get surprised in 7.0.

The additive features are genuinely useful. Built-in types for the Temporal API mean no more installing third-party date-time type packages and hoping they’re current. Map.getOrInsert lands as a standard method. RegExp.escape gets first-class support. None of these are revolutionary in isolation. Together they feel like the language finally catching up to what JavaScript itself has already shipped, which is a reasonable complaint to have had for a while.

The interesting product decision here is the deprecation strategy. Microsoft is essentially using 6.0 to force a cleanup pass across the ecosystem before the architecture switches underneath everyone. It’s a controlled disruption. You can argue about the timeline, and some engineers on LinkedIn apparently are, but the logic is defensible. Better to break things predictably now than chaotically during a compiler rewrite.

It got solid traction on launch day, which tracks. The TypeScript community is large and pays attention to official releases.

For teams already on strict mode and ESM, this upgrade is close to painless. For teams on older configs, the migration guide is going to get some real traffic. If you’re managing a large open source project, the same questions about tooling costs and compatibility that come up with things like AI-assisted coding workflows are going to surface here too.

The Verdict: This Works If and Only If the Migration Doesn’t Break

TypeScript 6.0 is doing exactly what it needs to do, and I don’t think most teams realize how important that is. This release isn’t trying to be exciting or innovative. It’s trying to be correct, and that’s the move that matters right now.

The defaults modernization is overdue. The deprecations are honest about where the language is going. The new API types are genuinely useful instead of performative. This is engineering for the long term, not for the announcement blog post. I respect that.

But here’s the real story: 6.0 is a load-bearing release for 7.0. If this version breaks a bunch of codebases and teams spend months cleaning up migration friction, Microsoft loses credibility right when they need it most. The 10x performance claim for 7.0 is a big number, and people will only believe it if 6.0 lands smoothly.

The one thing that determines whether TypeScript’s native compiler strategy actually happens is adoption velocity in the next 60 days. If large teams upgrade and the breakage is minimal, you get momentum into 7.0. If you get messy migrations and a bunch of frustrated blog posts about unexpected defaults changes, Microsoft has a real problem.

Here’s my prediction: 6.0 adoption will be faster than Microsoft expects because the upgrade path is genuinely reasonable, but it won’t be fast enough for them to hit their early 2026 timeline for the native compiler. They’ll ship it late, but when they do, the performance gains will be real enough to matter. TypeScript becomes infrastructure that actually feels good to use again.