Connexion Premium

Microsoft publie TypeScript 7.0 avec des hausses impressionnantes de performances

Ah oui quand même

Microsoft publie TypeScript 7.0 avec des hausses impressionnantes de performances

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.

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.

Source : Microsoft

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)

votre avatar
La version 6 avait justement été publié pour préparer l'arriver de la version 7 : le but était de faire les changements nécessaires dans le comportement et l'API pour que la transition de 6 vers 7 soit toute douce et soyeuse, aussi rafraîchissante qu'un bon verre d'eau à 18°C en pleine canicule.

Je me suis emporté sur la fin on dirait.
votre avatar
Bonne nouvelle pour les devs, mais je trouve le titre trompeur.

En le lisant, je m'attendais à des perf d'exécution et pas la compilation.
votre avatar
Ah, mais TypeScript n'a jamais exécuté quoi que ce soit : il ne fait qu'écrire du JavaScript. C'est le moteur JS qui fait le boulot d'exécution derrière.

Peut-être que Doom en TypeScript sera plus performant par contre : github.com GitHub (annonce sur https://fosstodon.org/@MichiganTypeScript/114070803727265788 et explication sur https://www.tomshardware.com/video-games/porting-doom-to-typescript-types-took-3-5-trillion-lines-90gb-of-ram-and-a-full-year-of-work)
votre avatar
Les dev de Doom 😢
votre avatar
Tout à fait vrai, mais pour interpréter convenablement le titre, il faut savoir ça, ce qui n'est clairement pas le cas de la majorité.
votre avatar
Oui moi aussi j'ai cru à une optimisation du code produit 😅
Et bien non, le code JS produit est strictement le même donc aucun gain de ce côté là c'est dommage.
votre avatar
L'idée m'a traversée la tête 2 secondes. Mais TypeScript étant compilé en JavaScript, ça parait évident que de tel gains a l'exécution sont impossibles, sauf si le JavaScript généré était auparavant de qualité catastrophique. Mais dans ce cas là, TypeScript n'aurait jamais été adopté.
votre avatar
La plupart du temps, Typescript ne change absolument rien au code écrit, à part enlever le typage. Ça peut d'ailleurs être vérifié avec le paramètre --erasableSyntaxOnly (cf devblogs.microsoft.com Microsoft, qui donc empêche d'utiliser :

  • les enums

  • les namespaces et modules avec du code

  • les propriétés de paramètres

  • les alias d'import



Mais 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.
votre avatar
J'aime pas JS...
Oui je sais commentaire totalement inutile mais j'ai pa pu m'en empêcher.
votre avatar
et hors sujet : on parle de typescript, pas de javascript :D
votre avatar
Ha mince j'étais quasi certain que TS était une des nombreuses surcouches qui visait à rendre fonctionnel JavaScript :keskidit:
votre avatar
TS est tout autant une surcouche à Javascript que C++ ne l'est pour le C.

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.
votre avatar
Okiii thanks :)
votre avatar
Pour le coup c'est plutôt l'inverse ; javascript n'avait aucune barrière (un peu comme les void * en c), là où typescript apporte beaucoup de contrainte, avec un bénéfice un peu de contrôle à la transpilation.
votre avatar
Un langage (semi-)compilé plus rapide qu'un interprété ?

In-cro-yable.
votre avatar
Cet article est bourré d'erreurs :
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
votre avatar
Il y a bien un compilateur TypeScript (tsc) et c'est lui qui transpile en JavaScript.
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.
votre avatar
On peut discuter pendant longtemps de la distinction fine entre un compilateur et un transpiler. Si la distinction qu'on fait est que le compilateur génère un "code machine" et un transpiler une source dans un autre langage, alors certes c'est bien un transpiler, mais d'un autre côté, JS est dans les fait le "langage machine" du navigateur, étant donné que webasm n'est pas forcément supporté partout (et apporte son lot d'inconvénients de compatibilité). Mais oui j'aimerais bien que tsc génère du webasm comme Dart...

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 comp transp 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.
votre avatar
Un transpileur est un compilateur, d'ailleurs c'est aussi appelé un "compilateur source à source".

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.
votre avatar
Le compilateur produit un autre langage pas nécessairement un langage machine ou de plus bas niveau, l'exemple typique est javac qui lit du ".java" et sort du java bytecode, ou encore gcc : "cc1" compile le C en assembleur, qui est dans un second temps compilé avec "as" en code machine

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.
votre avatar
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.
Pas tout à fait vrai, en tout cas, à une époque. Typescript a introduit le "let" pour les variables avant Javascript. Le code généré alors était plus complexe. Idem pour le support d'async/await, les décotareurs, les accesseurs, etc. car le code généré était alors compatible avec les versions courantes de javascript (il fallait donc "émuler" ces concepts).

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.
votre avatar
let / var / const : il suffit de tout remplacer par var et t'as du js "legacy"
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.
je ne connaissais pas ce comportement, là effectivement on est plus proche d'un compilateur.
votre avatar
let / var / const : il suffit de tout remplacer par var et t'as du js "legacy"
Absolument pas. un var peut être modifié, un const non. Et la portée entre un var et un let est différente. Ce n'est donc pas "juste" un remplacement de mot clé ;)

On est d'accord que le code pourra être exécuté, mais tu pourrais avoir des changements subtiles de comportements.