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