Microsoft va rendre le TypeScript « 10x plus rapide »
Le 14 mars à 07h52
2 min
Logiciel
Logiciel
Sur son blog dédié aux développeurs, Microsoft a annoncé que le TypeScript (un surensemble de JavaScript) avait un problème de performances. Sa base en JavaScript ne lui permet pas une mise à l’échelle : les performances ne suivent pas la taille des projets. L’éditeur travaillait donc à rendre le compilateur et ses outils natifs.
Microsoft a choisi le langage Go pour ce portage natif. Le projet est en cours, mais les premiers résultats semblent à la hauteur des attentes avec un temps de compilation moyen divisé par 10. Des gains très élevés ont également été observés dans le chargement des projets, la réactivité dans les éditeurs ou encore dans la consommation de mémoire vive, en moyenne divisée par deux.
L’arrivée de cette version native n’est pas pour tout de suite. La prochaine révision sera la 5.9, qui sera disponible « bientôt ». Après quoi, Microsoft passera à la branche 6.0, qui « introduira quelques dépréciations et ruptures pour s'aligner sur la base de code natif à venir ». Ce n’est que lorsqu’une parité « suffisante » aura été atteinte avec le TypeScript actuel que la version native sera lancée, en tant que TypeScript 7.0.
Le choix du Go peut bien sûr intriguer : Microsoft semblait ne jurer que par le Rust depuis quelques années. Sur X, le choix interroge. Comme le signale Analytics India Mag, Ryan Cavanaugh, responsable du développement de TypeScript, est venu expliquer ce choix sur Reddit.
Selon le développeur, c’est essentiellement une question de contraintes, dont la principale était la portabilité. Toutes les approches tentées auraient présenté des « compromis inacceptables (performances, ergonomie, etc.) », dont l’obligation d’écrire son propre ramasse-miettes (garbage collector). L’équipe se serait parfois approchée d’un résultat correct, mais au prix de nombreux pans de code non sécurisés. En définitive, un portage vers Rust aurait nécessité des années et aurait abouti à une version incompatible « que personne n’aurait pu utiliser ».
Son de cloche identique pour Anders Hejlsberg, auteur du billet de Microsoft et créateur de TypeScript, dans une interview donnée à la chaine Michigan TypeScript sur YouTube.
Le 14 mars à 07h52
Commentaires (11)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail 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
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 14/03/2025 à 08h00
Clairement je trouve Go bien plus adapté pour nombre d'outils de dev du quotidien. Et si ceux-ci sont en OSS, c'est également faciliter la prise en main de leur code base (Go reste bien plus accessible que Rust).
Le 14/03/2025 à 08h42
Le 14/03/2025 à 09h31
Modifié le 14/03/2025 à 14h27
Modifié le 14/03/2025 à 21h39
Dans ce cas, ce n'est pas forcément une optimisation pure (de celles de vrais codeurs assembleur avec la pilosité aggravée qui jouent leur vie sur un octet... que dis-je... un bit) mais peut-être le recours à une parallélisation massive. Qui requiert moins d'efforts de dev dans la conception ou la reprise de celle-ci.
Quelqu'un sait ?
Modifié le 14/03/2025 à 22h21
L'idée de Microsoft a donc été d'améliorer les choses en passant sur un langage compilé sans VM (pour gagner du temps au démarrage du programme). Cela a donc exclu C# (l'AOT n'est pas toujours la panacée).
Ensuite, le compilateur typescript étant complexe (c'est un compilateur !), l'idée était de trouver un langage proche niveau paradigme. C'est le GO qui a gagné.
Go, contrairement à Rust, dispose d'un ramasse-miette. Cela permet de traduire beaucoup plus facilement le compilateur d'un langage à l'autre. Avec Rust, il aurait fallu le réécrire entièrement à cause du paradigme de gestion de la mémoire radicalement différent.
Une réécriture complète avec changement de paradigme aurait été la source d'innombrables bogues et incompatibilités qu'il aurait fallu corriger. Il le faudra toujours avec le programme écrit en Go, mais il sera beaucoup plus facile de "vérifier la traduction" que de "comprendre le pourquoi du comment" s'il avait été réécrit en Rust.
[edit] Je précise : c'est mon interprétation de la chose. Je sais qu'il y a un sujet qui traine sur un github, mais je n'ai pas eu le courage de le lire ^^
Le 14/03/2025 à 23h37
Le 15/03/2025 à 14h44
Hier à 08h28
Le 15/03/2025 à 14h12
M'enfin, on parle d'un ersatz d'ECMAScript/JavaScript port par une bien trop grosse entreprise aux choix technologiques douteux, de toutes façons…
Le 15/03/2025 à 14h45
Le choix y est décrit. Après, on est d'accord ou pas d'accord (chacun son avis), mais c'est loin d'être un choix irréfléchi comme tu le laisses penser...