TypeScript is chugging an energy drink and sprinting laps around its old self. This week Microsoft announced a full migration of the TypeScript compiler to Go, and bragging of “A 10x Faster TypeScript.” Frontend developers may worry that TypeScript is having an existential crisis. More on that later. But for most workaday devs TypeScript code isn’t changing. Instead, it’s the engine under the hood that’s seeing improvement. Anders Hejlsberg, Microsoft Fellow and TypeScript’s lead architect, explains that by porting the TypeScript compiler and tools to Go they can now “drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage.” Sounds like an unmitigated glow up, but some folks in the JavaScript (JS) community like Evan You, creator of Vue.js, have been less enthusiastic. So let’s discuss.
If you’ve been using TypeScript on a sizable project, you know the pain: the larger the codebase, the slower the type-checking and compiling. Running tsc (the TypeScript compiler) on a big project can feel like watching paint dry. Over the years, developers have grumbled that TypeScript’s compiler is too slow, especially compared to some newer tools. In fact, according to Matt Pocock, independent educator at Total Typescript, “Improved performance has been the community’s most-requested feature for years.” Microsoft listened (and probably experienced the pain internally too). Thirteen years after its launch the Typescript team has decided to port the compiler in the lower-level, faster language Go.
Switching a compiler’s programming language is noteworthy on a number of counts. For starters, it is not a new idea. In 2010 my colleague Steve O’Grady wrote about Facebook/Meta’s now defunct PHP transpiler, HipHop, whose value proposition was also speed. Next, Go was created by Google—a competing hyperscaler—so this move demonstrates Microsoft’s relatively recent willingness to use technologies that weren’t developed in-house. Armin Ronacher, VP of Platform at Sentry, acknowledges Microsoft’s historically insular, Not Invented Here (NIH) vibe in his re-skeet of Hejlsberg’s announcement.
It’s also worth emphasizing that Go is much closer to bare metal than TypeScript. Moving from a high-level, interpreted language (JavaScript/TypeScript) to a low-level, compiled language (Go, Rust) brings tremendous speed gains. The current TypeScript compiler is written in TypeScript (which compiles to JavaScript), running on Node.js. That means every time you run the compiler, you’re essentially firing up a JavaScript engine to interpret all that code. It’s like instructing a butler who then instructs the chef to cook your meal–polite, but not the fastest route to dinner. By contrast, a Go implementation compiles down to machine code ahead of time, running directly on your computer’s processor without that intermediary. It’s more like a chef who’s ready to cook as soon as you’re hungry.
The results are dramatic, and promise to significantly improve developer experience. Hejlsberg shares some impressive benchmarks that, for example, the Visual Studio Code codebase (over 1.5 million lines of code) that took 77.8 seconds to type-check with the old compiler now takes about 7.5 seconds with the Go-powered compiler. The Playwright library (356k lines) dropped from 11.1s to 1.1s, while even smaller projects like date-fns saw ~9.5× improvements. On the Syntax podcast, Hejlsberg mentioned they can compile the entire Node.js codebase in 5–6 seconds now, whereas it previously took over a minute. For developers, shaving those seconds (or minutes) off build and type-check times means less thumb-twiddling and context-switching. Their IDE’s IntelliSense and error squiggles will appear almost instantly instead of lagging behind their keystrokes. In practical terms: no more hitting “build” and then going for a coffee top-up; developers might not even have time to stretch before it’s done.
Chart from “A 10x Faster TypeScript” on Microsoft Dev Blogs.
So far, so good. But plenty in the community, like Maximilian Schwarzmüller, a developer educator, expected a rewrite in Rust, the performance darling of many dev tools lately. Significant players in the JavaScript community have jumped on the Rust bandwagon (SWC, Deno, Rspack), and there’s a feeling that Rust could have delivered equal or greater speed. According to one Hacker News poster:
Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS / Parcel etc) and one of the reasons given is it has really great language constructs for parsers and traversing ASTs (I think largely due to the existence of `match` but i’m not entirely sure)
Needless to say, the discussion on this point is lively. Although Microsoft’s choice of Go has raised some eyebrows, they have solid reasoning. As Dr. Axel Rauschmayer, who has authored several books on JavaScript and TypeScript, explains, the TypeScript team wanted to port the codebase as-is as much as possible, rather than completely rewrite from scratch. Porting means taking the existing logic and structure and expressing it in another language, whereas rewriting means re-architecting everything. Anders and his colleagues at Microsoft make it clear: a full rewrite in Rust would take too long and risk too much. The implication is that they could get 10× speed in Go now rather than chase 15× or 20× with Rust years later.
For frontend developers working in frameworks like React, Angular, and Vue, this means less waiting and more coding. Big monorepos with tons of TypeScript files that used to make VS Code’s language server cry will load up with far fewer hiccups. Another area where developers will see improvements is with continuous integration (CI) and build processes. Many have CI pipelines that run tsc –noEmit just to do a type check, or that compile TypeScript before running tests. That step has often been one of the slowest in the pipeline. With a native compiler, CI builds will speed up.
It’s important to note, however, what this change will not do. It won’t make your actual web app run faster in production because TypeScript is erased at runtime. Remember, TypeScript’s job is done once it produces plain JavaScript output (or just checks types). By the time your code is running in a browser, the TypeScript compiler is out of the picture. As Alex Riviere, Senior Frontend Developer at Hygiena, explained when I chatted with him about the update: “this isn’t going to magically make your website faster… it’s developer tooling.” So don’t expect your bundle size or page load times to shrink—this is all about the development and build phase, not the end-user experience (although indirectly, faster tooling can lead to more optimized code or quicker iteration, which benefits users too, but I digress).
One of the biggest concerns I have seen raised by the community is tied to running the TypeScript compiler in the browser. Today, in some instances you can actually run TypeScript in a web page. The official TypeScript Playground works in this way, and it’s also used in online IDEs like StackBlitz, CodeSandbox, or VS Code for the Web. How? Well, since the compiler is written in JavaScript, they bundle it or dynamically load it and execute it right in the browser JavaScript engine. If the compiler is a Go binary, you can’t run a binary in the browser – you’d have to compile it to WebAssembly (WASM). WebAssembly lets you run compiled code on the web, but here’s the thing: Go’s performance in WASM isn’t exactly stellar right now.
While I agree Go is the the pragmatic choice for a 1:1 port, my biggest concern is Go's relatively subpar WASM performance.
As a data point, esbuild's WASM build performs quite poorly in web containers, even slower than js bundlers like Rollup.
In the screenshot below, looks… https://t.co/moy4nG1NsS
— Evan You (@youyuxi) March 12, 2025
Evan You voiced this worry on Twitter/X: “While I agree Go is the pragmatic choice for a 1:1 port, my biggest concern is Go’s relatively subpar WASM performance.” You points out that esbuild’s WASM build (esbuild is written in Go, and it offers a WASM version for browser use) performs poorly in the browser. In fact, it can be slower than JS bundlers like Rollup for in-browser operations.The upside is that the TypeScript team is aware of this, and efforts are ongoing to improve WASM support in Go (there’s even a discussion in Go’s GitHub repo), so this may improve over time.
And because it’s 2025, and there has to be an AI story, Hejlsberg argues performance improvements in TypeScript will have significant repercussions in our LLM-assisted present, explaining:
This new foundation goes beyond today’s developer experience and will enable the next generation of AI tools to enhance development, powering new tools that will learn, adapt, and improve the coding experience
While arguably an orthogonal concern, as developers move to create and consume more AI-native products, services, and systems, beyond just raw speed, performance improvements are a boon for developer tooling.
Microsoft’s decision to port TypeScript to Go is a big deal, and mostly in a good way. It addresses long-standing performance pain points with a pragmatic solution, uplevels TypeScript’s development experience, and ensures that as apps and codebases grow, the tooling keeps up. There are some concerns, namely about specific scenarios like in-browser usage, but the overwhelming community sentiment that I’m hearing is excitement.
Disclaimer: Microsoft, Google, and Sentry are RedMonk clients.
No Comments