You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/routes/blog/post/typescript-7-faster-with-go/+page.markdoc
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ To address this challenge, Microsoft recently confirmed a significant shift unde
15
15
16
16
Let's break down what this transition means, what's officially confirmed, and how it'll affect you as a developer.
17
17
18
-
### What does this mean for TypeScript?
18
+
# What does this mean for TypeScript?
19
19
20
20
Here's what we know so far:
21
21
@@ -26,7 +26,7 @@ Here's what we know so far:
26
26
27
27
Microsoft has not announced any changes to TypeScript's language features, syntax, or output because of this rewrite. The transition to Go is an engineering effort to improve performance and maintainability.
28
28
29
-
### Why Go specifically? Not Rust or C++?
29
+
# Why Go specifically? Not Rust or C++?
30
30
31
31
One question naturally arises: why Go specifically? While Microsoft hasn't provided a comprehensive breakdown comparing Go to alternatives like Rust or C++, they've [publicly shared](https://github.com/microsoft/typescript-go/discussions/411) some key factors:
32
32
@@ -38,21 +38,21 @@ One question naturally arises: why Go specifically? While Microsoft hasn't provi
38
38
39
39
**Long-term API design considerations:** The TypeScript team wants more control over internal compiler APIs. While Go's interop with JavaScript isn't as strong as some alternatives, moving to a more intentional API design will help modernize the ecosystem.
40
40
41
-
### Benchmark numbers: early results, still preliminary
41
+
# Benchmark numbers: early results, still preliminary
42
42
43
43
Perhaps the most attention-grabbing details involve benchmark numbers shared by Microsoft and industry publications. For instance, compiling the Visual Studio Code codebase (about 1.5 million lines of TypeScript) reportedly went from around 78 seconds with the current compiler down to roughly 7.5 seconds with the new Go-based compiler; a 10x improvement. Other large projects, such as Playwright and TypeORM, reportedly saw similar performance improvements (approximately 10x-13x faster).
44
44
45
45
These numbers come directly from early demonstrations and internal testing shared by Microsoft. But benchmarks at this early stage often represent idealized or carefully selected scenarios. Real-world improvements for diverse TypeScript projects may vary, and final figures might differ as the implementation matures.
46
46
47
-
### How will this affect tooling and ecosystem compatibility?
47
+
# How will this affect tooling and ecosystem compatibility?
48
48
49
49
A main concern among developers centers around compatibility with existing tools and integrations. Currently, TypeScript integrates smoothly with bundlers like Webpack, Vite, and esbuild, plus countless IDE plugins and language-server implementations.
50
50
51
51
Microsoft has publicly committed to maintaining compatibility and minimizing disruption throughout the compiler transition. Still, it's realistic to expect that tooling relying heavily on internal compiler APIs or deeply integrated TypeScript behaviors may require some adjustments. It's been [confirmed](https://github.com/microsoft/typescript-go/discussions/411) that the TypeScript team will initially support both the existing JavaScript-based compiler and the new Go-based compiler concurrently. This dual-compiler support would allow tool authors and ecosystem maintainers ample time to adapt without immediate disruption.
52
52
53
53
While Microsoft is prioritizing a smooth transition, developers and tool authors should prepare for minor integration adjustments, especially if their workflows rely directly on internal TypeScript compiler APIs.
54
54
55
-
### Timeline and versioning: what we know
55
+
# Timeline and versioning: what we know
56
56
57
57
Microsoft has confirmed that **TypeScript 7.0 will ship with the Go-based compiler** once it reaches feature parity with the current JavaScript-based version. Meanwhile, the existing compiler will continue under the **TypeScript 6.x** series, which will receive updates and breaking changes to align with the upcoming transition.
58
58
@@ -65,12 +65,12 @@ The rough timeline is:
65
65
66
66
For now, both compilers will coexist, allowing developers to upgrade at their own pace.
67
67
68
-
### What does this mean for you?
68
+
# What does this mean for you?
69
69
70
70
This transition changes how TypeScript is compiled but not how developers use it. The language itself remains the same, and the compiler will continue outputting JavaScript as before. The main difference is that builds should be significantly faster, with better performance in large projects.
71
71
72
72
That said, the new compiler is still in development, and benchmarks are early-stage. While Microsoft is working to maintain compatibility, some tools may need updates, and TypeScript 6.x will remain available for projects that aren't ready to switch immediately.
73
73
74
74
The long-term goal is for the Go-based compiler to fully replace the current one, but until it reaches full stability, both will be maintained in parallel.
75
75
76
-
We'll continue monitoring official announcements and detailed benchmarks as Microsoft progresses through this transition. Until then, you can remain cautiously optimistic: the future of TypeScript looks promising, and notably faster.
76
+
We'll continue monitoring official announcements and detailed benchmarks as Microsoft progresses through this transition. Until then, you can remain cautiously optimistic: the future of TypeScript looks promising, and notably faster.
0 commit comments