Why Microsoft Is Rewriting the TypeScript Compiler in Go
A few months ago, Microsoft announced they’re rewriting the TypeScript compiler — not the language — from JavaScript (running on Node.js) to Go.
The goal?
Faster compiler performance, not faster TypeScript apps.
Think of It Like This:
If you're building cars and upgrade your car manufacturing machines, the cars themselves don’t suddenly drive faster. But now, you can build those cars much faster.
Same thing here:
- The TypeScript compiler is the manufacturing machine.
- Microsoft is rebuilding that machine in Go to make it faster and more efficient.
The language (TypeScript) itself stays the same.
What’s changing is the engine behind it.
Node.js Architecture Breakdown
For years, the TypeScript compiler has run on Node.js, which uses Google’s V8 engine (same as Chrome).
Here’s what powers Node.js:
- V8: Written in C/C++, compiles JavaScript to machine code using JIT (Just-In-Time) compilation.
- libuv: C library that handles async I/O like file access and network calls.
- Many of Node’s performance advantages come from these native under-the-hood parts.
But there’s a catch:
Node.js is great for I/O and memory-heavy work — but not for CPU-heavy tasks.
Examples:
I/O-bound (Node is good at):
- Database queries
- Network/API calls
- File system operations
Memory-bound:
- Parsing JSON
- Data transformations
- Routing HTTP requests
But when you throw CPU-intensive jobs at it (like compiling a codebase), Node slows down.
Why Node.js Struggles with Compilers
Node.js is single-threaded by default.
If one heavy task (like compiling) runs, it blocks the event loop, so:
- No new requests get handled
- Everything waits until that one job finishes
That’s a big problem for something like a compiler.
So... Is a Compiler CPU-Bound?
Yes — compilers are classic CPU-bound programs.
They don’t just read files or wait on databases. They do serious processing:
- Type checking
- Code analysis
- Transformations
- Output generation
These tasks hit the CPU hard — not I/O, not memory.
As TypeScript has added more features (generics, decorators, etc.), the compiler has gotten more complex and CPU-hungry.
Why Go Is a Better Fit
Go’s Superpower: Goroutines
Go has a built-in concurrency model — goroutines — which are:
- Lightweight threads
- Can run thousands at once
- Managed by Go’s own scheduler, not the OS
That means Go can:
- Type-check multiple files in parallel
- Transform code without freezing
- Generate output concurrently
- All without blocking anything else
Compare that to Node.js, which relies on workarounds (like worker threads) to get any kind of parallelism.
Another advantage: Go produces native executables — .exe for Windows, ELF for Linux, etc.
No need for:
- Node.js runtime
- JS engine like V8
- External dependencies
That makes it perfect for:
- CLI tools
- Build systems
- Fast startup and distribution
Compare this to Node.js:
- Needs V8 at runtime
- Slower cold starts
- More dependencies to carry
Microsoft’s Smart Move
Anders Hejlsberg said they evaluated multiple languages, and Go was the easiest to port the code base into. The TypeScript team has apparently created a tool that generates Go code, resulting in a port that's nearly line-for-line equivalent in many places. That might lead you to think the code is "doing the same thing," but that's a misconception.
This isn’t just a performance tweak — it’s a strategic shift in how dev tools are built.
What About Browser Support?
The current TypeScript compiler runs in browser tools like the TS Playground. But Go doesn’t naturally run in browsers.
So how could this work?
Possible Approaches:
1. WebAssembly (WASM)
- Go can be compiled to WASM
- Works in browsers
- Has limitations (e.g., no full multithreading)
Might be used for basic tasks (like playgrounds or small apps).
2. Cloud Compilation
- Browser sends code to a remote server running the Go compiler
- Server returns compiled output/errors
- Very scalable, browser stays lightweight
3. Dual Compiler Strategy
- Keep the JS-based compiler for browsers
- Use the Go compiler for CLI/build tools/IDEs
- Harder to maintain both, but possible
4. Lite Browser Version
- Stripped-down version for type-checking/syntax validation
- Could use WASM or JS under the hood
- Good enough for teaching and small projects
Microsoft hasn’t officially confirmed their plan yet.
These are educated guesses based on blog posts and engineering trends.
Final Thoughts
Microsoft’s decision to rewrite the TypeScript compiler in Go isn’t just about raw speed — it’s about building a modern, scalable toolchain that matches the complexity of today’s codebases. Go’s native concurrency, efficient memory usage, and ability to produce fast binaries make it a perfect fit for powering large-scale developer tools.
While this move introduces questions around browser support, the likely hybrid model (Go for CLI, JS/WASM for browser) shows that Microsoft is thinking long-term.
In the end, the language we write (TypeScript) stays the same — but the tools we use to build and scale with it are evolving. And that evolution, powered by Go, could shape the future of how fast, reliable, and portable our dev workflows become.
Top comments (0)