TypeScript 7 est officiellement disponible, et qu'est-ce qu'il est rapide !
BBetter Stack
컴퓨터/소프트웨어AI/미래기술
Transcript
00:00:00TypeScript 7 est officiellement sorti, et après plus d'un an de développement acharné,
00:00:05le portage du compilateur sous Go par Bun a prouvé qu'on pouvait tout faire avec l'IA. Donc je suis
00:00:10sûr que les développeurs en sont ravis. Si vous lancez « npm install typescript » maintenant, vous aurez la version
00:00:167, qui est celle intégrant le compilateur Go. Suite à la vidéo d'annonce de Microsoft
00:00:20il y a quelques jours, je voulais analyser en détail comment ils ont obtenu ces gains de performance
00:00:25massifs. Les résultats sont vraiment impressionnants. Le nouveau compilateur bâtit le code source de VS Code,
00:00:31soit 1,3 million de lignes de code réparties sur près de 8 000 fichiers, en seulement 10 secondes, contre 125
00:00:39secondes pour l'ancien compilateur. Et comme TypeScript trône fièrement en tête des langages sur
00:00:44GitHub, croyiez-le ou non, ce nouveau compilateur va changer la vie de tant de gens. Ça me rend ému
00:00:49rien d'y penser ! Mais plutôt que de regarder les fonctionnalités quasi identiques entre les versions 6 et 7, je voulais voir
00:00:54exactement comment cette vitesse est atteinte. Examinons ce nouveau compilateur pour comprendre ce qui
00:00:59le rend si rapide. Pourquoi cette réécriture ? Le créateur de C# et Technical Fellow chez Microsoft,
00:01:09Anders Hejlsberg, l'a expliqué très clairement : JavaScript est optimisé pour l'interface utilisateur et les navigateurs, il n'est
00:01:16pas vraiment optimisé pour les calculs intensifs et les compilateurs. C'est assez évident car il est
00:01:22monothreadé, et traiter un arbre syntaxique abstrait ou vérifier les types ne peut pas aller bien loin
00:01:27avec l'accès à un seul cœur. On pourrait théoriquement répartir le travail sur des workers, mais il faudrait
00:01:32alors sérialiser et désérialiser les données, ce qui est lent et gourmand en mémoire, sans compter
00:01:38la complexité de la gestion de tout cela. Ils ont donc opté pour Go, qui offre des gains de performances
00:01:43spectaculaires grâce à un langage sur mesure. Go est un langage compilé,
00:01:48ce qui signifie qu'on peut exécuter le code compilé directement sur le processeur sans l'interpréter. De plus, Go a un
00:01:54très bon modèle de concurrence, permettant d'exécuter facilement plusieurs threads en même temps,
00:02:00le tout avec une mémoire partagée. On peut ainsi exploiter tous les cœurs de la machine au lieu d'un seul
00:02:06seul. Le gain se répartit équitablement : jusqu'à la moitié est due à l'utilisation du code natif,
00:02:12et le reste provient de la concurrence avec mémoire partagée. Go est virtuellement le langage idéal pour cela.
00:02:17Il ne s'agit pas juste d'être plus rapide, Go dispose de plus de ressources à allouer au problème, et les résultats
00:02:23parlent d'eux-mêmes. En regardant les chiffres, VS Code et ses 1,3 million de lignes de code prenaient 125,7 secondes sur l'ancien
00:02:32compilateur contre 10,6 secondes ici, soit un gain de 11,9x. Pour Bluesky, on passe de 24,3 à 2,8, soit 8,7x d'amélioration,
00:02:42et pour Playwright, de 12,8 à 1,5 seconde, soit 8,7x d'amélioration aussi. Et amusant : il ne faut
00:02:49qu'une seconde pour s'abonner à Better Stack. Cet écart va continuer de se creuser, car la vitesse des cœurs
00:02:54n'augmente plus au même rythme qu'avant, mais nous obtenons plus de cœurs. Je suis par exemple sur un M3 Max,
00:03:00qui possède 14 cœurs, ce qui est fou. Je me souviens avoir monté un PC gamer à la fac avec un
00:03:06Intel i7 à quatre cœurs, et je trouvais que c'était un monstre sacré ! Le compilateur JavaScript n'utilisait
00:03:11qu'un seul de ces cœurs, mais avec Go, je les débloque tous. Et plus vous avez de cœurs, meilleures sont les
00:03:17performances. Si je compile un gros projet sur cette machine avec la version 6, cela prend 45
00:03:24secondes. Avec la version 7, on peut faire tomber cela à seulement 3 secondes. Il y a plusieurs
00:03:29étapes dans le processus de compilation, et la vérification des types n'en est qu'une parmi d'autres. Pour cela, Go
00:03:34va lancer 4 vérificateurs de types qui vont chacun analyser un quart de la base de code. Mais on peut
00:03:39encore optimiser cela : lors de la compilation, régler les vérificateurs sur 12 donne plus de vitesse encore.
00:03:45J'ai donc téléchargé le dépôt de VS Code sur ma machine pour comparer TypeScript 7 et 6.
00:03:51Par défaut, « tsc » sur ma machine pointe vers TypeScript 7. Exécutons le diagnostic
00:03:57dessus : vous voyez que ça a pris 5,4 secondes, et la majorité du temps a été consacrée à la
00:04:02vérification (4,7 secondes). On peut encore accélérer tout ça si l'on ajoute une option supplémentaire :
00:04:08« --checkers 12 ». Le temps total passe alors de 5,4 à 3,5 secondes. Tout cela réduit
00:04:15le temps de vérification : on passe de 4,7 à 2,9 secondes. Relançons maintenant la même
00:04:20commande, mais en utilisant cette fois TypeScript 6. Ça va prendre un peu de
00:04:23temps, donc nous allons passer en accéléré. Après cette attente, on voit que TypeScript 6 a terminé en
00:04:2845,3 secondes, contre 3,5 secondes lorsqu'on utilise tous les cœurs. C'est donc
00:04:36une amélioration effective de 15x sur ma puce M3 Max. Pour moi, c'est de là que viennent les 3,5 secondes.
00:04:43Faire cela va bien sûr impacter les autres processus, mais si vous ne faites rien d'autre,
00:04:47autant utiliser toutes les ressources de la machine. Regardons du vrai code
00:04:52du nouveau compilateur pour comprendre comment Go obtient ces performances. Voici une fonction
00:04:57« bindSourceFiles » dont le rôle est de lier chaque déclaration d'un fichier et de déterminer sa portée.
00:05:03En traitant potentiellement des milliers de fichiers, on parcourt chaque fichier, on met en file d'attente sa fonction de liaison,
00:05:09puis on attend que tout se termine. La beauté de la chose est qu'on n'a pas à se soucier de la façon dont
00:05:14ce travail est réparti sur les cœurs : le runtime de Go gère tout cela. Pas besoin de créer des threads ni de
00:05:20gérer une communication complexe entre les cœurs. On se contente de donner le travail et il gère la
00:05:26suite. En JavaScript, on pourrait écrire un code quasi identique, mais ce serait inutile pour des tâches dépendantes du CPU :
00:05:32tout s'exécuterait sur un seul thread, en séquence, même si Promise.all donne une illusion de parallélisme.
00:05:38Les workers sont techniquement une solution, mais impossible de partager des objets entre eux, seulement des octets bruts avec
00:05:43SharedArrayBuffer. Transmettre un arbre syntaxique à un worker exige donc de tout sérialiser,
00:05:48de le copier et de le reconstruire de l'autre côté. Pour un gros fichier, cela coûte plus cher que le travail lui-même.
00:05:53Fondamentalement, ce sont ces aspects qui rendent Go intrinsèquement meilleur pour les tâches dépendantes du CPU : son
00:05:58runtime gère la concurrence pour vous, et sa mémoire partagée permet de transmettre des objets
00:06:03sans devoir les copier. Au-delà du temps de compilation, ce qui sautera le plus aux
00:06:07yeux est la vitesse du serveur de langage. Quiconque a travaillé sur une grosse base de code TypeScript connaît la
00:06:13souffrance d'attendre la vérification des types, et mon dieu que les Mac Intel ont pu en souffrir ! Je me souviens d'avoir travaillé sur
00:06:20des projets il y a quelques années : il fallait ouvrir le dépôt et attendre littéralement
00:06:24jusqu'à deux minutes juste pour voir apparaître les lignes ondulées. Et à chaque modification
00:06:29effectuée, c'était d'une lourdeur incroyable. L'expérience développeur était horrible et plus personne ne voulait
00:06:34travailler sur le projet. Le nouveau serveur de langage apporte un retour instantané dans l'IDE :
00:06:40vous ouvrez un fichier, faites un changement et voyez les erreurs en quelques millisecondes à peine, même sur
00:06:46des bases de code géantes. En plus des performances, ce nouveau serveur de langage est plus stable :
00:06:51le besoin de redémarrer l'IDE quand la vérification des types plante est drastiquement réduit. TypeScript 7
00:06:57réduit les échecs de commandes du serveur de langage de plus de 80 % et les plantages de plus de 60 %.
00:07:04Ça fait moins d'ordinateurs jetés contre les murs, ce qui est plutôt une bonne chose pour l'environnement !
00:07:08Qui savait que Microsoft se souciait de la planète ? Il convient aussi de préciser qu'il s'agit d'un portage,
00:07:13pas d'une réécriture complète. L'équipe TypeScript a fait très attention à ce que le nouveau compilateur soit
00:07:19pleinement compatible avec l'ancien. Vous ne verrez probablement aucune différence, à part la vitesse. Mais
00:07:24même si vous pouvez lancer TypeScript 7 sur vos propres projets, il faudra attendre que vos paquets
00:07:29préférés s'adaptent. L'API programmatique manque encore, ce qui signifie que tout paquet qui en dépend
00:07:35devra attendre la version 7.1. Des paquets comme typescript-eslint, ts-jest ou ts-node accuseront
00:07:42donc un temps de retard. La version complète de TypeScript 7 est disponible au téléchargement, mais
00:07:47vous devez installer explicitement l'extension TypeScript 7 pour VS Code. Le paquet par défaut sera mis à jour
00:07:53à terme, mais pour l'instant, installez simplement cette extension appelée « TypeScript 7 » sur le store d'extensions
00:07:58et tout fonctionnera comme prévu. Si vous voulez en savoir plus sur les fonctionnalités de TypeScript 7, nous avons
00:08:03tourné une vidéo à ce sujet disponible ici. Et si vous aimez ce genre d'analyses, abonnez-vous
00:08:08à Better Stack pour en voir plus. J'espère que vous avez appris quelque chose, et que vous pourrez profiter
00:08:12du développement ultra-rapide qu'offre TypeScript 7. Je sais en tout cas que je vais adorer
00:08:16l'utiliser ! Merci d'avoir regardé, et on se retrouve bien sûr dans la prochaine vidéo.