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.

[Zefling]

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.

J'ai fais des webapp pour mon taff et perso. Et par exemple, même sans avoir des millions d'utilisateurs, j'aurais jamais fait ce site autrement qu'en webapp. Ou faire même faire un jeu interactif.
Ça dépend complètement du projet que tu vises. J'ai d'autres sites où l’approche webapp me semble pas trop pertinente.

[blbird]

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

Ce qui impose le plus la POO, c'est surtout que les développeurs apprennent à l'école que c'est l'alpha et l'omega du codage.

La POO peut-être dans certains contextes intéressante, mais la programmation fonctionnelle (ou les fonctions sont des citoyens de première classe) devient de plus en plus préférée dans les applications modernes, notamment pour sa simplicité, sa robustesse, sa souplesse et sa lisibilité, comparé à un langage orienté classes.

Malheureusement Typescript amène souvent avec lui la couche POO (classes et héritages), sans que cela ne soit réellement intéressant dans beaucoup de cas.

[gbegreg]

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.

C'était vrai il y a 10-15 ans. Mais maintenant, avec les stores, le déploiement d'une application client-serveur n'est plus un problème. De plus, je trouve plein d'avantages à faire du natif par rapport à du dev web :
- les performances (et les consommations moindre de ressources CPU, mémoire, batterie...);
- par défaut, on utilise les composants de l'OS ciblé : on ne casse pas l'expérience de l'utilisateur qui est habitué au rendu de son OS (qui est éventuellement paramétré avec un thème particulier). On n'a pas (ou peu) besoin de travailler sur le rendu graphique des composants (pas de css particulier à gérer par exemple);
- on hérite également de l'accessibilité standard de l'OS (donc moins de travail à faire aussi de ce côté là par rapport à du dev web);
- pas besoin de navigateur (on restreint ainsi la superficie d'attaque d'un point de vue sécurité et meilleures performance là encore);
- bien souvent, on n'a pas besoin de tirer des tonnes de dépendances (là aussi d'un point de vue de la sécurité c'est un plus, la maintenance est facilité, dette technique moindre etc...);
- si pas de réseau, l'application native peut continuer fonctionner en mode dégradé et, au besoin, se synchroniser lorsque le réseau est de nouveau disponible par exemple;
- et quand on choisit de bons outils, pas besoin de runtime ou de jvm...

[fodger75]

Commencer son propos par "Refuser TypeScript est un signal que vous ne vous souciez pas de la qualité du code" est un très très mauvais argument, tentative de manipulation de bas étage.

[popo]

Ce qui impose le plus la POO, c'est surtout que les développeurs apprennent à l'école que c'est l'alpha et l'omega du codage.

La POO peut-être dans certains contextes intéressante, mais la programmation fonctionnelle (ou les fonctions sont des citoyens de première classe) devient de plus en plus préférée dans les applications modernes, notamment pour sa simplicité, sa robustesse, sa souplesse et sa lisibilité, comparé à un langage orienté classes.

Malheureusement Typescript amène souvent avec lui la couche POO (classes et héritages), sans que cela ne soit réellement intéressant dans beaucoup de cas.

C'est toujours intéressant de voir ce qu'en pensent ceux qui ne sont pas dev (puisqu'apparemment tu n'es pas un dev mais un consultant en systèmes d'information),

Déjà, attention à ne pas confondre "programmation fonctionnelle" et "programmation procédurale".
Ce sont deux paradigmes différents.

La routine décrite par Doksuri, c'est de la programmation procédurale.

Ensuite,
Il y a une raison pour laquelle l'école t'apprend la POO.
Il y a une raison pour laquelle les développeurs de Typescript (qui sont, sans aucun doute, plus qualifiés quoi toi et moi) ont utilisé la POO.

Parmi ces raisons, et en reprenant tes propres idées reçues sur la programmation procédurale, voici ma maigre contribution.

Simplicité :
Effectivement, il est plus simple et moins contraignant d'écrire des routines plutôt que des méthodes de classe.
Mais, lorsque tu commences à en avoir beaucoup et que certaines routines dépendent d'autres routines, tu te retrouves plus rapidement avec des effets de bord non prévus.
Lorsqu'une même routine est utilisé dans deux contextes différents, les ennuis commencent dès que l'un des contextes évolue et que la routine n'est plus adaptée.
Tu n'as pas ce problème en POO si tu as une classe dédié à chaque contexte.

Robustesse :
L'exemple précédent est parfait pour démontrer à quel point c'est tout sauf robuste.
Sans POO, si l'un des contexte évoluent, la routine doit être adaptée.
Tu vas devoir effectuer un test pour savoir dans quel contexte tu te situes et adapter le comportement.
Plus une routine sera utilisée dans différents contextes, plus tu vas devoir multiplier les vérifications.
Tu pourrais également dupliquer la routine pour en créer une qui sera adapté au second contexte, puis une autre adaptée à un troisième contexte, etc.
Dans les deux cas, il va arriver un moment où ça deviendra beaucoup trop complexe.
L'un des avantages de la POO, est que tout ce qui concerne un contexte est propre à un seul objet dédié à ce contexte.

Souplesse :
Toujours le même exemple.
Là où ta routine devra multiplier les vérifications de contexte, la POO résout cela, soit par le fait même qu'il y a plusieurs classes dédiés, soit dans les cas plus complexe (par exemple avec un bout de comportement commun), par l'héritage et le polymorphisme.

Lisibilité :
Toujours le même exemple.
A force de multiplier les vérifications de contexte ta routine devient rapidement illisible.
Avec la POO, tu connais le contexte et donc la classe utilisée.
Et dans cette classe, il n'y a pas tout ces IF a examiner, il n'y a qu'un seul contexte possible.

[air-dex]

JavaScript est un langage qui est réputé pour ses hérésies genre true + true == 2. Mais ceci n'est pas une fatalité. JS ne pose pas de problèmes à qui sait bien le cornaquer. Ceci passe par la maîtrise des types et ça tombe bien, TypeScript est une technologie qui a été créée pour cela, en plus d'être très compatible avec JS (un code JS est censé être un code TS valide) et de ne pas produire de code à l'excès à la transpilation (coucou Dart et ton ko de code JS spaghetti pour un "Hello world!").

Oui TS est donc une sacrée aide au codage. Mais ce n'est pas pour autant indispensable pour qui est suffisamment rigoureux sur les types lorsqu'il code en JS "pur". Sur ça et sur la différence entre true/false et truthy/falsy qui est un autre point où il faut savoir cornaquer JS en étant coalescent.

[floyer]

Oui, pour 3 lignes de code, il est facile de bien « cornaquer ».

Sur des milliers de ligne de code, avoir une vérification de type peut détecter bien des erreurs avant même le test. Pourquoi s’en priver ?