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 11 mars 2021 à 14:26, par Bill Fassinou

184PARTAGES

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 ?