Discussion :

[Bill Fassinou]

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.

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

[dfiad77pro]

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é...

[blbird]

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.

[dfiad77pro]

@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

[Lcf.vs]

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

[dfiad77pro]

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

[Lcf.vs]

@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

[dfiad77pro]

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 ...

[Lcf.vs]

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.

[frfancha]

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.

[Lcf.vs]

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)

[hollaamic]

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

[defZero]

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 .

[bilgetz]

« 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.

[blbird]

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.

[air-dex]

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.

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.

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.

[frfancha]

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.

[Lcf.vs]

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.

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)

[Mister Nono]

On ne peux pas ignorer la supériorité d'un langage typé et compilé par rapport à un langage non typé et interprété.

[Mister Nono]

@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...