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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

89PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de hollaamic
Membre à l'essai https://www.developpez.com
Le 11/03/2021 à 21:16
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
9  0 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 11/03/2021 à 19:17
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.
8  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/03/2021 à 18:56
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
6  1 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/03/2021 à 17:45
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é...
4  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/03/2021 à 19:10
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 ...
4  0 
Avatar de bilgetz
Membre averti https://www.developpez.com
Le 12/03/2021 à 8:10
« 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.
4  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/03/2021 à 18:44
@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
2  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 11/03/2021 à 21:43
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 .
2  0 
Avatar de blbird
Membre chevronné https://www.developpez.com
Le 12/03/2021 à 8:25
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.
1  0 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 14/03/2021 à 9:45
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.
1  0