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

TypeScript Discussion :

Comment un développeur JavaScript anti-TypeScript est devenu un fan de TypeScript ?


Sujet :

TypeScript

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 298
    Points
    66 298
    Par défaut Comment un développeur JavaScript anti-TypeScript est devenu un fan de TypeScript ?
    Comment un développeur JavaScript anti-TypeScript est devenu un fan de TypeScript ?
    Voici les raisons de Chirag Swadia, un développeur JavaScript reconverti en développeur TypeScript

    TypeScript est un langage libre et open source développé et maintenu par Microsoft. C'est un surensemble de JavaScript, c'est-à-dire qu'il contient tous ses éléments. Le langage a gagné en popularité ces dernières années et est le langage principal du framework Angular conçu par Google. Selon certains rapports, environ 60 % des développeurs JavaScript utilisent déjà TypeScript, et environ 22 % souhaitent l'essayer. Alors, TypeScript est-il un meilleur choix que JavaScript ? Existe-t-il des raisons pour lesquelles un développeur devrait choisir TypeScript au lieu de JavaScript ?

    JavaScript a-t-il une courbe d'apprentissage plus facile que TypeScript ?

    Historiquement, JavaScript est le principal langage de script des pages et applications Web. Il est maintenant possible d'utiliser JavaScript à la fois sur le front-end et le back-end avec des frameworks comme Node.js et Deno. De même, des outils comme Electron ont rendu JavaScript encore plus populaire, car il permet désormais de concevoir des applications pour le bureau. De nombreuses applications populaires pour le bureau utilisent déjà cette technologie, que ce soit sur macOS, sur Windows ou sur Linux. En fait, Electron est un framework permettant de développer des applications multiplateformes en utilisant des technologies du Web.

    Nom : large.png
Affichages : 40302
Taille : 336,0 Ko

    TypeScript, étant un surensemble de JavaScript, a ajouté des éléments comme les types aux fonctions/variables et beaucoup d'autres concepts qui manquaient au JavaScript pour l'"améliorer" et répondre aux exigences du compilateur TypeScript. Cependant, Chirag Swadia, alors développeur JavaScript, a déclaré qu'il voyait tout ceci comme de l'ingénierie excessive qui n'apportait aucun avantage significatif. Ce dernier a ajouté qu'il trouvait TypeScript lent et "ennuyeux", car il obtenait toujours des erreurs de compilation difficiles à comprendre. « Je me grattais la tête pour essayer de comprendre le problème », a-t-il déclaré.

    « Cela a provoqué une certaine frustration, et j'ai commencé à détester TypeScript. L'autre raison pour laquelle je détestais TypeScript était ses concepts avancés, dont les génériques. Ils étaient très difficiles à comprendre et j'ai commencé à avoir l'impression d'être dans le monde Java, où chaque morceau de code est fortement typé et écrasant. Même écrire un petit code en quelques lignes me faisait peur lorsque j'ai commencé à apprendre TypeScript », a confié Swadia. Il a déclaré que, pour ces raisons, même s'il continuait d'apprendre TypeScript avec des tutoriels ou en lisant des livres, il n'a jamais travaillé sur une application d'entreprise écrite en TypeScript.

    « En fait, j'avais l'habitude de choisir JavaScript plutôt que TypeScript (s'il y avait un choix) pour les devoirs à domicile dans le cadre du processus d'entretien avec les entreprises », a-t-il déclaré. Cependant, après avoir accepté un poste où travailler avec JavaScript n'était pas une option, il n'a pas eu d'autres choix que de revoir ses habitudes, car toutes les applications sur lesquelles il devait travailler étaient écrites en TypeScript (avec seulement du code hérité en JavaScript). Alors comment passe-t-on d'un développeur JavaScript pur à un fan incontesté de TypeScript ?

    Les raisons pour lesquelles l'on devrait "préférer" TypeScript à JavaScript

    Swadia dit avoir été submergé par la situation dans un premier temps, ajoutant que sa "rage" contre TypeScript s'est accrue. Toutefois, il a déclaré qu'il a fini par comprendre quelques mois après les avantages et les raisons pour lesquelles l'on devrait préférer TypeScript à JavaScript. Voici les 3 principales raisons pour lesquelles Swadia est devenu un fan de TypeScript.

    Rendre les états impossibles impossibles

    « C'est la raison principale pour laquelle j'aime TypeScript », a déclaré Swadia. Il s'agit en effet d'une phrase populaire chez les développeurs utilisant le langage Elm, mais le concept est également utilisé dans la communauté TypeScript, ainsi que d'autres langages de programmation. Dans la communauté, les états impossibles, ou états absurdes, sont décrits comme les états du système qui n'ont aucun sens. Il s'agit très probablement d'un sous-produit de la façon dont vous stockez votre état. L'idée de "rendre les états impossibles impossibles" signifie essentiellement que ces situations ne devraient jamais se présenter.

    Cela signifie que vous devez concevoir des API qui font une distinction claire entre les états possibles d'un composant. Cela rend le composant plus facile à maintenir et à utiliser. Notez que le système de types vous aide à prévenir les bogues avant qu'ils n'arrivent en production, mais il ne peut pas identifier tous les bogues sans votre aide. Si vous vous assurez que vos types ne permettent pas d'états invalides, votre système de types prendra soin de s'assurer que votre programme ne se retrouvera pas dans un mauvais état. Cette vidéo du développeur Richard Feldman illustre brièvement le concept dans le langage Elm.



    Par ailleurs, l'approche "rendre les états impossibles impossibles" ne sera pas utile s'il n'y a pas un moyen d'exprimer l'impossibilité par un système de types. Enfin, l'on estime que l'approche "rendre les états impossibles impossibles" n'est qu'un des types d'erreurs dites de "logique métier" qu'il est possible de prévenir à l'aide du système de types. Enfin, les développeurs avertissent cependant que "rendre les états impossibles impossibles" n'empêche pas les boucles infinies et ne prouve pas que tous les états sont atteignables.

    Ainsi, vous devez garder à l'esprit que cette technique réduira considérablement le nombre de bogues dans votre application, mais cela ne signifie pas que vous en avez formellement prouvé l'exactitude.

    Repérer les bogues rapidement

    Selon Swadia, la deuxième raison pour laquelle vous devriez choisir TypeScript au lieu de JavaScript est que le premier vous permet de repérer facilement les bogues. « En travaillant sur JavaScript, j'ai rencontré de nombreux cas où des bogues ont été repérés en production en raison d'un cas particulier qui s'est produit parce qu'il n'y avait pas de vérification de type sur le front-end. Ces bogues peuvent être évités et détectés au moment de la compilation par le compilateur TypeScript, ce qui vous fera gagner des heures dans le cycle DEV-QA », a déclaré Swadia.

    Il continue en disant qu'avec TypeScript, tout reste tel qu'il a été défini initialement. Si une variable est déclarée comme booléenne, elle le sera toujours et ne se transformera pas en un nombre. « Cela augmente la probabilité que le code fonctionne comme il était initialement prévu. En bref, le code est prévisible », justifie-t-il.

    Un support riche dans les EDI et un refactoring facile

    En troisième position, Swadia a déclaré que les EDI offrent un support complet et riche pour TypeScript et qu'il rend facile le refactoring. « Les informations sur les types rendent les éditeurs et les environnements de développement intégrés beaucoup plus utiles. Ils peuvent offrir des fonctionnalités telles que la navigation dans le code et l'autocomplétion, en fournissant des suggestions précises. Vous obtenez également un retour d'information pendant la saisie : l'éditeur signale les erreurs, y compris celles liées aux types, dès qu'elles se produisent », a écrit Swadia, citant un rapport de la société de conseils en technologie AltexSoft.

    Selon lui, tout cela vous aide à écrire un code facile à maintenir et se traduit par une augmentation significative de la productivité. En outre, Swadia estime que le refactoring, ou la mise à jour de l'application sans changer son comportement, est nécessaire pour que la base de code reste robuste et maintenable. Il a déclaré que TypeScript rend cet important processus moins pénible. « Avec des IDE qui en savent beaucoup sur votre code, vous êtes équipé d'outils de navigation tels que "trouver toutes les références" ou "aller à la définition" », a-t-il expliqué.

    « De plus, de nombreuses erreurs sont repérées automatiquement. Par exemple, si vous renommez une fonction et que vous oubliez ensuite de changer le nom quelque part, TypeScript vous alertera sur le problème. Cela simplifie et accélère le refactoring, ce qui est particulièrement bénéfique lorsque vous traitez de grandes parties de la base de code », a-t-il ajouté.

    Source : Chirag Swadia

    Et vous ?

    Quel est votre avis sur le sujet ?
    Utilisez-vous TypeScript ? Le préférez-vous à JavaScript ?
    Selon vous, faut-il préférer TypeScript à JavaScript ? Si oui, quelles sont les raisons ?

    Voir aussi

    The State of the Octoverse 2020 : Python et TypeScript gagnent en popularité parmi les langages de programmation, alors que JavaScript continue d'être le langage le plus populaire sur GitHub

    State of JavaScript 2020 : TypeScript leader incontestable des déclinaisons de JavaScript, le typage statique devient la fonctionnalité la plus demandée et React reste le framework front-end dominant

    La version bêta de TypeScript 3.7.0 est disponible avec la prise en charge de l'opérateur de chaînage d'optionnels (?.) et l'opérateur (??)

    La version 3 de Svelte, un framework JavaScript de composants graphiques, supporte officiellement le langage de programmation TypeScript, depuis juillet 2020

  2. #2
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 544
    Points : 1 748
    Points
    1 748
    Par défaut
    pour moi un des autres gros avantages de typescript est aussi coté définition de client d'API (générée à partir de swagger).

    quel bonheur de plus avoir à fouiller toute la stack pour faire du front.

    Bon après on trouve toujours des boulets qui te mettent 'any' partout.

    J'ai l'impression que beaucoup de gens se sont brouillé avec typescript et n'ont pas cherchés à comprendre car c'est Microsoft qui l'a inventé...

  3. #3
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    760
    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 : 760
    Points : 2 095
    Points
    2 095
    Par défaut
    Mon soucis avec Typescript, c'est que trop souvent il est utilisé pour forcer une couche Objets au-dessus de JS, alors que perso j'utilise justement JS uniquement en tant que langage fonctionnel sans les concepts POO de classes, d'héritages et d'interfaces.

    Quel bonheur d'ouvrir un projet JS sans avoir des fichiers Ixxxx, et des classes partout dans tout les sens, alors que l'intérêt est quasiment nul pour beaucoup de projets front-end.

    Pour moi, l'avantage du typage fort est complètement anéanti par l'utilisation excessive d'une surcouche PO Objets qui n'apporte rien, sur un langage qui fait de la PO fonctions.

  4. #4
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 544
    Points : 1 748
    Points
    1 748
    Par défaut
    @blbird

    en effet, c'est souvent une bêtise de vouloir faire comme java (voir C#) en TS

    maitriser typescript veut aussi dire être bon en javascript.

    c'est un parfait exemple des différences en reactTs et Angular (injection de dépendance via annotation, etc)

    sans être forcément un fanatique du fonctionnel, un code js fonctionnel transformé juste en typant est déja plus maintenable

  5. #5
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    Points : 808
    Points
    808
    Par défaut
    Le TypScript ? C'est un langage...
    • contaminant
    • où seules les features qui peuvent faire du buzz ou nécessaires à la plus grande masse sont supportées, mais dès qu'on rentre dans du plus technique, les features nécessaires ne sont pas assez populaires pour être considérées
    • où il y a ce forcing classes est juste contreproductif et inutile quand on maîtrise le JS.
    • où plein de features ES5 basiques ne sont pas supportées ou qu'en surface
    • qui ne force pas l'intégrité à l'exécution... alors qu'on a souvent des scripts interagissant avec des scripts tiers pouvant altérer le comportement
    • qui ajoute une stack au développeur, tant en termes de configuration qu'en termes de langages, puisqu'il n'est pas suffisant sans un réel apprentissage du JS

  6. #6
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 544
    Points : 1 748
    Points
    1 748
    Par défaut
    en effet utiliser anticore est la solution au covid et au réchauffement climatique ! Trève de plaisanterie, je suis d'accord avec toi sur le fait qu'un bon dev TS doit être avant tout un bon dev JS

  7. #7
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    Points : 808
    Points
    808
    Par défaut
    @dfiad77pro : plutôt qu'un TS, j'préfère miser sur une vraie robustesse, à l'exécution...

    Mon approche ? https://www.npmjs.com/package/@etchedjs/etched

  8. #8
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 544
    Points : 1 748
    Points
    1 748
    Par défaut
    je comprend ton point de vue, mais après faut pas oublier qu'en entreprise t'a des stack lourdes et de multiple dev qui passent sur des modules donc la pseudo sécurité du TS est souvent intéressante dans un monde ou on embauche de des JS qui ne savent pas ce que c'est qu'un prototype, la porté du this, le clean code, etc...

    et pis quand on voit le nombre de gens qui en ont rien a faire de warnings voir erreurs au runtime

    mon en résumé un mauvais dev JS sera sans doute un mauvais dev TS ...

  9. #9
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    Points : 808
    Points
    808
    Par défaut
    Oui, je ne dis pas, la validation par TSC a des avantages... mais il aurait sans douté été préférable de la faire lors d'un bundling, par exemple, tout en restant en JS.

  10. #10
    Membre éprouvé

    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    506
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Novembre 2009
    Messages : 506
    Points : 1 291
    Points
    1 291
    Par défaut
    Citation Envoyé par Lcf.vs Voir le message
    Le TypScript ? C'est un langage...
    où il y a ce forcing classes est juste contreproductif et inutile quand on maîtrise le JS.
    TypeScript propose les classes mais ne force en rien à les utiliser.
    Nous avons des très gros projets TypeScript sans utiliser une seule classe.
    Et TypeScirpt est un pur bonheur pour le refactoring.

  11. #11
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    Points : 808
    Points
    808
    Par défaut
    Citation Envoyé par frfancha Voir le message
    TypeScript propose les classes mais ne force en rien à les utiliser.
    Nous avons des très gros projets TypeScript sans utiliser une seule classe.
    Et TypeScirpt est un pur bonheur pour le refactoring.
    Selon moi, il pousse tout de même trop dans cette direction, je ne doute pas qu'on puisse bosser sans mais si, à cela, tu ajoutes les limites du TS, cela peut sacrément limiter un projet.

    Notamment, quand tu bosses pas mal avec de l'immutable (et je ne parle pas de la lib de Facebook), cela peut vite devenir très contraignant... j'ai eu plein de cas, avec le développement d'etched, ne serait-ce que pour décrire les types, qui sont juste impossibles à faire, en TS, de l'aveu de leur team... je n'ai pu faire des déclarations au mieux possible (d'où le fait que je n'aie cherché à les publier sur le @types)

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 2
    Points : 13
    Points
    13
    Par défaut
    Ou : Comment un developpeur incapable de lire les messages d'erreur les plus élémentaires a découvert les avantages d'un langage fortement typé pour la vie en entreprise

  13. #13
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    Mai 2015
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2015
    Messages : 429
    Points : 1 631
    Points
    1 631
    Par défaut
    Quel est votre avis sur le sujet ?

    Pour moi TypeScript étant un sur-ensemble de JS, il ne fait que rajouter du sucre syntaxique et des validations à ce dernier.
    Après tout du code JS valide est du code TS valide aussi.

    Je serait plus en faveur d'une généralisation des langages tel que ReasonML / ReScript / Elm ..etc en Entreprise.
    Tout simplement car ils ont la propriété de se baser sur un sous-ensemble admissible de JS ("The Good Part" quoi).

    Utilisez-vous TypeScript ? Le préférez-vous à JavaScript ?

    J'ai essayé et est préféré ReasonML et autres langage plus "propre".
    Après si le choix ne porte qu'entre ces deux là, évidemment je préfère TS, ne serait-ce que pour la "validation" des types à la compilation.

    Selon vous, faut-il préférer TypeScript à JavaScript ? Si oui, quelles sont les raisons ?

    Oui, tout simplement parce que TS fournit les même fonctionnalités (logique pour un sur-ensemble me direz vous), mais avec des garanties supplémentaire.
    Alors il est loin d'être parfait, mais à choisir, je prend le sucre syntaxique et les validations en rab .

  14. #14
    Membre averti
    Inscrit en
    Octobre 2005
    Messages
    135
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 135
    Points : 391
    Points
    391
    Par défaut
    « En travaillant sur JavaScript, j'ai rencontré de nombreux cas où des bogues ont été repérés en production en raison d'un cas particulier qui s'est produit parce qu'il n'y avait pas de vérification de type sur le front-end. Ces bogues peuvent être évités et détectés au moment de la compilation par le compilateur TypeScript, ce qui vous fera gagner des heures dans le cycle DEV-QA », a déclaré Swadia.
    Alors si tu commence à faire confiance au client pour faire ta vérification de type, le problème c'est pas le langage, c'est le dev.
    La vérification coté client, ce n'est que du confort / économie de bande passante. Il faut toujours vérifier coté serveur tes données venant d'un client.

  15. #15
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    760
    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 : 760
    Points : 2 095
    Points
    2 095
    Par défaut
    Citation Envoyé par frfancha Voir le message
    TypeScript propose les classes mais ne force en rien à les utiliser.
    Nous avons des très gros projets TypeScript sans utiliser une seule classe.
    Et TypeScirpt est un pur bonheur pour le refactoring.
    Merci de ton retour, c'est bon à savoir que ça existe.

  16. #16
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 667
    Points : 3 812
    Points
    3 812
    Par défaut
    L'un des avantages de TypeScript est son côté "JS bullshit manager", où il prend à son compte certaines erreurs de base que l'on ferait s'il n'était pas là. Un peu comme jQuery, mais dans un autre registre.

    Citation Envoyé par dfiad77pro Voir le message
    Bon après on trouve toujours des boulets qui te mettent 'any' partout.
    Perso j'ai instauré comme bonne pratique dans mes dev le fait de bannir l'inférence de types autant que faire se peut. Cela laisse moins de hasard quant à ce que le compilateur comprend. D'ailleurs en parlant de compréhension, l'inférence de type se résume à un "on se comprend" entre celui qui a écrit ça et celui qui lit le code, ce qui à partir d'un certain point peut poser problème.

    Après l'inférence de types a aussi ses avantages. C'est juste qu'il faut savoir l'utiliser avec parcimonie.

    Citation Envoyé par dfiad77pro Voir le message
    J'ai l'impression que beaucoup de gens se sont brouillé avec typescript et n'ont pas cherchés à comprendre car c'est Microsoft qui l'a inventé...
    Les fameux qui abrègent Microsoft avec un dollar.

  17. #17
    Membre éprouvé

    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    506
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Novembre 2009
    Messages : 506
    Points : 1 291
    Points
    1 291
    Par défaut
    Citation Envoyé par Lcf.vs Voir le message
    Notamment, quand tu bosses pas mal avec de l'immutable (et je ne parle pas de la lib de Facebook), cela peut vite devenir très contraignant... j'ai eu plein de cas, avec le développement d'etched, ne serait-ce que pour décrire les types, qui sont juste impossibles à faire, en TS, de l'aveu de leur team... je n'ai pu faire des déclarations au mieux possible (d'où le fait que je n'aie cherché à les publier sur le @types)
    En effet y a sans doute des cas compliqués si pas impossibles quand tu veux écrire ton propre framework.
    Pour nos états autre que des types élémentaires on utilise immer.
    C'est presque transparent et comme les états "fabriqués" par immer sont readonly ça bloque toute erreur qui irait écrire dedans.
    On a décidé de ne pas ajouter le flag readonly aux types typescript, donc si un objet de type T n'est pas un état mais une structure de calcul temporaire elle reste mutable.

  18. #18
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    Points : 808
    Points
    808
    Par défaut
    Citation Envoyé par frfancha Voir le message
    En effet y a sans doute des cas compliqués si pas impossibles quand tu veux écrire ton propre framework.
    Oui, et ils en sont visiblement conscients, on m'a répondu que TypeScript est surtout destiné aux utilisateurs de bibliothèques et frameworks, afin de couvrir les besoins les plus courants (suite à quoi je n'ai pas trop pu m'empêcher de voir comme un "CMS" du JS).

    J'ai donc fait mes déclarations TS, de manière à faciliter le taff des IDEs, pour la complétion de code, ne pouvant faire davantage que ce que le TS permet... après, je continue de surveiller l'évolution du TS, des fois que j'puisse aller plus loin, un jour.

    Citation Envoyé par frfancha Voir le message
    Pour nos états autre que des types élémentaires on utilise immer.
    Je n'en avais jamais entendu parler, c'est une approche intéressante, surtout l'aspect "basé sur les objets natifs"... mais j'ai souvent besoin d'aller plus loin, en termes de contraintes et de gestion de fusions d'objets, tel que:
    • Déterminer les propriétés que l'on souhaite avoir dans l'objet résultant, aucune autre n'est permise... pratique quand on manipule des objets de provenance externe (clients, services tiers, ...)
    • Appliquer des contraintes pouvant être complexes (genre min/max/step, etc., comme avec les formulaires) sur chaque propriété
    • Pouvoir cumuler les contraintes pour une même propriété


    Si tu es curieux, tu peux en voir quelques exemples dans mon lab (le dossier lab illustre l'utilisation qu'on en ferait dans un projet et, via le bouton Show, en haut de page, tu peux afficher une page te montrant les résultats en console)

  19. #19
    Membre chevronné Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur Mathématiques et Informatique
    Secteur : Santé

    Informations forums :
    Inscription : Septembre 2002
    Messages : 2 234
    Points : 1 897
    Points
    1 897
    Par défaut
    On ne peux pas ignorer la supériorité d'un langage typé et compilé par rapport à un langage non typé et interprété.

  20. #20
    Membre chevronné Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur Mathématiques et Informatique
    Secteur : Santé

    Informations forums :
    Inscription : Septembre 2002
    Messages : 2 234
    Points : 1 897
    Points
    1 897
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    @blbird

    en effet, c'est souvent une bêtise de vouloir faire comme java (voir C#) en TS
    Ah bon ? Et pourquoi PHP qui comme du JS permettait de faire tout et n'importe quoi a-t-il trouvé des lettres de noblesse grâce à Symfony qui rappelle les bonnes pratiques et méthodologies des langages typés et compilés ?

    Soyons professionnel et reconnaissons l'évidence...

Discussions similaires

  1. Pourquoi utiliser TypeScript - Une introduction à TS
    Par Paleo dans le forum TypeScript
    Réponses: 8
    Dernier message: 30/06/2017, 17h18
  2. [WD17] pourquoi WinDev n'a pas plus de fan?
    Par PoloLeFou dans le forum WinDev
    Réponses: 3
    Dernier message: 04/12/2012, 08h13
  3. Devenir fan de Developpez.com
    Par Khleo dans le forum La taverne du Club : Humour et divers
    Réponses: 1
    Dernier message: 29/11/2009, 18h19

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