Microsoft publie TypeScript 7.0 avec des hausses impressionnantes de performances
Ah oui quand même
Le 09 juillet à 12h29
La nouvelle mouture de TypeScript est annoncée avec des performances largement revues à la hausse. L’essentiel des nouveautés se concentre sur ces gains, le langage n’apportant rien de vraiment neuf sur les types et la syntaxe.
Microsoft publie TypeScript 7.0 avec des hausses impressionnantes de performances
Ah oui quand même
La nouvelle mouture de TypeScript est annoncée avec des performances largement revues à la hausse. L’essentiel des nouveautés se concentre sur ces gains, le langage n’apportant rien de vraiment neuf sur les types et la syntaxe.
Logiciel
Logiciel
4 min
Ce n’est pas tous les jours que l’on peut annoncer des hausses majeures de performances sur des technologies. Microsoft vient pourtant de lancer la version 7.0 de son langage open source TypeScript, un surensemble de JavaScript sous licence Apache 2.0. Depuis sa sortie, le langage a rencontré un grand succès.
Hop, une division par 10
La plus grosse nouveauté de TypeScript 7.0 est son compilateur. Ce dernier était lui-même compilé en TypeScript/JavaScript jusqu’ici, mais c’est fini : le nouveau est écrit en Go. Le code produit est strictement le même, mais avec une différence de taille : le temps de compilation est en moyenne divisé par 10. En fonction des cas, ce facteur alterne entre 8 et 12, le gain de temps étant dans tous les cas énorme.
Ce gain de performances rejaillit sous de nombreux aspects. La compilation complète bien sûr, en passant de plusieurs dizaines de secondes à quelques secondes, mais aussi une réaction beaucoup plus rapide de tsc –watch, l’accélération de l’analyse des types ou encore une consommation de mémoire vive revue à la baisse, le plus souvent entre 5 et 25 % selon les cas.
Microsoft insiste également sur la solidité de cette version, car elle a bénéficié d’une année de tests. Ces derniers ont aussi bien lieu avec d’autres équipes de Microsoft (Loop, Office, PowerBI, Teams ou encore Xbox) qu’avec des entreprises tierces : Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et autres. Les retours auraient été unanimes : des gains de temps conséquents et des économies de ressources.
La nouvelle version a en outre des conséquences positives sur Visual Studio Code. Dans un test, Microsoft a pu mesurer que le temps passé à ouvrir un fichier avec une erreur dans Visual Studio Code était réduit à 1,3 seconde, contre 17,5 auparavant, soit une division par 13. L’autocomplétion est aussi plus rapide, la fonction « Go to Definition » est presque instantanée, le renommage va plus vite, les diagnostics apparaissent plus rapidement, etc. Microsoft ajoute que plus les monorepos sont volumineux, plus la différence se sent. Une bonne part de ces améliorations vient d’une parallélisation beaucoup plus importante des instructions.
Une transition « transparente »
On aurait pu s’attendre à de nouvelles fonctions, des types et autres syntaxes, mais cette version 7.0 ne change pratiquement rien de ce côté. La plus grosse partie du travail s’étant concentrée sur les performances, TypeScript 7 reste donc compatible avec la version 6. La migration se veut la plus transparente possible, la nouvelle version n’étant livrée avec aucune API. Celle-ci arrivera avec TypeScript 7.1 mais, en attendant, Microsoft a fait le choix « de garantir que TypeScript puisse être exécuté parallèlement à TypeScript 6.0 pour les utilitaires nécessitant encore un certain accès programmatique au compilateur (comme typescript-eslint) ».
L’éditeur ajoute que dans le cadre de cette transition, un paquet de compatibilité a été publié. Il fournit un exécutable nommé pour que les développeurs puissent installer TypeScript 7.0 (qui publie son propre binaire) côte à côte, sans conflit de nommage. « Le nouveau package réexporte également l’API TypeScript 6.0, afin que vous puissiez l’utiliser pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0 », précise Microsoft.
Commentaires (23)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 9 juillet à 13h45
Je me suis emporté sur la fin on dirait.
Le 9 juillet à 14h40
En le lisant, je m'attendais à des perf d'exécution et pas la compilation.
Le 9 juillet à 15h06
Peut-être que Doom en TypeScript sera plus performant par contre :
Le 9 juillet à 15h22
Le 9 juillet à 22h28
Le 9 juillet à 15h14
Et bien non, le code JS produit est strictement le même donc aucun gain de ce côté là c'est dommage.
Modifié le 9 juillet à 17h22
Le 9 juillet à 17h02
--erasableSyntaxOnly(cfMais beaucoup de code Typescript n'utilise pas tout ça. Vous pouvez faire mumuse sur https://www.typescriptlang.org/play/, ça affiche le code JS résultant.
Le 10 juillet à 09h45
Oui je sais commentaire totalement inutile mais j'ai pa pu m'en empêcher.
Le 10 juillet à 10h25
Le 10 juillet à 12h00
Le 10 juillet à 13h56
Outre le typage statique, typescript a introduit à plusieurs reprises des concepts qui ont ensuite été ajouté à Javascript (let, les décorateurs, async/await, etc.)
Bien que syntaxiquement proche, c'est un langage à part entière.
Le 10 juillet à 14h53
Lundi à 11h46
Le 12 juillet à 03h53
In-cro-yable.
Modifié lundi à 11h54
il n'y a pas de compilateur typescript, le code est transpilé en javascript.
Ce sont ni plus ni moins que des expressions régulières pour supprimer les types et autres cast ajoutés à javascript par typescript, tout le reste est identique : même nom de variable, même algorithme, boucles, if, routines...
La compilation implique une analyse syntaxique, lexical, puis de la grammaire du langage, avant de réécrire dans le nouveau langage : ce n'est pas le cas ici.
les gains n'ont pas énormément d'intéret
Jeudi à 13h28
C'est d'ailleurs ce compilateur qui a été réécrit en GO, puisqu'il était auparavant écrit lui-même en TypeScript (puis transpilé en JavaScript, ce qui n'est plus le cas avec la version 7), il était jusqu'à lors un compilateur autohébergé.
C'est aussi lui qui fait l'analyse syntaxique et sémantique pour effectuer son type checking, qui est le principal intérêt du langage. Sans parser dédié, il ne pourrait pas vérifier le code avant d'être transpilé en JavaScript, du coup le langage n'aurait aucun intérêt...
Les gains ont de l'intérêt pour ceux qui utilisent quotidiennement le langage, car le typechecking en temps réel dans l'IDE est plus rapide et les compilations / hotreloading pendant le développement sont aussi plus rapides.
Jeudi à 14h18
En outre, il serait étonnant qu'une expression régulière soit capable de vérifier la conformance des types (contrairement à Python où les types peuvent être vus comme de simples annotations ignorables, en tsc la conformance de type est obligatoire au succès de la
comptransp ilation.), donc tsc ne se contente pas de retirer les annotations et est bien obligé de faire une analyse sémantique donc syntaxique, donc lexicale de la source.Jeudi à 15h24
C'est juste que d'usage on appelle principalement un "compilateur" tel quel lorsqu'il compile d'un langage de plus haut niveau d'abstraction à un langage de plus bas niveau (y compris le langage machine).
Un transpileur de son côté compile d'un langage de haut niveau vers un autre langage de niveau similaire.
Mais leur principe reste le même et les deux ont un parser pour analyser leur grammaire et en découle l'analyse sémantique et la transformation en JavaScript à la fin pour tsc. Donc ce ne sont pas que des expressions régulières pour enlever des types effectivement.
Vendredi à 11h01
le fait est que tsc fait deux choses le contrôle et la transpilation. Pour la partie transpilation il n'y a besoin d'analyseur grammatical : ce sont les mêmes langages aux annotations de type et cast près.
Vendredi à 11h57
Maintenant que la norme Ecma a inclus ces notions, il est vrai que le compilateur à moins de boulot à faire là dessus. Mais réduire typescript comme étant le même langage que JS aux annotations de typage et de cast près, c'est assez réducteur.
Et c'est aussi une partie du boulot du compilateur justement : dans le cas où la version ciblé de JS est une version antérieure qui ne supporte pas les fonctionnalités, TS remplace le code par un équivalent fonctionnel.
Hier à 09h36
je ne connaissais pas ce comportement, là effectivement on est plus proche d'un compilateur.
Hier à 16h42
On est d'accord que le code pourra être exécuté, mais tu pourrais avoir des changements subtiles de comportements.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?