{"id":315,"date":"2025-03-13T15:27:48","date_gmt":"2025-03-13T15:27:48","guid":{"rendered":"https:\/\/redmonk.com\/kholterhoff\/?p=315"},"modified":"2025-03-13T15:27:48","modified_gmt":"2025-03-13T15:27:48","slug":"new-typescript-compiler-who-dis","status":"publish","type":"post","link":"https:\/\/redmonk.com\/kholterhoff\/2025\/03\/13\/new-typescript-compiler-who-dis\/","title":{"rendered":"New TypeScript Compiler, Who Dis?"},"content":{"rendered":"

\"\"<\/p>\n

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 \u201cA 10x Faster TypeScript<\/a>.\u201d Frontend developers may worry that TypeScript is having an existential crisis. More on that later. But for most workaday devs TypeScript code isn\u2019t changing. Instead, it’s the engine under the hood that\u2019s seeing improvement. Anders Hejlsberg<\/a>, Microsoft Fellow and TypeScript\u2019s lead architect, explains<\/a> that by porting the TypeScript compiler and tools to Go they can now \u201cdrastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage.\u201d Sounds like an unmitigated glow up, but some folks in the JavaScript (JS) community like Evan You<\/a>, creator of Vue.js, have been less enthusiastic. So let\u2019s discuss.<\/p>\n

If you\u2019ve 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\u2019s compiler is too slow, especially compared to some newer tools. In fact, according to Matt Pocock<\/a>, independent educator at Total Typescript<\/a>, \u201cImproved performance has been the community’s most-requested feature for years.\u201d 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.<\/p>\n

\"\"<\/a><\/p>\n

Switching a compiler\u2019s programming language is noteworthy on a number of counts. For starters, it is not a new idea. In 2010 my colleague Steve O\u2019Grady wrote<\/a> about Facebook\/Meta\u2019s now defunct PHP transpiler, HipHop, whose value proposition was also speed. Next, Go was created by Google\u2014a competing hyperscaler\u2014so this move demonstrates Microsoft\u2019s relatively recent willingness to use technologies that weren\u2019t developed in-house. Armin Ronacher<\/a>, VP of Platform at Sentry, acknowledges Microsoft’s historically insular, Not Invented Here (NIH) vibe in his re-skeet<\/a> of Hejlsberg’s announcement.<\/p>\n

It\u2019s 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\u2019re essentially firing up a JavaScript engine to interpret all that code. It\u2019s like instructing a butler who then instructs the chef to cook your meal\u2013polite, 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\u2019s processor without that intermediary. It\u2019s more like a chef who\u2019s ready to cook as soon as you\u2019re hungry.<\/p>\n

The results are dramatic, and promise to significantly improve developer experience. Hejlsberg shares<\/a> 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\u00d7 improvements. On the Syntax podcast<\/a>, Hejlsberg mentioned they can compile the entire Node.js codebase in 5\u20136 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\u2019s IntelliSense and error squiggles will appear almost instantly instead of lagging behind their keystrokes. In practical terms: no more hitting \u201cbuild\u201d and then going for a coffee top-up; developers might not even have time to stretch before it\u2019s done.<\/p>\n

\"\"<\/a>
\nChart from “A 10x Faster TypeScript<\/a>” on Microsoft Dev Blogs.<\/sub><\/p>\n

So far, so good. But plenty in the community, like Maximilian Schwarzm\u00fcller<\/a>, a developer educator, expected a rewrite in Rust<\/a>, 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\u2019s a feeling that Rust could have delivered equal or greater speed. According to one Hacker News poster<\/a>:<\/p>\n

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)<\/p><\/blockquote>\n

Needless to say, the discussion on this point is lively. Although Microsoft\u2019s choice of Go has raised some eyebrows, they have solid reasoning. As Dr. Axel Rauschmayer<\/a>, who has authored several books on JavaScript and TypeScript, explains, the TypeScript team wanted to port the codebase as-is<\/a> 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\u00d7 speed in Go now rather than chase 15\u00d7 or 20\u00d7 with Rust years later.<\/p>\n

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\u2019s 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.<\/p>\n

It\u2019s important to note, however, what this change will not do. It won\u2019t make your actual web app run faster in production because TypeScript is erased at runtime. Remember, TypeScript\u2019s 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<\/a>, Senior Frontend Developer at Hygiena, explained when I chatted with him about the update: \u201cthis isn\u2019t going to magically make your website faster\u2026 it\u2019s developer tooling.\u201d So don\u2019t expect your bundle size or page load times to shrink\u2014this 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).<\/p>\n

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\u2019s 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\u2019t run a binary in the browser \u2013 you\u2019d have to compile it to WebAssembly (WASM). WebAssembly lets you run compiled code on the web, but here\u2019s the thing: Go\u2019s performance in WASM isn\u2019t exactly stellar right now.<\/p>\n

\n

While I agree Go is the the pragmatic choice for a 1:1 port, my biggest concern is Go's relatively subpar WASM performance.<\/p>\n

As a data point, esbuild's WASM build performs quite poorly in web containers, even slower than js bundlers like Rollup.<\/p>\n

In the screenshot below, looks\u2026 https:\/\/t.co\/moy4nG1NsS<\/a><\/p>\n

— Evan You (@youyuxi) March 12, 2025<\/a><\/p><\/blockquote>\n