TypeScript 7 is officially released! 🚨

#webdev #javascript #programming #opensource

Hello everyone! The long-awaited TypeScript 7 was finally released the other day. And the new features it brings are truly astonishing.

Several months ago I already wrote an article on this topic, but today I would like to write again about this event in programming.

Well, let's get started!

👀 What did they do?

First of all, it is worth noting that the implementation of TypeScript 7 is now done in the Go programming language. As Microsoft said, they tried to make the functions as close to the old code as possible in order to minimize bugs.

This was done to speed up the compilation of TypeScript code into machine-readable code, in short. Since VS Code runs on TypeScript, its speed is correspondingly increased. Editor operations now nearly instantaneous (e.g., finding first error in VS Code from ~17.5s to <1.3s). And not just a text editor.

To prove my point, let's check the performance benchmarks:

Benchmark 1: Compile Times Between Typescript 6&7

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

Benchmark 2: Aggregate Memory Usage in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7	Cumulative Memory
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

Benchmark 3: Performance with --checkers 8 in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7 (--checkers 8)	Speedup
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

These are the official benchmark results. And they're truly impressive. I can say that VS Code used to take quite a while to open on my old MacBook, but with these new features, everything will be much faster now.

⚙️ Functional changes

In addition to speed and rewriting all functions in Go, the following benefits are now added:

Performs parsing, type-checking, and emitting in parallel with experimental --checkers and --builders for fine-tuning microsoft

This gives developers complete control over the balance between performance and memory consumption. On CI runners or with limited resources, parallelism can be reduced without losing functionality.

New --singleThreaded for debugging or resource-limited environments

Solves a rather important debugging problem and ensures predictability of results when reproducing bugs.

Type-checking workers can be scaled without scaling builder workers

If you didn't know, type-checking workers handle complex type-checking logic, while builder workers assemble project references; their work is limited by the project dependency graph.

This means that now when setting parameters such as --checkers 6 and --builders 4 can be configured flexibly for each project to ensure the best project build performance.

The --watch mod has also changed, now it uses Parcel's file-watcher ported to Go for assembly, and eliminates expensive polling on large node_modules.

There are also some minor changes in JavaScript and in the configuration file, but overall they are not that important.

💬 My opinion

I believe that speeding up fundamental features like TypeScript, even if it's just rewriting functions in Go, has a significant impact on development. Websites today have quite a few modules and run on modern frameworks like Next.js, Remix, Nuxt, and many others. And they all still run on TypeScript, so it's difficult to comprehend how much time a tenfold speedup in version 7 will save. For developers, VS Code and the Cursor built on top of it will allow them to develop websites even faster.

What do you think about this? It will be interesting to read!

❤️ Thank you very much for reading the article!