Cinq vérités inconfortables à propos de TypeScript, selon Stefan Baumgartner

Cinq vérités inconfortables à propos de TypeScript, selon Stefan Baumgartner
auteur de livres sur le langage de programmation

Dans un billet de blog, Stefan Baumgartner aborde cinq vérités inconfortables sur le langage TypeScript. Tout d'abord, il rappelle que TypeScript n'est pas une version "corrigée" de JavaScript, mais plutôt un sur-ensemble de ce dernier. Il ne vous épargne donc pas JavaScript avec ses bizarreries et ses défauts. Malgré son approche graduelle, TypeScript ajoute aussi de la complexité aux projets en raison de ses nombreuses options de configuration. En outre, ce n'est pas vraiment un langage à typage sûr, en particulier lorsque des interactions avec le "monde extérieur" sont impliquées. Stefan Baumgartner affirme également que TypeScript existe sous une multitude de variantes implicites, chacune avec ses avantages et ses inconvénients. Malgré tout, il estime que TypeScript reste un langage précieux pour améliorer la productivité et la maintenabilité des projets, à condition de comprendre ses compromis et de l'utiliser correctement.

Stefan Baumgartner est un auteur de deux livres sur TypeScript, y compris le livre « TypeScript in 50 Lessons ». Chaque fois qu'il rencontre un nouveau groupe de développeurs, lors de ses ateliers et formations, il y a certaines réalités sur TypeScript auxquelles ils sont confrontés. Ce sont ces réalités qu'il a décidé de partager dans un billet de blog intitulé « Cinq vérités inconfortables à propos de TypeScript », ce que nous vous présentons ici.

1. TypeScript ne vous épargnera pas JavaScript

À chaque fois qu'il donne des ateliers sur TypeScript, il y a au moins une personne qui apprend TypeScript parce qu'elle a essayé JavaScript et que cela n'a pas fonctionné pour elle. TypeScript devrait être meilleur, n'est-ce pas ?

Stephan Baumgartner dit avoir constaté que l'idée fausse selon laquelle TypeScript est une version "meilleure" ou "corrigée" de JavaScript est très répandue. Cette idée existe depuis les tout premiers jours où TypeScript était fortement promu par des développeurs qui utilisaient généralement C#/.NET et avaient besoin d'écrire des API côté client également. C'était également la première rencontre de Stefan Baumgartner avec TypeScript : quelqu'un lui a dit qu'il avait trouvé une "meilleure version". Et c'est aussi la raison pour laquelle il a initialement rejeté TypeScript.

TypeScript étant sans aucun doute un sur-ensemble de JavaScript, M. Baumgartner rappelle que cela signifie qu'il reprend toute l'histoire, les bizarreries et les pièges de JavaScript. « Oui, cela vous aide à éviter les erreurs et à travailler avec un langage de programmation à typage dynamique. Cela génère des erreurs lorsque quelque chose ne concorde pas. Mais en son cœur, c'est toujours JavaScript. Si vous travaillez suffisamment longtemps avec TypeScript, vous verrez les zones jaunes transparaître à travers le revêtement bleu des types statiques ». Il utilise les couleurs jaune et bleue pour faire allusion respectivement à JavaScript et TypeScript.

« Le système de typage de TypeScript adopte pleinement la typage structurel - pour de bonnes raisons - et cela, combiné au fait que les types ne sont que des informations supplémentaires qui se superposent au code existant, peut être déroutant pour beaucoup de gens qui s'attendent à une transition rapide d'un langage à l'autre », dit-il. « Si vous souhaitez vous plonger dans TypeScript, ne pensez pas que vous pouvez laisser JavaScript derrière vous. Il vous trouvera, et il vous attrapera. »

2. TypeScript ajoute de la complexité à vos projets

TypeScript est connu pour son approche graduelle : utilisez autant de types que vous le souhaitez, allez aussi loin que vous le voulez. TypeScript cherche également à abaisser continuellement la barrière d'entrée, en s'assurant que les personnes qui connaissent juste suffisamment de JavaScript puissent bénéficier des informations de typage. Néanmoins, Stefan Baumgartner affirme que TypeScript ajoute une couche de complexité à votre projet dont vous devez être conscient. Et il ne parle pas seulement des types et des fonctionnalités avancées complexes comme les types conditionnels. Il parle de toutes les options de configuration, de paramètres et d'intégrations que TypeScript apporte pour être compatible avec absolument tout : Deno, Node, Babel, Webpack, Esbuild, de vieilles bibliothèques de graphiques, etc. Même avec Internet Explorer 5, dit-il pour ironiser.

« Vous avez compris l'idée. Le compilateur TypeScript est configuré via TSConfig, un énorme fichier JSON avec de nombreuses possibilités pour adapter TypeScript à vos besoins. Il y a tellement d'options de configuration différentes qu'il devient vraiment difficile de dire quelles règles sont réellement appliquées. Et une fois que vous avez surmonté cette extravagance de configuration, vous pouvez commencer à examiner tous les compromis que TypeScript fait pour vous afin d'obtenir un code sûr. TypeScript est une affaire complexe », dit-il.

Pièce jointe 641874
Stefan Baumgartner présentant les bizarreries de TypeScript lors d'une conférence

3. TypeScript n'est pas vraiment un langage à typage sûr

Cela peut être surprenant pour beaucoup, mais Stefan Baumgartner estime TypeScript n'est pas vraiment un langage à typage sûr. La vérification des types de TypeScript fonctionne très bien dans ce que Stefan Baumgartner appelle le "monde interne des types" de votre application. Cette partie où vous avez défini vos types, les opérations sur ces types et leur flux dans tout votre programme.

« Ici, tout ce qui devrait fonctionner ensemble fonctionnera ensemble, tout ce qui ne fonctionne pas provoquera des lignes ondulées rouges et des erreurs de compilation. Mais il y a des choses aux bords. Si vous quittez le monde interne de la sécurité de typage et que vous avez besoin d'accéder à des entrées-sorties quelconques : entrée utilisateur, accès aux fichiers, récupération de données sur Internet. Là, TypeScript n'a aucune idée des types en question et doit se fier à ce que vous lui dites. Vous devez faire des annotations de type, des assertions de type ou de gros contrôles de flux pour donner à TypeScript un indice de ce à quoi s'attendre. Et ces mesures sont aussi bonnes que vous. En TypeScript, vous avez la possibilité de changer un type en quelque chose d'autre à tout moment. Vous pouvez le changer d'un type large qui autorise de nombreuses valeurs mais qui est moins spécifique à un type restreint qui autorise moins de valeurs mais fournit plus d'informations à tout moment, parfois sans même le remarquer. Et il y a des situations, notamment avec les API qui retournent "any", où vous pouvez annoter quelque chose de complètement différent de ce que vous obtenez en retour. »

« Et rien ne vous en protège contre cela », explique M. Baumgartner. « Non seulement cela, mais TypeScript fait quelques exceptions où il échange la sécurité des types contre la productivité. Et ce sont ces scénarios qui peuvent vraiment vous causer des problèmes. »

4. TypeScript existe en de nombreuses variantes

Oui, pour Stefan Baumgartner, TypeScript existe en de nombreuses variantes qui ne disent pas leurs noms : vous pouvez juste faire du JavaScript avec une touche de types, ou aller à fond dans les hiérarchies de classes et en utilisant toutes les extensions de langage comme si c'était en 2012. Vous pouvez écrire principalement en React et avoir besoin de l'extension TSX. Vous pouvez aussi écrire du code fonctionnel et travailler beaucoup avec des types conditionnels et des types de tuples variadiques. Ou encore, vous pouvez utiliser des décorateurs expérimentaux qui fournissent des informations pour une multitude d'autres compilateurs qui s'exécutent par la suite. Chacun utilise TypeScript de la manière qui fonctionne le mieux pour lui, et son équipe.

Stefan Baumgartner affirme que TypeScript offre tant de possibilités qu'il n'a jamais vu un seul projet qui ressemble à un autre. Chaque équipe trouve quelque chose de différent et utilise une variété d'outils pour s'exprimer en TypeScript. Et ils viennent tous avec différents fonctionnalités et compromis. Les enums, les classes abstraites, les types conditionnels, etc. Ils viennent tous avec des compris. Les classes abstraites, par exemple, vous aident à définir un comportement partagé, mais elles n'ont aucune base dans JavaScript. Et les types conditionnels nécessitent presque toujours une documentation supplémentaire pour que les gens puissent comprendre ce qui a été fait après un certain laps de temps.

Vos décisions d'utiliser des types ou des interfaces, des énumérations constantes ou des énumérations régulières. Vos décisions d'inférer les types ou les annoter, etc. indiquent la variante de TypeScript que vous utilisez. Pour M. Baumgartner, c'est presque comme en C++, où les équipes doivent toujours décider d'un sous-ensemble du langage pour gérer la complexité. TypeScript vous demande la même chose.

5. TypeScript en vaut toujours la peine

Cela dit, Stefan Baumgartner estime que TypeScript en vaut totalement la peine. A condition de comprendre le langage, comprendre ses compromis et ses inconvénients, et comprendre ce qu'il apporte à votre projet. C'est à ces conditions que vous pourrez pleinement profiter de la puissance de TypeScript en tant que système de typage et langage de programmation. TypeScript devient alors un langage précieux pour améliorer la productivité et la maintenabilité des projets.

Source : Stefan Baumgartner

Et vous ?

:fleche: Utilisez-vous TypeScript ? Que pensez-vous du langage ?
:fleche: Etes-vous d'accord avec les "vérités inconfortables" à propos de TypeScript ?

Voir aussi

:fleche: Microsoft annonce la disponibilité de TypeScript 5.2 Beta et présente une liste rapide des nouveautés de TypeScript 5.2

:fleche: TypeScript a 10 ans ! Joyeux anniversaire. À cette occasion, Microsoft fait le point. L'entreprise revient sur les doutes des premiers jours ainsi que sur l'évolution du langage

:fleche: Le top 25 des langages de programmation les plus populaires auprès des DevOps : TypeScript a détrôné JavaScript en tant que langage préféré, Ruby est en 3è position, d'après CircleCI

:fleche: Pendant que Deno, le runtime de JS et TS, gagne en maturité, certaines entreprises tentent de l'utiliser en production, mais d'autres repartent non satisfaites à la suite des tests effectués

:fleche: Utilisez-vous TypeScript ? Que pensez-vous du langage ?

Pour résumer je considère TypeScript comme des "annotations" pour faciliter la vie de l'équipe et la réussite des projets sur le long terme.

Oui, j'utilise TypeScript (surtout en backend) où je force l'équipe à respecter des règles @typescript-eslint strictes telles que :

Code:

---

1 2 3 4 5 6 7 8

"@typescript-eslint/no-explicit-any": "error", "@typescript-eslint/explicit-function-return-type": "error", "@typescript-eslint/typedef": ["error", { "memberVariableDeclaration": true, "parameter": true, "propertyDeclaration": true }], "@typescript-eslint/prefer-optional-chain": "error"

---

ces règles forcent la précision des types au niveau des signatures de fonction/méthode et attribut de classe. Ce forcing est là pour des raisons évidentes de maintenance, si on ne respecte pas ces règles, le projet NodeJS aussi puissant soit-il devient tout simplement ingérable.

Ne perdez pas de vue que tant que TypeScript ne fera pas partie du standard JavaScript/EcmaScript, TypeScript restera juste une surcouche qui vous produira du JavaScript en sortie. Peut-être que TypeScript intégrera le standard un jour, mais d'ici là on se contentera de transpilateur tels que esbuild car il n'y a pas de support officiel de deno par les grands providers de cloud.