Most TypeScript developers share one frustration: how long the compiler takes. For years there was nothing to do but accept it, since tsc was the only compiler TypeScript had.
Now that same compiler has been rebuilt. tsgo is the Go-based version of tsc that ships with TypeScript 7.0 beta, and it works exactly as tsc does, checking the same code by the same rules. What changes is the speed, with tsgo running close to ten times faster on large projects.
That is enough to make anyone want to move, but is this the right time to do it? To find out, I spent proper time with the beta. Here is everything worth knowing about tsgo vs tsc, where the new compiler already does better, where tsc is still the safer pick, and whether you should switch now or give it more time to settle.
tsgo vs tsc: A Quick Comparison
Here are the main differences between the two. I will explain each one below the table.
| What Matters | tsc | tsgo |
|---|---|---|
| Type-checking speed | Baseline | Around 10x faster on large projects |
| Memory use | Baseline | Roughly half |
| JavaScript output (emit) | Full support | Still in progress |
| Output targets | All, including older JavaScript | ES2021 and newer only |
| Decorators | Supported | Not supported yet |
| Watch and incremental builds | Supported | Still in progress |
| Editor and tooling support | Complete, full plugin API | Partial, maturing |
| Status | Stable, production-ready | Beta (@typescript/native-preview) |
tsgo vs tsc: Key Differences Explained in Detail
To understand whether tsgo is worth adopting, it helps to look at how it differs from tsc in the areas that matter most, including type-checking speed, memory usage, JavaScript output, and tooling support:
1. Type-Checking Speed
The first and biggest difference is the speed of type-checking. tsgo runs far quicker than tsc, and the way each one works explains why.
tsc uses JavaScript, so it depends on a separate program called Node.js to run. That dependency sits between the compiler and your machine and drags the speed down, so a single type-check on a large project can take more than a minute.
tsgo uses Go instead, so it runs on its own as a native program, with nothing sitting in between. This is exactly what makes it faster. Microsoft proved the gain on a codebase as large as VS Code, where a type-check that took 77.8 seconds on tsc dropped to 7.5 seconds on tsgo, close to ten times quicker.
2. Memory Use
The second difference is how much memory each compiler uses while it runs. tsgo runs much lighter than tsc.
tsc works on top of Node.js, and Node.js takes up a good amount of memory on its own. That cost comes on top of the memory tsc needs for the actual checking, so the total climbs quickly on a large project.
tsgo runs on its own, with no Node.js underneath it. The only memory it uses is what the checking itself requires, which works out to roughly half of what tsc needs for the same project.
3. Turning TypeScript into JavaScript
The third difference involves a job every compiler must handle beyond checking your code. A browser cannot run TypeScript directly; it only understands plain JavaScript. So before your app runs, the compiler must turn your TypeScript into JavaScript.
tsc does this fully. After it checks your types, it produces the final JavaScript, and it can output both modern and older versions so your code runs even on older browsers. It also supports extra features like decorators during this step.
tsgo does the checking part well, but this conversion step is still unfinished. Right now, it can only produce newer versions of JavaScript, and it does not handle decorators yet. So when you need the final JavaScript to ship your app, tsc is still the one that does the whole job.
4. Tooling and Stability
The difference here comes down to how each compiler fits the tools you already use. tsc supports the whole ecosystem today, while tsgo is still building that support.
tsc has shaped TypeScript tooling for years, so everything connects to it without effort. Editors use it to highlight errors, linters and build tools run on it, and plugins across the ecosystem depend on its interface.
In contrast, tsgo ships as a preview, so its support is still partial. Its editor integration remains thinner than tsc's, and many plugins cannot work with it yet, though each update narrows that gap.
tsgo vs tsc: Which Should You Use Right Now?
For most teams, the answer is to use both. tsgo and tsc run side by side without conflict, and each one suits a different job.
Give the type-checking to tsgo. It installs separately from tsc, so the compiler you already use stays in place. Each one has its own command, so they never conflict. Your current build runs just as before, with tsgo working alongside it.
The right moment to adopt tsgo depends on your project.
| Your Situation | What to Do |
|---|---|
| Large codebase with slow type-checks | Add tsgo for type-checking today |
| Heavy CI pipeline | Run tsgo there to cut wait time and memory |
| You depend on decorators or older targets | Keep tsc for the build, try tsgo for checks |
| Small, easy project | Either works, and tsgo is low-risk to try |
Getting this right the first time saves trouble later, and a TypeScript development services provider can set up your build and CI so both compilers work together cleanly.
tsgo vs tsc in Summary
After spending time with the beta, I came away impressed. tsgo is not here to replace tsc overnight. It is the same compiler as tsc, only much faster, and right now it already handles type-checking well.
For now, the smart move is to let each one do what it does best. tsgo gives you fast type-checking in your editor and CI, while tsc keeps producing the final JavaScript your users run. You get the speed today without giving up anything you depend on.
Once tsgo can handle the build too, moving to it fully will make sense. Until that day, running both is the practical choice. If you would like a hand getting there, you can hire TypeScript developers who have already put both compilers to work in production.
Top comments (0)