TypeScript 7 Ships a Native Go Compiler, Runtime Story Gets Stranger

On July 8, 2026, Microsoft shipped TypeScript 7.0 through the standard typescript npm package. The headline was not a new language feature. It was a number: full builds typically see 8x to 12x speedups, with roughly tenfold performance gains across the compiler, language service, and editor experience, according to Visual Studio Magazine. The team had rebuilt the compiler in Go and shipped it stable, which is a strange moment for a language whose users have spent the last few years being told they would not need a compiler at all.

That claim is called type stripping. The pitch is deceptively simple: run TypeScript directly by treating type annotations as whitespace, erasing them before execution so that the runtime never has to understand a union type or an interface. The consequence is a real thing called no-build TypeScript, a workflow without source maps or compilation delays, with stack traces that point at the original file. InfoWorld laid out the promise in January 2026: modern runtimes have incentives to make the compiler optional. TypeScript 7 just made the compiler dramatically better. Both things are true, and each one raises the other's cost.

The TypeScript team's decision to rebuild the compiler in Go, rather than iterating on the existing TypeScript-based implementation, is the strongest signal Microsoft has sent about where the bottleneck lives. The old compiler was itself written in TypeScript, which made it a beautiful proof of concept and an increasingly slow one as codebases crossed into tens of thousands of files. The Go-based native compiler is compatible with existing TypeScript semantics, ADTmag reported, but it changes the economics of the toolchain.

For five years, the default TypeScript workflow in a serious company was a build graph: install packages, compile, watch for changes, maintain a separate dist directory, then execute the JavaScript. Type stripping attacks the compile step from the bottom, inside the runtime. Node, Bun, and Deno now all treat .ts files as directly executable artifacts, with different constraints and different opinions about what kinds of TypeScript syntax are legal. The compiler rewrite attacks the same step from the top, inside the editor. What remains in the middle is a set of questions about how the language itself should age.

By treating types as whitespace, modern runtimes are unlocking a 'no-build' TypeScript that keeps stack traces accurate and workflows clean., InfoWorld

Node.js is the most consequential of the three runtimes, and its path to type stripping has been the most conservative. The project spent 2024 experimenting with an --experimental-strip-types flag, moved toward stabilization in January 2025, and kept the scope deliberately narrow, InfoWorld reported at the time. Node erases types but does not compile them. Features that require transformation, such as enums, namespaces, and parameter properties, are explicitly unsupported unless the code is first compiled with the TypeScript compiler. The runtime solves the common case and hands the long tail back to the compiler.

Deno landed in 2018 with the opposite instinct. It was built by Ryan Dahl, the original creator of Node, and it treated TypeScript as a first-class language from day one, compiling and type-checking on the fly. Deno 2.0, which arrived as a production release in October 2024, emphasized backward compatibility with Node and its npm ecosystem, InfoWorld reported. The clean-room vision had to make room for the installed base. Deno still ships native TypeScript support, but its long-term bet has shifted from purity to compatibility.

Bun took a third route. It pushed TypeScript as a default, erased types aggressively, and sold the whole runtime as a faster Node, with a built-in bundler, test runner, and package manager. Then, in December 2025, Anthropic acquired Bun to build out its AI coding tooling, Reuters reported via Yahoo Finance. The acquisition took the most aggressive Node challenger and assigned it a different job: serving an AI product rather than contesting the server-side JavaScript market. In one stroke, the competitive map changed, and so did the meaning of Bun as a language-community artifact.

The fragmentation looks technical, but it is mostly a difference in values. Node values stability and incrementalism, so type stripping arrived late and stayed deliberately narrow. Deno values standards compliance and security, then learned the cost of being incompatible. Bun valued startup performance and developer convenience, then became an infrastructure acquisition. Each runtime community is over-rotated on one thing, and the TypeScript team itself has been over-rotated on performance this cycle. The trade is always the same: compatibility with the ecosystem you already have versus fidelity to the idea you wanted.

What the compiler rewrite actually changes

For the users who live inside Visual Studio Code, TypeScript 7 changes the feeling of the editor. Project loads, completions, go-to-definition, and error surfacing all get faster without any change to how the code is written. The compatibility story matters less to them than the latency story. For users who care about deployment, though, the compiler rewrite changes very little by itself. The thing that used to run in the build pipeline was already a separate process with its own startup cost. A faster process lowers that cost but does not eliminate it.

Elimination is what the runtimes are selling. A Node developer on type stripping no longer needs to think about dist directories for the majority of small services and scripts. A Deno developer has been living in that world longer, but with the burden of knowing some TypeScript features require the full compiler anyway. A Bun shop starting in 2026 is unlikely to evaluate the runtime on its own merits because the ownership question has already been answered. The practical result is that a team's TypeScript workflow now depends on which runtime they are on, which editor they are in, and which subset of the language they use.

The language itself is being pulled in two directions at once. TypeScript 7 preserves existing semantics, which means every feature the compiler can lower remains part of the language. Type stripping, in every runtime that implements it, refuses to support some of those features unless the compiler has already transformed them. That is not a disagreement about how to implement anything. It is a disagreement about whether the language should have a runtime-facing subset that is strictly erasable, with the rest of the surface area treated as a compiler-only dialect.

The people cost in the middle

The maintenance cost of TypeScript 7 is not shared equally. The TypeScript team spent a significant chunk of 2025 and 2026 on the native port, and that energy did not go into features. The runtime teams maintain three different type-stripping implementations with three different compatibility matrices. Package authors who publish TypeScript cannot assume their consumers run the same toolchain. And the future readers of the code inherit whichever decision was made, often in a tooling setup nobody documented because the build step had become invisible.

That is the real people debate underneath the performance numbers. A language gets adopted because it solves a coordination problem: teams need shared types, shared tooling, shared refactoring. Fragmentation taxes that coordination. When TypeScript was the only layer between JavaScript and the compiler, one tool did the whole job. Now five tools touch the same .ts file: the editor, the compiler, the runtime, the package manager, and the CI pipeline. Each one has its own version of the truth about what TypeScript is.

The package authors and tool maintainers feel this first. A library that ships TypeScript with enums will work in a compiled environment and break under Deno's stricter checking. A CLI tool that shells out to the type checker now has to think about whether the host is using TypeScript 7, a native binary, or Node's erasure. None of this is catastrophic, but it is exactly the kind of small, chronic tax that makes a language feel older than its adoption numbers suggest.

What has aged well is the decision, made by the JavaScript ecosystem after years of argument, to converge on TypeScript as the default way to write browser, server, and tooling code. What has aged less well is the idea that one runtime would be the runtime. The three-way split among Node, Bun, and Deno is now a four-way split if you count the compiler itself as a platform. The people running these projects are not fighting over whether TypeScript succeeds. They are fighting over the definition of success.

The next checkpoint to watch is not another performance benchmark. It is whether the TypeScript team decides which language features are part of the erasable, runtime-facing subset, and then says so in public, in a way that Node, Deno, and Bun can each implement without drifting. That would cost the compiler team some backwards compatibility and force a conversation nobody has wanted to have. But it would also make the promise of no-build TypeScript true in the same way for everyone, instead of true in three different, slightly incompatible ways.