TL;DR
- Microsoft réécrit le compilateur TypeScript en Go. L'annonce date de mars 2025, le code est open-source.
- Les benchmarks montrent une compilation 10x plus rapide sur les gros projets. L'IDE (VS Code) sera aussi plus réactif.
- Ce qui ne change pas : la syntaxe TypeScript, ton code, tes configurations. C'est le compilateur qui change, pas le langage.
- Pourquoi Go et pas Rust ? Pragmatisme : Go est plus simple, le garbage collector simplifie le port, et l'équipe TS connaissait déjà Go.
- Date estimée : TypeScript 7.0, probablement fin 2025 ou début 2026.
L'annonce qui a secoué l'écosystème
Le 11 mars 2025, Anders Hejlsberg (le créateur de TypeScript, et aussi de C# et Delphi) a annoncé que Microsoft réécrivait le compilateur TypeScript en Go. Pas un wrapper, pas un binding -- une réécriture native complète.
La vidéo de démo a fait le tour de la communauté dev en quelques heures. Le compilateur Go compile le repo TypeScript lui-même en 1.2 secondes. Le compilateur actuel (écrit en TypeScript, exécuté par Node.js) met 12 secondes. Dix fois plus rapide, sur un projet réel, pas un benchmark artificiel.
Voyons ce que ça signifie concrètement pour les développeurs qui utilisent TypeScript au quotidien.
Pourquoi réécrire ?
TypeScript a un problème de performance qui s'aggrave avec le temps. Le compilateur est écrit en TypeScript, exécuté par Node.js, avec V8 comme moteur JavaScript. C'est élégant (le compilateur est écrit dans le langage qu'il compile -- on appelle ça le bootstrapping), mais ça a des limites.
Les problèmes concrets
Les gros projets souffrent. Un monorepo avec 500 fichiers TypeScript peut prendre 30 à 60 secondes pour un type-check complet. Avec les project references et le mode incrémental, ça descend, mais le premier check reste douloureux.
L'IDE rame. Le Language Server Protocol (LSP) de TypeScript -- tsserver -- est le même compilateur qui tourne en arrière-plan dans VS Code. Quand tu tapes et que l'autocomplétion met 2 secondes à apparaître, c'est tsserver qui galère à recalculer les types.
La mémoire explose. Sur les gros projets, tsserver peut consommer 2 à 4 Go de RAM. C'est un problème réel quand tu as 3 projets ouverts dans VS Code et que ton laptop a 16 Go de RAM.
La concurrence s'est accélérée. Des outils comme esbuild (Go), SWC (Rust), et Bun (Zig) ont montré que les outils JavaScript écrits dans des langages compilés sont des ordres de grandeur plus rapides. Microsoft ne pouvait pas rester les bras croisés.
Pourquoi Go et pas Rust ?
C'est la question que tout le monde a posée. Rust est le choix "évident" pour les outils de développement performants : SWC, Turbopack, Biome -- tous écrits en Rust. Alors pourquoi Go ?
Les raisons données par l'équipe TypeScript
1. La similarité structurelle. Le compilateur TypeScript utilise beaucoup de structures en arbre (AST), de parcours récursifs, et de patterns orientés objet. Go, avec ses structs, interfaces et méthodes, mappe bien sur ces patterns. Rust, avec son ownership model, aurait demandé de repenser fondamentalement l'architecture.
2. Le garbage collector. Le compilateur TypeScript actuel dépend du GC de V8. Porter vers Go, qui a aussi un GC, est plus direct que porter vers Rust, qui gère la mémoire manuellement. L'équipe estime que le GC de Go est suffisamment performant pour leur cas d'usage.
3. La productivité de l'équipe. Plusieurs membres de l'équipe TypeScript connaissaient déjà Go. Apprendre Rust en parallèle d'une réécriture massive aurait ralenti le projet de plusieurs mois.
4. La compilation rapide de Go lui-même. Go compile vite. Ça veut dire des cycles de développement courts pour l'équipe qui travaille sur le compilateur. En Rust, les temps de compilation du compilateur auraient été significatifs.
L'argument contre Go
Les critiques ont un point : Go n'a pas d'unions discriminées natives (enum types), ce qui est ironique pour un langage qui compile TypeScript (qui en a). L'équipe a dû implémenter ses propres patterns pour gérer les types union, ce qui ajoute de la complexité.
Go n'a pas non plus de generics aussi expressifs que Rust. Mais pour un compilateur, c'est moins critique que pour une bibliothèque générique.
Mon avis : c'est un choix pragmatique. Pas le choix "pur" que les fans de Rust auraient voulu, mais le choix qui permettra de livrer plus vite avec une équipe qui peut maintenir le projet.
Ce que 10x plus rapide change concrètement
Pour le type-check
| Projet | TypeScript actuel | TypeScript Go | Amélioration |
|---|---|---|---|
| Petit (50 fichiers) | ~2s | ~0.3s | 6.5x |
| Moyen (200 fichiers) | ~8s | ~0.8s | 10x |
| Gros (1000+ fichiers) | ~35s | ~3.5s | 10x |
| Monorepo enterprise | ~90s | ~8s | 11x |
Ces chiffres viennent des benchmarks internes de Microsoft et de la communauté qui a testé les premières builds. Ils sont cohérents : le gain est plus important sur les gros projets, ce qui est logique (plus de données = plus de bénéfice de la parallélisation et de la gestion mémoire native).
Pour l'IDE
C'est là que le gain sera le plus visible au quotidien :
- Autocomplétion : de 500-2000ms à 50-200ms sur les gros projets
- Go to definition : quasi-instantané
- Refactoring (rename, extract) : 3 à 5x plus rapide
- Mémoire : réduction de 50-70% de l'empreinte mémoire de
tsserver
Si tu travailles sur un monorepo TypeScript et que VS Code te fait régulièrement attendre, c'est la mise à jour qui va te changer la vie.
Pour la CI/CD
Le type-check est souvent la partie la plus lente d'une pipeline CI TypeScript. Passer de 90 secondes à 8 secondes, c'est une économie réelle :
- Feedback plus rapide sur les PR
- Moins de temps d'attente pour les devs
- Réduction des coûts CI (moins de minutes de compute)
Ce qui ne change PAS
C'est important de le souligner, parce que beaucoup de gens ont paniqué :
Ton code TypeScript ne change pas. Pas une virgule. Le langage reste le même. La syntaxe reste la même. Les types restent les mêmes.
Ton tsconfig.json ne change pas. Les options de compilation restent identiques. strict, noImplicitAny, target -- tout pareil.
Tes dépendances ne changent pas. Les @types/* packages continuent de fonctionner. DefinitelyTyped reste pertinent.
L'écosystème ne casse pas. ESLint, Prettier, les frameworks -- rien n'est impacté. C'est le compilateur qui change, pas l'interface qu'il expose.
Ce qui change, c'est le moteur sous le capot. Comme quand ta voiture passe d'un moteur thermique à un moteur électrique : l'expérience de conduite est la même (voire meilleure), mais les performances changent.
Le calendrier
L'équipe TypeScript a annoncé le plan suivant :
- Mars 2025 : annonce et repo open-source du compilateur Go
- Mi-2025 : preview publique avec les features les plus utilisées (type-check, LSP basique)
- Fin 2025 : parité fonctionnelle avec le compilateur actuel sur les cas courants
- TypeScript 7.0 (probablement début 2026) : le compilateur Go devient le défaut
Le compilateur actuel (TypeScript 5.x/6.x) continuera d'être maintenu en parallèle pendant la transition. Microsoft ne va pas casser l'écosystème du jour au lendemain.
Ce que ça dit de Microsoft et de TypeScript
Au-delà de la technique, cette annonce envoie un signal fort.
Microsoft investit sérieusement dans TypeScript. Réécrire un compilateur, c'est un investissement de plusieurs millions de dollars en temps d'ingénierie. Ce n'est pas un projet secondaire.
TypeScript n'est pas menacé. Certains prédisaient que TypeScript allait être remplacé par des outils de type-checking plus rapides (comme les annotations de type dans les commentaires JSDoc, ou le proposal TC39 pour des types natifs en JavaScript). La réécriture en Go montre que Microsoft parie sur TypeScript pour les 10 prochaines années.
La tendance "outils JS en langages compilés" continue. Après esbuild (Go), SWC (Rust), Biome (Rust), et Turbopack (Rust), c'est le compilateur TypeScript lui-même qui rejoint le mouvement. L'ère des outils de dev en JavaScript pur touche à sa fin pour les cas où la performance compte.
L'open source reste central. Le nouveau compilateur est open-source dès le premier commit. Microsoft aurait pu le garder propriétaire pendant le développement. Ils ne l'ont pas fait.
Ce que tu devrais faire maintenant
Honnêtement ? Rien de spécial.
- Continue d'écrire du TypeScript normalement. Ton code ne sera pas impacté.
- Suis le repo GitHub si tu veux tester les premières builds.
- Ne migre pas tes outils en anticipation. Le compilateur actuel est maintenu et fonctionnel.
- Prépare-toi psychologiquement à une DX significativement meilleure dans les 6 à 12 prochains mois.
Et la prochaine fois qu'un collègue dit "TypeScript c'est trop lent", tu pourras répondre que c'est en train d'être réglé -- par les gens qui ont créé le langage.
Ressources
- Annonce officielle Microsoft -- le blog post d'Anders Hejlsberg
- Repo GitHub du compilateur Go -- le code source
- Vidéo de démo (YouTube) -- la vidéo de l'annonce avec les benchmarks
- Discussion Hacker News -- les réactions de la communauté
- TypeScript Roadmap -- le calendrier officiel de TypeScript