Avons-nous vraiment besoin de TypeScript en 2020?

TypeScript est devenu l'une des compétences essentielles d'un développeur Web moderne. En 2019, il est entré dans le TOP 10 des langues les plus utilisées sur GitHub , son support a été entièrement ajouté à l'application Create react, et vous pouvez trouver de nombreuses autres preuves de sa popularité croissante. Dans le même temps, des langages comme Java et C continuent de perdre du terrain .

Lorsque nous parlons des avantages de TypeScript, la liste suivante vient généralement à l'esprit:

• TypeScript prend en charge la saisie statique
• TypeScript facilite la lecture et la compréhension du code.
• TypeScript aide à éviter les nombreux bogues douloureux que les développeurs font généralement, grâce à la vérification de type dans le code
• TypeScript encourage les développeurs à suivre les meilleures pratiques de POO
• À la suite de ce qui précède - TypeScript fait gagner du temps aux développeurs

Fait intéressant, tous les éléments de cette liste sont pris sur la foi sans œil critique. Aujourd'hui, je vous suggère d'examiner ces points de plus près et de découvrir s'ils nous sont vraiment si utiles.

Étant donné que l'objectif principal de TypeScript est de réduire le nombre de bogues, décidons pourquoi cela est si important? La réponse est simple: moins il y a de bogues - moins nous passons de temps pour les développeurs et les testeurs - nous obtiendrons un produit intéressant pour moins d'argent et il commencera à générer des revenus plus tôt.

Dans cet esprit, découvrons comment TypeScript peut nous aider à améliorer notre productivité et notre efficacité.

Saisie statique - une tablette magique pour les bugs?

La principale caractéristique de TypeScript est la prise en charge de la frappe statique. Les développeurs estiment que la frappe dynamique est à l'origine de presque tous les problèmes rencontrés par les développeurs JavaScript.

Je me demande ce que les mauvaises personnes trouvent dans la frappe dynamique? Pourquoi un tel barrage de critiques ne tombe-t-il pas sur d'autres langages dynamiques, par exemple, Python et Ruby? Je peux seulement supposer que le problème n'est pas tant dans la frappe dynamique que dans la fonte de type en JavaScript. En effet, il peut parfois être très désagréable de surprendre un code comme celui-ci:


Mais c'est un problème plutôt une mauvaise connaissance de JavaScript, et non du langage lui-même. Imaginez que vous ayez une puissante voiture de sport. Mais vos compétences de conduite sont assez médiocres. Aurez-vous besoin du constructeur automobile pour apporter des modifications afin de réduire la vitesse maximale de la voiture ou apprendre la conduite avancée et devenir un professionnel hors pair? Ce que nous propose TypeScript, c'est de limiter les possibilités de frappe dynamique, plutôt que d'apprendre correctement JavaScript.

Une autre question pour les opposants au typage dynamique est que si le typage statique est si bon, pourquoi rencontrons-nous encore des bogues dans le code écrit en Java et C #? Oui, nous pouvons détecter ces erreurs au stade de la compilation, mais soyons honnêtes, ce n'est pas suffisant. Nous devons suivre les principes SOLIDES et les autres meilleures pratiques pour garantir un code de qualité. Et encore une fois - cela s'applique davantage aux connaissances et aux qualifications des programmeurs qu'au langage de programmation.

Le code TypeScript est-il plus facile à lire?

Voici 2 exemples de Redux Thunk:

const getUsers = async dispatch => { //... try { const users = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

et la même chose sur TypeScript:

 const getUsers = (): ThunkAction<void, {}, {}, AnyAction> => async (dispatch: ThunkDispatch<{}, {}, AnyAction>) => { //... try { const users: User[] = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

Que signifient tous ces génériques? Pourquoi y a-t-il 2 objets vides en eux? Combien de temps devrions-nous consacrer à la lecture de la documentation pour tout comprendre? Eh bien, c'est toujours normal pour Redux Thunk, car il s'agit d'un middleware très populaire pour Redux, ils ont une excellente équipe d'assistance et une excellente documentation. Mais que faire si nous devons maintenir un code qui n'a pas tout cela?

Il n'y aura plus de bugs subtils?

Dans l'exemple précédent, vous avez vu comment TypeScript rend le code plus détaillé. Comme vous le savez, plus le système est grand et complexe, plus la probabilité d'erreur est grande. En plus des erreurs que nous pourrions faire dans le code JavaScript, nous devons également prendre soin de ne pas faire de faute de frappe dans les interfaces, une erreur dans les génériques, etc. En toute honnêteté, il convient de noter que le compilateur vous aidera à trouver et à corriger rapidement de telles erreurs, mais sans TypeScript, nous ne les aurions pas rencontrées du tout.

Suivre les meilleures pratiques de la POO

Comme nous le savons, nous devons suivre les meilleures pratiques si nous voulons écrire du code de haute qualité, facilement évolutif et maintenable. Et TypeScript peut nous y aider. Cela sonne bien, regardons un exemple d'Express:

userRoute.js

 router.get('/users', (req, res) => { //get users from DB res.json(users) }) router.post('/users', (req, res) => { //create user res.json(userCreated) }) 

userRoute.ts

 class UserRouter { public router = express.Router() public address = '/users' constructor() { this.initRoutes() } initRoutes() { this.router.get(this.address, this.getUsers) this.router.post(this.addressm this.createUser) } getUsers(req: express.Request, res: express.Response) { //get users from DB res.json(users) } createUser(req: express.Request, res: express.Response) { //create user res.json(userCreated) } } 

La première chose qui attire votre attention est que davantage de code est en cours d'écriture. Nous utilisons des classes pour écrire dans le style OOP. Nous devrons alors instancier ces classes. De plus, nous pouvons utiliser des interfaces, des types statiques et d'autres constructions. Et pour que tout cela ne se transforme pas en chaos complet, nous n'avons d'autre choix que d'utiliser les meilleures pratiques. Et c'est ce qu'on appelle: «encourager les développeurs à utiliser les meilleures pratiques de POO» .

Lorsque les développeurs ont voté pour des langages simples, flexibles et dynamiques tels que JavaScript et Python, lorsque le paradigme de programmation fonctionnelle a montré ses avantages et sa capacité à résoudre certains problèmes de manière plus élégante et efficace (et en JavaScript, nous pouvons utiliser les deux approches), TypeScript nous pousse à pour écrire du code à l'ancienne dans le style de OOP Java et C #.

Pour résumer, nous avons vu que TypeScript ne nous fait pas vraiment gagner du temps, il ne nous protège pas d'un grand nombre de bugs, ni augmente notre productivité. De plus, cela nécessite d'écrire plus de code, une configuration supplémentaire, des fichiers de définition de type et de perdre du temps à lire de la documentation supplémentaire. Un débutant écrira probablement, peut-être pas une application idéale, mais qui fonctionne en JavaScript ou Ruby, tandis que nous écrirons une excellente application TypeScript conformément à tous les principes. Et puis il nous embauchera pour réécrire sa startup, où nous pouvons utiliser TypeScript pour tout faire correctement.

C'est drôle de voir à quel point les langages massifs, verbeux et compliqués disparaissent, incapables de rivaliser avec des langages plus dynamiques et simples, puis ces derniers refusent tout ce qui les a aidés à se développer si rapidement et s'efforcent de devenir plus lourds, plus verbeux et plus compliqués.

Je le vois comme ça:

D'accord, nous ne voulons plus de Java, nous voulons JavaScript. Mais nous n'aimons pas JavaScript tel qu'il est, alors faisons-en un peu plus comme Java. Super, maintenant nous avons tout ce qui était en Java, et ce n'est pas Java. C'est parti!