IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Conception Web Discussion :

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


Sujet :

Conception Web

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Nouveau candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2025
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Mai 2025
    Messages : 4
    Par défaut Refuser TypeScript est un signal que vous ne vous souciez pas de la qualité du code
    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.*

    Nom : 1.jpg
Affichages : 100798
Taille : 38,1 Ko

    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

  2. #2
    Membre éclairé

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    771
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 771
    Par défaut
    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.

  3. #3
    Membre Expert
    Avatar de Doksuri
    Profil pro
    Développeur Web
    Inscrit en
    Juin 2006
    Messages
    2 498
    Détails du profil
    Informations personnelles :
    Âge : 55
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2006
    Messages : 2 498
    Par défaut
    Citation Envoyé par blbird Voir le message
    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
    La forme des pyramides prouve que l'Homme a toujours tendance a en faire de moins en moins.

    Venez discuter sur le Chat de Développez !

  4. #4
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    486
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 486
    Par défaut
    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).

  5. #5
    Membre confirmé
    Homme Profil pro
    Architecte réseau
    Inscrit en
    Février 2024
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Février 2024
    Messages : 274
    Par défaut
    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.

  6. #6
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    486
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 486
    Par défaut
    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)

  7. #7
    Membre éclairé

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    771
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 771
    Par défaut
    Citation Envoyé par Doksuri Voir le message
    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.

  8. #8
    Expert confirmé
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    Mars 2005
    Messages
    2 981
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 2 981
    Par défaut
    Citation Envoyé par blbird Voir le message
    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.

  9. #9
    Membre extrêmement actif Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 707
    Par défaut
    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.

  10. #10
    Membre habitué
    Femme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2024
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Autre

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : Juillet 2024
    Messages : 24
    Par défaut
    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.

Discussions similaires

  1. [EDI] Quel est l'éditeur que vous recommandez pour PHP ?
    Par Lana.Bauer dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 400
    Dernier message: 10/04/2018, 20h08
  2. Réponses: 10
    Dernier message: 23/08/2017, 11h41
  3. est ce que vous pouvez m'expliquez la ligne de code suivante?
    Par KTARIK dans le forum Général Python
    Réponses: 2
    Dernier message: 06/05/2014, 12h37
  4. Math.round, c'est plus compliqué que vous le pensez ! =)
    Par patriccote dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 06/09/2011, 18h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo