TypeScript 10 fois plus rapide
(devblogs.microsoft.com)- Microsoft annonce une amélioration des performances de TypeScript par 10 grâce au portage natif du compilateur et des outils
- Temps de démarrage de l’éditeur nettement amélioré, temps de build divisés par 10, et forte réduction de l’utilisation mémoire
- Une version preview de
tscest prévue d’ici la mi-2025, avec un support complet du build de projet et des services de langage d’ici fin 2025
Contexte de l’amélioration des performances de TypeScript
- La valeur centrale de TypeScript réside dans son excellente expérience développeur
- Plus la base de code grandit, plus la valeur de TypeScript augmente, mais des problèmes de performances apparaissent sur les projets de grande taille
- Problèmes de temps de chargement et de vérification trop longs
- Nécessité de trouver un équilibre entre un démarrage rapide de l’éditeur et l’analyse de l’ensemble de la base de code
- Les fonctionnalités basées sur l’IA ont besoin d’informations sémantiques rapides et précises
- La demande augmente pour vérifier l’état d’une base de code via des builds en ligne de commande
Plan de progression du portage natif
- Début des travaux de portage natif du compilateur TypeScript et de ses outils
- Objectifs d’amélioration des performances :
- Réduire fortement le temps de démarrage de l’éditeur
- Réduire le temps de build jusqu’à 10 fois
- Diminuer l’utilisation mémoire
- Mi-2025 : sortie prévue d’une version preview de
tsccapable d’effectuer une vérification de types en ligne de commande - Fin 2025 : prise en charge prévue du build complet de projet et des services de langage
Exécution du code et tests
- Le code peut être compilé et exécuté depuis le dépôt du code Go de TypeScript
- Le dépôt fournit des instructions pour compiler et exécuter
tscainsi que le serveur de langage - Des mises à jour régulières sont prévues concernant les nouvelles fonctionnalités
À quel point est-ce devenu plus rapide ?
- Les tests actuels des temps de build de projets TypeScript sur plusieurs bases de code populaires montrent les gains suivants :
- Le projet VS Code, avec environ 1,5 million de lignes de code, passe de 77,8 secondes à 7,5 secondes, soit environ 10,4 fois plus rapide
- Le projet Playwright, avec environ 350 000 lignes de code, passe de 11,1 secondes à 1,1 seconde, soit environ 10,1 fois mieux
- Le projet TypeORM, avec environ 270 000 lignes de code, passe de 17,5 secondes à 1,3 seconde, soit environ 13,5 fois mieux
- Le projet date-fns, avec environ 100 000 lignes de code, passe de 6,5 secondes à 0,7 seconde, soit environ 9,5 fois mieux
- Le projet tRPC, avec environ 18 000 lignes de code, passe de 5,5 secondes à 0,6 seconde, soit environ 9,1 fois mieux
- Le projet rxjs, avec environ 2 000 lignes de code, passe de 1,1 seconde à 0,1 seconde, soit environ 11 fois mieux
- Même si tout n’est pas encore complet, une amélioration de performances supérieure à 10x est attendue sur la plupart des bases de code
- La vérification de types rapide et la navigation dans le code deviennent possibles
- L’intégration avec les outils d’IA et la prise en charge du refactoring avancé deviennent envisageables
Amélioration des performances de l’éditeur
- Amélioration de la vitesse de chargement et de réactivité de l’éditeur
- Temps de chargement basé sur la base de code de Visual Studio Code :
- Actuel : 9,6 secondes → version native : 1,2 seconde (environ 8 fois mieux)
- L’utilisation mémoire diminue également d’environ 50 %
- Des gains de performances sont attendus pour les opérations du service de langage (auto-complétion, info-bulles rapides, aller à la définition, etc.)
- La transition est en cours sur la base du protocole Language Server Protocol (LSP)
Feuille de route des versions
- TypeScript 5.8 est déjà sorti, et TypeScript 5.9 devrait arriver prochainement
- La base de code TypeScript en JS continuera d’être développée sous la branche 6.x
- Une fois la base de code native stabilisée, elle sortira sous TypeScript 7.0
- TypeScript 6 → version basée sur JS
- TypeScript 7 → version basée sur du natif
- La version 6.x sera également maintenue pendant un certain temps après la sortie de TypeScript 7
Prochaines étapes
- Davantage d’informations seront publiées sur les performances, l’API du compilateur, le LSP, etc.
- Une FAQ est disponible sur GitHub FAQ
- Une AMA est prévue le 13 mars 2025 sur le Discord de la communauté TypeScript (10 h PDT | 17 h UTC)
24 commentaires
J’avais l’impression que tout le monde lançait ça sans vraiment réfléchir au structural typing.
Le réécrire dans un langage à typage nominal comme C# ou Rust n’aurait sans doute pas été simple, puisqu’il aurait fallu modifier bien trop profondément la structure fondamentale du projet.
Parmi les langages qui adoptent le structural typing, les seuls capables d’offrir de meilleures performances qu’une base JS existante seraient probablement C++ ou Go, et si on tient aussi compte de la productivité, il n’y a pas vraiment d’alternative.
À un moment, j’avais commencé à moins m’intéresser à TS, mais en voyant ce genre de nouvelle, ça me retente bien, non ?
Dans ts, si on abuse de
anysauf quand c’est vraiment inévitable, ça revient à utiliser du vanilla… hahaLa controverse semble assez vive pour qu’Anders Hejlsberg ait laissé lui-même un commentaire.
https://github.com/microsoft/typescript-go/…
Une personne aimerait compiler du TypeScript pour obtenir directement un binaire en sortie
Je ne connais pas grand-chose au front... c’est différent de swc ?
SWC se concentre, comme Babel, sur la génération de code JavaScript compatible et même sur le bundling, tandis qu’ici l’accent est mis sur la transformation du code TypeScript en JavaScript ou sur la vérification des erreurs.
On parle de dogfooding, le fait d’utiliser soi-même ce qu’on a créé. Mais dans le cas d’un langage, ça me fait un peu réfléchir.
À mon avis, comme les runtimes de JS sur lesquels TS repose (par ex. SpiderMonkey, V8) sont pour la plupart écrits en C++, qu’il n’existe pas de runtime implémenté en JS,
et que même pour la compilation JS -> JS, dès qu’on utilise du pur JS c’est bien trop lent et tout le monde finit par passer à des trucs comme esbuild,
je me dis que dans le cas de TS aussi, ce n’est peut-être pas nécessaire de s’obstiner à dogfooder à tout prix.
J’ai peur qu’à terme, la maintenance de la base de code TypeScript existante ne soit négligée.
C’est une bonne nouvelle ! De façon assez surprenante, le langage TypeScript de MS semble faire, contrairement aux attentes, beaucoup de choix vraiment inattendus. Du point de vue de MS, c’est presque son premier projet open source, et contrairement à Dart de Google, qui cherchait à remplacer JS, le choix d’avoir voulu compléter JS paraît très judicieux ; et pour ce portage natif aussi, alors qu’ils ont sans doute beaucoup de langages maison, il est étonnant qu’ils aient choisi le Go de Google.
Tiens, il me semblait qu’ils avaient déjà créé un toolchain basé sur Rust du côté de Deno... pourquoi passer soudainement à Go ?
Vous semblez parler de runtimes comme Node, mais ici il s’agit du compilateur du langage TS lui-même.
Ah, en lisant un peu plus l’article, je pense que je me suis embrouillé parce qu’il était aussi question d’un éditeur plus rapide.
tscdevient 10 fois plus rapide. Autrement dit, le temps de transpilation detsversjsest fortement réduit.ts, comme VSCode, devient beaucoup plus rapide. Cela signifie que la logique qui partage les fonctionnalités detsc, comme l’analyse syntaxique dets, a été accélérée.C’était donc bien de cela qu’il s’agissait.
J’ai déjà eu recours à des solutions de repli parce que l’utilisation de types génériques définis de façon récursive ralentissait tout. Si c’est 10 fois plus rapide, j’espère que ce genre de point pourra aussi être amélioré.
Le fil de discussion sur la question de savoir pourquoi Go est assez intéressant.
https://github.com/microsoft/typescript-go/discussions/411
Il y a aussi beaucoup de points à examiner...
Je comprends cela dit aussi ce que peuvent ressentir les développeurs .NET...
Les développeurs .NET et Rust sont visiblement très en colère.
Je comprends pour .NET, mais j’ai l’impression que Rust se situe au même niveau que Go. J’imagine que les projets et bibliothèques Go déjà existants autour de JS ont aussi influencé la décision.
Le développement du langage C# ne s’est pas arrêté, mais j’ai trop souvent l’impression que les frameworks utilisant C# sont laissés à l’abandon.
Écrivez en Go~
J’ai vraiment hâte.
Avis Hacker News
tscrapide en Ruststc: abandonnéezno: activement développé, sans viser une correspondance 1:1 avectsc