5 raisons pour lesquelles Deno cessera d’utiliser TypeScript
Un document a fait surface aujourd’hui indiquant que Deno cessera d’utiliser TypeScript dans son code interne, citant plusieurs problèmes avec l’environnement actuel. Les problèmes mentionnés concernent les temps de compilation TypeScript, la structuration et l’organisation du code, entre autres. À l’avenir, Deno utilisera du JavaScript pur pour son code interne.
Deno problèmes avec TypeScript
Les situations défavorables que l’équipe Deno rencontre actuellement lors de l’utilisation de TypeScript pour son code interne sont :
-
Le temps de compilation de TypeScript lorsque la modification des fichiers prend plusieurs minutes, ce qui rend la compilation continue un processus extrêmement lent
-
La structure Typescript qu’ils utilisent dans les fichiers source qui créent l’exécutable Deno réel et les API orientées utilisateur créent des problèmes de performances d’exécution
-
TypeScript ne s’avère pas utile pour organiser le code Deno. Au contraire, l’équipe Deno subit l’effet inverse. L’un des problèmes mentionnés est qu’ils se sont retrouvés avec des classes Body indépendantes en double à deux endroits https://github.com/denoland/deno/issues/4748
-
Le code interne et les déclarations TypeScript d’exécution doivent être synchronisés manuellement car le compilateur TypeScript n’est pas utile pour générer les fichiers d.ts
-
Ils maintiennent deux hôtes de compilateur TS : un pour le code interne Deno et un autre pour le code utilisateur externe, même si les deux ont un objectif similaire.
Suppression de TypeScript dans le code Deno interne
L’ équipe Deno vise à supprimer toutes les vérifications et regroupements de type TS au moment de la construction pour le code Deno interne. Ils sont impatients de déplacer tout le code d’exécution dans un seul fichier JavaScript. Cependant, ils utiliseront toujours un fichier d.ts compagnon pour conserver les définitions de type et la documentation.
Il convient de mentionner que Deno cessera d’utiliser TypeScript uniquement pour le code Deno interne : le code utilisateur Deno sera toujours dans TypeScript et donc vérifié.
Alors que TypeScript est parfois considéré comme une version améliorée de JavaScript, ce cas montre qu’en fait, ce n’est pas le cas. Il a des défauts comme n’importe quelle autre langue. L’un des plus importants est son temps de compilation lent. Bien que les petits projets puissent ne pas voir un énorme pic de temps de compilation lors du passage de JavaScript pur à TypeScript, cela sera perceptible dans les grands projets comme une application React complexe. Compte tenu de la grande taille de son environnement d’exécution, il n’est pas surprenant que Deno cesse d’utiliser TypeScript.
La sécurité de la vérification des types pendant le développement a un coût au moment de la compilation. Ce n’est pas sans raison que le projet TypeScript dispose d’un document complet sur la façon d’aborder et d’ améliorer le temps de compilation. L’une des approches les plus intéressantes consiste à utiliser Project References, qui permet aux développeurs de décomposer un gros morceau de code TypeScript en morceaux plus petits.
En savoir plus sur les raisons pour lesquelles Deno cessera d’utiliser TypeScript
La discussion complète sur la décision de supprimer TypeScript du code interne de Deno et d’utiliser JavaScript à la place se trouve dans ce document, où Ryan Dahl et ses collaborateurs discutent du problème, de sa solution et de la manière dont il va être implémenté.