Discussion :

[Jade Emy]

Un TypeScript 10x plus rapide : Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, présente un nouveau portage de TypeScript qui offrira aux développeurs un outil de haute performance.

Microsoft annonce une réécriture de son langage de programmation TypeScript en le dotant d'un compilateur et d'un ensemble d'outils natifs. Cet effort vise à résoudre les problèmes de performance, en particulier dans les grandes bases de code, en portant le compilateur TypeScript existant de TypeScript/JavaScript au langage natif, Go. Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, affirme : "L'implémentation native améliorera considérablement le démarrage de l'éditeur, divisera par 10 la plupart des temps de construction et réduira substantiellement l'utilisation de la mémoire".

Le 11 mars 2025, TypeScript a annoncé une réécriture complète de TypeScript en Go. Lors des tests, cette réécriture a permis une accélération de 10 fois dans certains dépôts - et jusqu'à 15 fois dans d'autres. Cette accélération affectera chaque partie de l'écosystème TypeScript : de l'exécution de tsc via CLI à la performance des survols et des erreurs dans votre IDE. Une fois la version publiée, vous serez en mesure d'adopter la nouvelle version de TypeScript sans modifier une seule ligne de code.

Pour rappel, TypeScript est un langage de programmation open-source et gratuit, développé par Microsoft, qui ajoute à JavaScript un typage statique avec des annotations de type optionnelles. Il est conçu pour le développement de grandes applications et se transpose à JavaScript. Depuis des années, l'amélioration des performances est la fonctionnalité la plus demandée par la communauté. Plusieurs tentatives ont été faites pour réécrire TypeScript dans un langage plus rapide, mais aucune n'a abouti.

Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, a récemment présenté cette réécriture de TypeScript. Anders Hejlsberg est un ingénieur logiciel danois qui a co-conçu plusieurs langages de programmation et outils de développement. Il est l'auteur original de Turbo Pascal et l'architecte en chef de Delphi. Il travaille actuellement pour Microsoft en tant qu'architecte principal de C# et développeur principal de TypeScript.

Anders Hejlsberg présente un nouveau portage de TypeScript qui offrira aux développeurs un outil de haute performance

La proposition de valeur centrale de TypeScript est une excellente expérience pour le développeur. Au fur et à mesure que votre base de code se développe, la valeur de TypeScript elle-même augmente, mais dans de nombreux cas, TypeScript n'a pas été en mesure de s'adapter aux bases de code les plus importantes. Les développeurs travaillant sur de grands projets peuvent être confrontés à des temps de chargement et de vérification longs, et doivent choisir entre un temps de démarrage raisonnable de l'éditeur et une vue complète de leur code source.

Les développeurs apprécient de pouvoir renommer des variables en toute confiance, de trouver toutes les références à une fonction particulière, de naviguer facilement dans leur base de code et de faire toutes ces choses sans délai. Les nouvelles expériences basées sur l'IA bénéficient de larges fenêtres d'informations sémantiques qui doivent être disponibles avec des contraintes de latence plus strictes. Microsoft souhaitent également créer des builds en ligne de commande rapides pour valider que l'ensemble de votre base de code est en bon état.

Pour atteindre ces objectifs, Anders Hejlsberg affirme qu'ils ont commencé à travailler sur un portage natif du compilateur et des outils TypeScript. L'implémentation native améliorera le démarrage de l'éditeur, réduira la plupart des temps de construction par 10, et réduira substantiellement l'utilisation de la mémoire. En portant la base de code actuelle, ils prévoient d'être en mesure de présenter une implémentation native de tsc capable de vérifier les caractères en ligne de commande d'ici la moitié de 2025, avec une solution complète pour la construction de projets et un service linguistique d'ici la fin de l'année 2025.


Un TypeScript 10 fois plus rapide

L'implémentation native serait déjà capable de charger de nombreux projets TypeScript populaires, y compris le compilateur TypeScript lui-même. Voici les temps d'exécution de tsc sur quelques bases de code populaires sur GitHub de différentes tailles :

Bien que les fonctionnalités ne soient pas encore complètes, ces chiffres sont représentatifs de l'ordre de grandeur de l'amélioration des performances que vous constaterez en vérifiant la plupart des bases de code.

Anders Hejlsberg commente notamment ces gains : "Nous sommes très enthousiastes à l'idée des opportunités créées par cette augmentation massive de la vitesse. Des fonctionnalités qui semblaient autrefois hors de portée sont désormais à portée de main. Ce portage natif sera capable de fournir instantanément des listes d'erreurs complètes sur l'ensemble d'un projet, de supporter des refactorings plus avancés et de permettre des analyses plus approfondies qui étaient auparavant trop coûteuses à calculer. Cette nouvelle fondation va au-delà de l'expérience actuelle des développeurs et permettra à la prochaine génération d'outils d'IA d'améliorer le développement, en alimentant de nouveaux outils qui apprendront, s'adapteront et amélioreront l'expérience de codage."


Vitesse de l'éditeur

Les développeurs passent la plupart de leur temps dans les éditeurs, et c'est là que les performances sont les plus importantes. Les développeurs souhaitent que ces éditeurs chargent rapidement les grands projets et réagissent rapidement dans toutes les situations. Grâce à cette réécriture, TypeScript serait en mesure de fournir des expériences d'édition incroyablement rapides.

En utilisant à nouveau la base de code de Visual Studio Code comme référence, le temps de chargement d'un projet complet dans l'éditeur sur un ordinateur rapide est d'environ 9,6 secondes. Ce temps tombe à environ 1,2 seconde avec le service de langue maternelle, soit une amélioration de 8 fois le temps de chargement du projet dans les scénarios de l'éditeur. Cela se traduit par une expérience de travail plus rapide depuis l'ouverture de l'éditeur jusqu'à la première frappe dans n'importe quelle base de code TypeScript. Cepedant, il reste à voir si tous les projets bénéficieront de ce niveau d'amélioration du temps de chargement.

L'utilisation globale de la mémoire semble également être environ la moitié de l'implémentation actuelle. La réactivité de l'éditeur pour toutes les opérations des services linguistiques (y compris les listes d'achèvement, les informations rapides, les définitions et la recherche de toutes les références) connaîtra également des gains de vitesse significatifs. Ils passeront également au protocole de serveur de langue (LSP), un travail d'infrastructure de longue haleine visant à mieux aligner l'implémentation sur les autres langues.

Feuille de route des versions

Voici les projets futures pour TypeScript selon Anders Hejlsberg :

Notre dernière version de TypeScript était TypeScript 5.8, et TypeScript 5.9 sera bientôt disponible. La base de code basée sur JS continuera son développement dans la série 6.x, et TypeScript 6.0 introduira quelques dépréciations et ruptures pour s'aligner sur la base de code native à venir.

Lorsque la base de code native aura atteint une parité suffisante avec le TypeScript actuel, nous la publierons en tant que TypeScript 7.0. Cette version est encore en cours de développement et nous annoncerons les étapes de stabilité et de fonctionnalités au fur et à mesure qu'elles se produiront.

Par souci de clarté, nous les appellerons simplement TypeScript 6 (JS) et TypeScript 7 (natif), puisque telle sera la nomenclature dans un avenir prévisible. Vous pouvez également nous voir faire référence à « Strada » (le nom de code original de TypeScript) et « Corsa » (le nom de code pour cet effort) dans les discussions internes ou les commentaires de code.

Alors que certains projets peuvent être en mesure de passer à TypeScript 7 dès sa sortie, d'autres peuvent dépendre de certaines fonctionnalités de l'API, de configurations héritées ou d'autres contraintes qui nécessitent l'utilisation de TypeScript 6. Reconnaissant le rôle critique de TypeScript dans l'écosystème de développement JS, nous continuerons à maintenir la base de code JS dans la ligne 6.x jusqu'à ce que TypeScript 7+ atteigne une maturité et une adoption suffisantes.

Notre objectif à long terme est de maintenir ces versions aussi proches que possible afin que vous puissiez passer à TypeScript 7 dès qu'il répondra à vos besoins, ou revenir à TypeScript 6 si nécessaire.

Il est vrai qu'une amélioration des performances de 10x représente un saut massif dans l'expérience de développement TypeScript et JavaScript. Si Anders Hejlsberg et l'équipe TypeScript sont enthousiaste de cet effort, il est intéressant de rappeller quelques vérités sur TypeScript. En 2023, Stefan Baumgartner, un auteur de deux livres sur TypeScript, a notamment présenté "Cinq vérités inconfortables à propos de TypeScript".

Tout d'abord, il a rappellé que TypeScript n'est pas une version "corrigée" de JavaScript, mais plutôt un sur-ensemble de ce dernier. Il ne vous épargne donc pas JavaScript avec ses bizarreries et ses défauts. Malgré son approche graduelle, TypeScript ajoute aussi de la complexité aux projets en raison de ses nombreuses options de configuration.

En outre, ce n'est pas vraiment un langage à typage sûr, en particulier lorsque des interactions avec le "monde extérieur" sont impliquées. Stefan Baumgartner affirme également que TypeScript existe sous une multitude de variantes implicites, chacune avec ses avantages et ses inconvénients. Malgré tout, il estime que TypeScript reste un langage précieux pour améliorer la productivité et la maintenabilité des projets, à condition de comprendre ses compromis et de l'utiliser correctement.


Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Microsoft annonce la disponibilité de TypeScript 5.8, apportant des vérifications plus granulaires pour les branches dans les expressions de retour, ainsi que plusieurs autres améliorations

Le langage Go souffle ses 15 bougies et atteint sa position la plus haute sur l'indice Tiobe. Google annonce que le nombre d'utilisateurs de Go a plus que triplé au cours des cinq dernières années

Pourquoi je suis sceptique quant à la réécriture des outils JavaScript dans des langages "plus rapides", par Nolan Lawson

[Pyramidev]

Comme le but de cette réécriture est d'avoir de bonnes performances, si on ne connaît pas le contexte, le choix le plus évident est le langage Rust. Pourquoi avoir choisi Go ? Ryan Cavanaugh de chez Microsoft a répondu hier à cette question sur reddit. En résumé, c'est parce que le code existant en TypeScript était écrit de telle sorte qu'il était facile de le porter en Go, tandis que passer en Rust aurait nécessité une réécriture beaucoup plus longue et aurait présenté des risques de regression. Voici la réponse complète de Ryan Cavanaugh :

(Hi, dev lead of TypeScript here)

Lots of questions about why Go in thread, let me address.

We definitely knew when choosing Go that there were going to be people questioning why we didn't choose Rust (or others). It's a good question because Rust is an excellent language, and barring other constraints, is a strong first choice when writing new native code.

Portability (i.e. the ability to make a new codebase that is algorithmically similar to the current one) was always a key constraint here as we thought about how to do this. We tried tons of approaches to get to a representation that would have made that port approach tractable in Rust, but all of them either had unacceptable trade-offs (perf, ergonomics, etc.) or devolved in to "write your own GC"-style strategies. Some of them came close, but often required dropping into lots of unsafe code, and there just didn't seem to be many combinations of primitives in Rust that allow for an ergonomic port of JavaScript code (which is pretty unsurprising when phrased that way - most languages don't prioritize making it easy to port from JavaScript/TypeScript!).

In the end we had two options - do a complete from-scrach rewrite in Rust, which could take years and yield an incompatible version of TypeScript that no one could actually use, or just do a port in Go and get something usable in a year or so and have something that's extremely compatible in terms of semantics and extremely competitive in terms of performance.

And it's not even super clear what the upside of doing that would be (apart from not having to deal with so many "Why didn't you choose Rust?" questions). We still want a highly-separated API surface to keep our implementation options open, so Go's interop shortcomings aren't particularly relevant. Go has excellent code generation and excellent data representation, just like Rust. Go has excellent concurrency primitives, just like Rust. Single-core performance is within the margin of error. And while there might be a few performance wins to be had by using unsafe code in Go, we have gotten excellent performance and memory usage without using any unsafe primitives.

In our opinion, Rust succeeds wildly at its design goals, but "is straightforward to port to Rust from this particular JavaScript codebase" is very rationally not one of its design goals. It's not one of Go's either, but in our case given the way we've written the code so far, it does turn out to be pretty good at it.