Le ralentissement de TypeScript, bien visible mais ignoré
Le développement TypeScript comporte deux processus distincts : la transpilation et la vérification sémantique des types. Des outils de build rapides comme esbuild ou Vite suppriment rapidement la syntaxe TypeScript pour la convertir en JavaScript exécutable. Cette étape est rapide et ne prend souvent que quelques millisecondes.
Le goulot d'étranglement apparaît lors de la vérification sémantique des types, qui contrôle la validité du code. Ce processus, essentiel pour les retours dans l'éditeur et les pipelines de CI, peut durer plusieurs minutes sur les grands projets. Les développeurs ressentent ce délai sous la forme d'un signalement d'erreurs lent dans les IDE ou de temps d'exécution de CI prolongés.
Microsoft a officiellement répondu à ce problème avec un portage en Go du compilateur TypeScript, offrant une accélération de 8 à 12x par rapport à l'ancien moteur JavaScript. Cette version Go, intégrée à TypeScript 7.0, a nettement réduit les temps de vérification : par exemple, la vérification des types de VS Code est passée de 125,7 secondes à 10,6 secondes.
Récemment, une implémentation en Rust menée par la communauté a vu le jour et propose un nouveau concurrent. Développé rapidement par Cloudflare et le projet Oxc à l'aide d'agents d'IA, ce portage en Rust de la base de code Go affirme être presque trois fois plus rapide que la version Go officielle. Bien qu'il ne soit pas encore intégré à l'ensemble de l'écosystème, il réussit plus de 99,9 % des tests de conformité TypeScript, ce qui démontre son potentiel.
Le benchmark : 0,3 seconde contre 0,7
Pour quantifier l'accélération, un benchmark a opposé l'ancien compilateur JavaScript aux nouveaux portages Go et Rust. Le test a utilisé le dépôt TypeScript officiel, une base de code conséquente comprenant 793 fichiers et environ 380.000 lignes de code. Quatre scénarios ont évalué les performances : du code parfaitement valide, une seule erreur de type, une défaillance en cascade due à un type central défectueux, et une récursion profonde.
Dans l'ensemble de ces scénarios variés, les résultats sont frappants. Le compilateur JavaScript a systématiquement été le plus lent, avec des temps allant de 6,6 à 13 secondes. Le portage en Go a nettement amélioré ces résultats, avec des vérifications effectuées en 0,6 à 2,2 secondes. La version Rust, en revanche, a affiché des performances supérieures, terminant en seulement 0,2 à 0,5 seconde.
Pour mettre en perspective les chiffres clés, le compilateur Rust a été en moyenne environ 24 fois plus rapide que l'implémentation JavaScript d'origine. Plus impressionnant encore, il a été presque trois fois plus rapide que le portage en Go dans ce test précis. Ces résultats soulignent le potentiel d'améliorations substantielles de l'expérience des développeurs.
Il est essentiel de garder à l'esprit que les résultats des benchmarks peuvent varier. Des facteurs tels que les caractéristiques matérielles, la structure du projet, les versions précises du compilateur et la méthodologie exacte du benchmark peuvent tous influencer les performances. Néanmoins, l'accélération constante et spectaculaire observée avec le portage en Rust constitue une avancée notable pour l'écosystème TypeScript.
Des agents d'IA ont reproduit une conception durement acquise
Fait remarquable, le portage en Rust n'est pas né d'un ingénieur concevant un nouveau système de types. Un ingénieur a plutôt dirigé des agents d'IA, principalement Claude Opus 3.5, pour traduire en Rust, fonction par fonction, le compilateur Go existant de Microsoft. Cette approche reposait sur une traduction mécanique, et non créative.
Cette stratégie de traduction s'appuyait sur la vaste suite de conformité de TypeScript, qui compte plus de 13.000 cas de test. Chaque cas de test précise les erreurs de diagnostic exactes qu'un compilateur conforme doit signaler. Les agents portaient une fonction, exécutaient les tests correspondants, corrigeaient les écarts éventuels, puis passaient à la fonction suivante.
Le fait de réussir tous ces tests, comme le fait désormais la version Rust, confirme sa compatibilité et sa capacité à produire des résultats de vérification des types identiques à ceux du compilateur Go officiel. Cela a permis une itération rapide et vérifiable en seulement trois semaines de développement. Pour en savoir plus sur le portage officiel en Go, consultez A 10x Faster TypeScript - Microsoft Developer Blogs.
Toutefois, la réussite des tests de conformité vérifie avant tout l'exactitude des résultats. Elle ne garantit pas en soi des performances équivalentes pour tous les types de projets, une intégration fluide aux éditeurs ni une disponibilité immédiate en production pour chaque base de code. Si les benchmarks présentés dans la vidéo sont convaincants, une intégration plus poussée et des tests en conditions réelles seront essentiels pour consolider son adoption à plus grande échelle.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
La vitesse est enthousiasmante ; l'adoption est le véritable test
Les gains de performance de Rust sont enthousiasmants, mais son atout WebAssembly offre une raison convaincante de l'adopter. Cloudflare, par exemple, vise à exécuter des outils de développement directement dans les navigateurs et les environnements edge. Rust se compile en WebAssembly sans embarquer de ramasse-miettes, contrairement à Go, ce qui le rend idéal pour une exécution légère et isolée.
L'implémentation en Go du compilateur TypeScript par Microsoft reste la référence officielle et alimente TypeScript 7.0 avec des gains de vitesse significatifs. Le portage en Rust, lui, est développé au sein du projet Oxc, une chaîne d'outils Rust créée par les auteurs de Vite. Cela le positionne pour de futures applications telles que le linting tenant compte des types dans Oxc Lint, en tirant parti de sa vitesse pour fournir un retour en temps réel.
Considérez ce benchmark comme un signal prometteur, et non comme une garantie universelle. Vérifiez la compatibilité et la prise en charge des outils pour votre pile technique spécifique avant de l'intégrer. Observez si ces optimisations et intégrations atteignent les flux de travail quotidiens et réduisent concrètement les temps de cycle pour les développeurs. Le véritable test pour le portage en Rust sera son passage d'un benchmark impressionnant à une utilité pratique à grande échelle.
Foire aux questions
Le compilateur TypeScript en Rust est-il une version officielle de Microsoft ?
Non. Il s'agit d'un portage en Rust mené par la communauté et associé au projet Oxc ; le portage natif officiel du compilateur par Microsoft est écrit en Go.
Dans le benchmark de la vidéo, le compilateur Rust était-il plus rapide, et de combien ?
Sur le test du dépôt TypeScript, il a été en moyenne environ 24 fois plus rapide que le compilateur JavaScript et presque trois fois plus rapide que le portage en Go.
Pourquoi développer un compilateur TypeScript en Rust ?
L'absence de ramasse-miettes dans Rust peut rendre le packaging WebAssembly attrayant, tandis que le portage explore également des optimisations de performances et de mémoire.
Le portage en Rust a-t-il été écrit par une IA ?
Des agents d'IA ont réalisé une grande partie du portage mécanique sous la direction d'un ingénieur, en s'appuyant sur le compilateur de Microsoft et les tests de conformité de TypeScript.

