Discussion :

[Robert Vitonsky]

Refuser TypeScript est un signal que vous ne vous souciez pas de la qualité du code, par Robert Vitonsky

Il y a quelques jours, David Heinemeier Hansson a annoncé que Turbo 8 abandonnait TypeScript. Cela ne me dérange pas, car je ne sais même pas ce qu'est Turbo 8. Cependant, au cours des dernières années, certains programmeurs front-end ont essayé de me vendre l'idée que « TypeScript est inutile, il suffit d'utiliser des tests ». Je pense que les personnes ayant de telles opinions ne se soucient pas de la qualité du code ou ne savent tout simplement pas ce qu'est TypeScript. Ici, je vais expliquer pourquoi vous devriez utiliser TypeScript.*

Le contrôle de la qualité du code est un processus complexe qui permet de maintenir le code à jour. Vous ne pouvez pas simplement couvrir le code avec des tests à 100% ou examiner chaque pull request et être sûr que votre code est maintenable, et quelqu'un d'autre que vous peut le découvrir dans ce désordre.

Vous ne pouvez pas vous assurer que votre code n'a pas de bogues et qu'il est parfaitement maintenable. Vous pouvez seulement augmenter les structures défensives dans votre référentiel pour rendre difficile la diffusion de mauvais code avec des bogues. Plus il y a de barrières au mauvais code, meilleure est la qualité du code.

Cela signifie que vous devez utiliser toutes les méthodes ensemble pour protéger le code dans votre référentiel : tests unitaires/e2e/intégration, revue de code, outils d'analyse de code, et maintenir une documentation claire, etc.

TypeScript est un outil d'analyse de code puissant ; il peut détecter de nombreux défauts dans le code. Un compilateur TypeScript oblige les programmeurs à s'assurer que le code est correct au niveau des types. La valeur du typage statique est sous-estimée par David et beaucoup d'autres.

Voyons quels sont les avantages de TypeScript pour la qualité du code.

Les contrats

Les types statiques permettent de définir des contrats dans le code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
type Participant = {
	id: string;
	name: string;
};

function sayHi(participant: Participant) {
	//...
	console.log(`Hi ${participant.name}`);
}

La fonction sayHi requiert un objet avec des propriétés et des types exacts, et ne se soucie pas de ce que l'utilisateur de cette fonction fera pour répondre aux exigences. Le compilateur garantit que le type sera correct.

Un utilisateur peut fournir un objet qui ne répond pas aux exigences et transformer le type en any, mais ce n'est pas un problème pour la fonction sayHi. Il s'agit d'une délégation de responsabilité, un concept important que les développeurs doivent comprendre pour utiliser correctement TypeScript et profiter de ses avantages.

Les programmeurs doivent valider toutes les données non fiables, telles que les entrées utilisateur et autres données d'entrée-sortie, ou les résultats de l'interopérabilité avec JavaScript. Après la validation et la définition des types, ils peuvent ensuite transmettre les données au code TypeScript en étant sûrs que les contrats seront respectés car le compilateur TypeScript a vérifié le code. Si un programmeur fait un cast d'un type, il doit s'assurer que le code est correct au moment de l'exécution.

Si, dans votre projet, vous pouvez convertir des types non intersectés en n'importe quel type, à l'exception des types unknown, sans vérification au moment de l'exécution, vous avez probablement des problèmes de qualité du code dans votre projet.

Les contrats vous permettent d'éviter d'écrire une validation pour chaque fonction afin de garantir l'exactitude des données. C'est excellent pour les performances et la propreté du code, qui devient simple et stupide.


Expérience du développeur et coûts de développement

Il m'arrive d'écrire du code en JavaScript pur, principalement dans la console du navigateur pour des calculs rapides ou l'analyse de données sur une page web. Il y a quelques mois, j'ai écrit un script pour Node.js afin de traduire des fichiers locaux à l'aide de ChatGPT. Ces fichiers contenaient de longs textes, et ChatGPT avait des limites, il fallait donc un certain temps pour découper les textes, les traduire, trouver des erreurs dans les résultats de ChatGPT, retraduire si nécessaire, et enfin recouper les tranches. Ce processus a duré entre 3 et 5 minutes, en fonction de la taille du fichier local.

J'ai perdu un peu de temps au cours de ce processus à cause d'erreurs de type triviales, comme oublier d'utiliser await, ce qui a eu pour conséquence qu'une variable contenant Promise a écrit « [objet Promise] » dans le fichier au lieu du texte traduit, ou de fournir le mauvais objet comme argument d'une fonction.

TypeScript élimine ce type d'erreurs.


Investissements pour l'avenir

TypeScript offre à votre code la possibilité d'être analysé par d'autres outils parce qu'il ajoute un contexte.

Avec l'EDI, vous pouvez renommer une propriété dans une interface, et toutes les entités qui mettent en œuvre l'interface mettront automatiquement à jour le nom de la propriété à leurs places respectives.

Les outils d'intelligence artificielle tels que ChatGPT et Copilot bénéficient des méta-informations supplémentaires fournies par TypeScript, ce qui peut améliorer l'analyse et la génération de code. Les outils d'analyse peuvent mieux identifier le code potentiellement risqué.

Le typage statique et les tests se complètent bien. Le code front-end est fortement asynchrone, ce qui rend difficile la couverture de tous les cas de test possibles et la prise en compte de tous les états de code potentiels. TypeScript oblige les programmeurs à traiter tous les cas possibles d'un état, ce qui améliore la fiabilité du code.


La complexité des types

David avait déclaré :

TypeScript me gêne dans ce domaine. Pas seulement parce qu'il nécessite une étape de compilation explicite, mais parce qu'il pollue le code avec des gymnastiques de types qui ajoutent très peu de joie à mon expérience de développement, et assez souvent beaucoup de chagrin. Les choses qui devraient être faciles deviennent difficiles, et les choses qui sont difficiles deviennent n'importe quoi. Non merci !

Je cite cette phrase parce que je l'ai entendue à maintes reprises.

Il est vrai que vous devez parfois écrire des types non triviaux pour convaincre le compilateur que vos données sont correctes.

Ce n'est pas grave. La création d'un code facile à maintenir et de haute qualité nécessite souvent un travail acharné.

Conclusion

TypeScript n'est qu'un outil, il n'améliorera pas automatiquement la qualité du code si vous l'activez simplement. Votre projet doit avoir des règles en place pour utiliser l'outil correctement, et un architecte qui applique ces règles. Plus les règles sont strictes, mieux c'est.

Lorsque vous désactivez les types statiques dans votre projet, vous perdez de nombreuses possibilités de contrôler la qualité du code.

Les fichiers de déclaration de type JSDoc et .d.ts ne peuvent pas remplacer le typage statique du code. Ils permettent simplement de déclarer l'API externe des entités, mais ne permettent pas d'analyser le code à l'intérieur des entités (fonctions, classes et autres blocs de code).


Source : "Refusing TypeScript is a signal that you don't care about code quality"

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates

Tout partout en même temps : Les promesses JavaScript, par Mensur Durakovic

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

[blbird]

Typescript est bien pour imposer du typage au Javascript.

L'inconvénient principal est qu'il impose aussi de la POO, qui bien souvent (par ex. dans un projet front-end) est complétement superflue et même contre productive.

Une orientation fonctionnelle et/ou orientée composants est bien souvent plus efficace.

Les contrats de types en JS, s'ils sont bien documentés, se suffisent à eux-même.

[Doksuri]

L'inconvénient principal est qu'il impose aussi de la POO

je veux bien que tu developes ce point.

avant :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function addNumbers(num1, num2) {
  return num1 + num2;
}

apres :

Code typescript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function addNumbers(num1:number, num2:number):number {
  return num1 + num2;
}

tu peux completement coder a l'ancienne.

c'est plutot la complexite des codes qui impose de la POO

[floyer]

Pourquoi laisser la machine trouver les erreurs de type alors que l’on est assez grand pour les trouver tout seul…

C’est le genre de chose qui me détourne de JS, Python et autre language dynamique. (Ada et OCaml ont ma préférence actuellement).

Les choses qui devraient être faciles deviennent difficiles, et les choses qui sont difficiles deviennent n'importe quoi. Non merci !

Si on ne sait pas écrire le type des ses fonctions, j’imagine qu’il doit être encore plus difficile de garantir la cohérence du programme. Sinon, deux approches dans le typage statique : explicite (comme avec Ada), ou implicite avec inférence de type comme OCaml. Dans ce dernier cas, l’écriture est abrégée, mais une erreur de type est toutefois détectée à la compilation. (OCaml permet d’être explicite… c’est d’ailleurs requis pour les fonctions publiées des bibliothèques de fonctions). De plus, l’inférence de type s’intègre à VSCode et autres : on tape la fonction sans type… et VSCode affiche sous la fonction les types inférés. (S’ils diffèrent de ce à quoi on s’attend, c’est qu’il y a un bug quelque part).

[RenarddeFeu]

Il faut refuser complètement les WebApps, pas Typescript en particulier. Elles sont chères, complexes et inutiles dans 90% des cas. Les seuls grands gagnants dans l'histoire sont les ESN qui arrivent à les vendre.

[floyer]

Pourquoi refuser les WebApps ? (Des applications comme GMail ou Google Docs?) Il permettent une facilité de déploiement bien supérieure aux applications client-serveurs, ce qui est pratique lors des mises à jour.

Il y a des framework/language qui permettent de développer cela de façon plus sécurisé que JavaScript. Par exemple Ocsigen/OCaml permet de développer le frontend et le backend dans un même language : language fonctionnel avec typage statique. Son module Eliom permet dans le même source de tagguer ce qui tourne sur le client ou sur le serveur… ou tourne sur le serveur mais est accessible par le client (let%rpc f … Eliom se charge de sérialiser/désérialiser de façon transparente). Cela supporte aussi la programmation réactive. Le site Be Sport est développé ainsi.

Dans un autre style, il y a Elm, c’est un language fonctionnel à typage fort associé à un framework inspiré de la programmation réactive.

C’est probablement moins mainstream que JavaScript ou TypeScript, mais on évite d’utiliser un language ou "1" + 1 vaut "11" et "1"-1 vaut 0 ! (Et dans un language sérieux une erreur de type dès la compilation).

Logiquement WebAssembly devrait permettre le développement dans plusieurs autres languages que JS (Rust par exemple)

[RenarddeFeu]

Pourquoi refuser les WebApps ? (Des applications comme GMail ou Google Docs?) Il permettent une facilité de déploiement bien supérieure aux applications client-serveurs, ce qui est pratique lors des mises à jour.

Si ton application a plusieurs millions d'utilisateurs, alors oui la WebApp est la bonne solution.

Le problème, c'est que la majorité des WebApps n'a que quelques dizaines d'utilisateurs si bien que les facilités de déploiement et de mise à jour ne compensent jamais les complexités de développement, de gestion des droits d'accès et de sécurisation.