En 2017-2019, il y a eu une augmentation significative de TypeScript. Cela s'est produit pour des raisons évidentes. Il y a beaucoup de bien dans cette langue. Près de la moitié
des répondants au sondage sur l'
état de JavaScript en 2018 ont déjà essayé TypeScript et envisagent d'y écrire à l'avenir. TypeScript est assez populaire, mais vaut-il la peine d'être utilisé dans des projets logiciels à grande échelle?
Dans ce matériel, une tentative est faite de manière assez stricte, basée sur les indicateurs numériques et l'expérience pratique de l'auteur, pour analyser l'effet de l'utilisation de TypeScript dans le développement de grands projets.
Ă€ propos de la croissance de TypeScript
TypeScript est l'un des langages dont la croissance est la plus rapide. Actuellement, c'est la langue principale de celles compilées en JavaScript. Voici les données TypeScript de Google Trends.
Données Google Trends 2014-2019 sur la dynamique de popularité de TypeScriptVoici les
informations de GitHub, reflétant l'intérêt des programmeurs pour le travail sur le développement de divers langages de programmation.
Données GitHub sur la croissance des langages de programmation en termes de nombre de contributeursCe qui précède sont des indicateurs très impressionnants qui indiquent la popularité croissante de TypeScript, qui ne doit pas être sous-estimée. Mais il faut noter que TS est encore loin d'être reconnu comme le premier langage de l'écosystème JavaScript. Si l'écosystème JavaScript est comparé à l'océan, alors TypeScript sera une grosse vague dans cet océan. Voici une comparaison de JavaScript (ligne rouge) et TypeScript (ligne bleue) selon Google Trends.
Données de Google Trends pour 2014-2018 sur la dynamique de la popularité de JavaScript et TypeScriptEt voici des
informations de GitHub sur les principaux langages de programmation utilisés pour créer des référentiels en 2008-2018.
Données GitHub sur le nombre de référentiels créés à l'aide de divers langages de programmationVous pouvez voir que, par le nombre de référentiels, TypeScript ne fait pas partie des cinq premiers langages.
Il convient de noter qu'en 2018, il y a eu un tournant dans l'histoire de TypeScript, et en 2019, ce langage sera utilisé dans de nombreux projets réels. Si vous êtes un développeur JavaScript, dans de telles conditions, vous n'aurez tout simplement pas le choix. La décision d'utiliser TypeScript dans un projet sur lequel vous devez travailler sera déjà prise sans tenir compte de votre avis. Vous n'avez pas besoin d'avoir peur d'apprendre et d'utiliser TypeScript.
Cependant, si vous êtes celui qui décide du langage à utiliser dans un projet, vous devez avoir une compréhension réaliste des forces et des faiblesses de TypeScript. Lors de la prise de décisions, vous devrez comprendre si le choix de TypeScript aura un effet bon ou mauvais sur le projet.
Mon expérience suggère que TypeScript a ses avantages et ses inconvénients, mais on ne peut pas dire que son utilisation, en général, a un impact positif sur les projets. TypeScript a séduit de nombreux développeurs, et beaucoup de choses sont liées à ce langage que moi, qui l'ai testé dans la pratique, l'aime vraiment. Mais il faut tout payer.
Contexte
Je suis arrivé à JavaScript dans le monde des langages à typage statique - tels que C / C ++ et Java. Au début, il m'était difficile de m'adapter au typage dynamique adopté en JavaScript, mais dès que je m'y suis habitué, je me suis senti comme une personne qui a atteint la sortie d'un long tunnel sombre et a vu la lumière. La frappe statique a de nombreuses caractéristiques positives, mais on peut en dire autant de la frappe dynamique.
Au cours des dernières années, j'ai régulièrement plongé tête baissée dans le développement de TypeScript. En conséquence, j'ai acquis plus d'un an de pratique TypeScript. J'ai dirigé plusieurs grandes équipes utilisant TypeScript comme langage principal. Cela m'a permis d'évaluer l'impact de TypeScript sur le développement de grands projets et de comparer des projets similaires avec des projets similaires utilisant du JavaScript standard.
En 2018, les applications décentralisées pourraient
décoller . La plupart de ces applications utilisaient des contrats intelligents et des solutions open source. Lors du développement d'applications pour l'Internet de la valeur, les erreurs dans les programmes peuvent coûter de l'argent aux utilisateurs. Plus que jamais, il est important d'écrire du code fiable. Étant donné que ces projets sont généralement open source, je pensais que ce que nous utilisons dans le développement de TypeScript est bon, car cela facilitera la tâche des autres équipes TypeScript avec nos solutions, et en même temps, cela garantit la compatibilité. notre code avec des projets qui utilisent JavaScript.
Lors de l'utilisation pratique de TypeScript, j'ai commencé à mieux comprendre les avantages et les inconvénients de ce langage. Il m'est également apparu clairement quel type de choix TypeScript pouvait avoir sur un projet logiciel. Je regrette de dire que l'expérience avec TypeScript n'a pas été aussi réussie que je le souhaitais. Si TypeScript n'est pas significativement amélioré, je ne choisirai pas ce langage pour un autre projet à grande échelle.
Forces de TypeScript
TypeScript, à long terme, me semble toujours une évolution positive. Je veux aimer cette langue et j'aime toujours définitivement certaines de ses fonctionnalités. J'espère que les développeurs TypeScript et leurs partisans verront des critiques constructives dans ce matériel, et non des attaques sans fondement contre ce langage. Les développeurs TypeScript peuvent corriger certaines de ses lacunes, et s'ils le font, je peux répéter mon analyse de l'efficacité de ce langage et arriver à des résultats différents.
Le typage statique peut être très utile dans la mesure où il aide à documenter les fonctions, rend le code plus facile à comprendre et réduit la surcharge cognitive du programmeur. Par exemple, je trouve généralement que le système de type Haskell fonctionne, ne nécessitant pas trop de temps et d'efforts, pratique, discret. Mais parfois, même le système flexible de type Haskell et ses types de type supérieur rendent le travail difficile. Par exemple, essayez de taper un transducteur à l'aide de Haskell ou de TypeScript. Ce n'est pas facile à faire, et le résultat sera peut-être légèrement pire que son équivalent non typé.
J'aime le fait que les annotations TypeScript, si elles interfèrent, peuvent être facultatives. J'aime le fait que TypeScript utilise le typage structurel et qu'il existe un certain support pour l'inférence de type (bien qu'il existe de nombreuses possibilités d'amélioration dans ce domaine).
TypeScript prend en charge les interfaces réutilisables (par opposition aux déclarations de type intégrées). Les interfaces peuvent être utilisées de différentes manières pour annoter des API et des signatures de fonction. Une seule interface peut avoir plusieurs implémentations. Les interfaces sont l'une des meilleures fonctionnalités de TypeScript et j'aimerais que quelque chose de similaire apparaisse en JavaScript standard.
L'une des forces de TypeScript est sa boîte à outils. Par exemple, l'utilisation d'un éditeur approprié (comme Atom ou Visual Studio Code), pour lequel des plugins TS de haute qualité sont créés, met à la disposition du développeur les meilleurs outils de l'écosystème JavaScript. Les développeurs d'autres plug-ins devraient étudier les plug-ins TS et réfléchir à la manière dont, en utilisant les idées qu'ils contiennent, ils peuvent améliorer leur développement.
Analyse des performances de TypeScript
Maintenant, je vais évaluer TypeScript pour plusieurs indicateurs, en plaçant les notes entre -10 et 10. Cela vous aidera à mieux comprendre à quel point (ou mauvais) l'impact TypeScript peut avoir sur les grands projets.
Si le score de l'indicateur dépasse 0, cela indique l'impact positif de TypeScript sur le projet. Si le score est inférieur à 0, cela indique un impact négatif. Une valeur de notation de 3 à 5 points indique un effet assez fort. 2 points indiquent une exposition moyenne. 1 point est un effet relativement faible.
Les chiffres avec lesquels je continuerai à travailler sont difficiles à mesurer avec précision. Dans mes évaluations, je serai, dans une certaine mesure, subjective. Mais j'ai essayé de faire ces estimations afin qu'elles révèlent de manière aussi réaliste que possible les avantages et les inconvénients de l'utilisation de TypeScript dans des projets réels.
Tous les projets que j'ai analysés, donnant des notes, contenaient plus de 50 000 lignes de code. Ils sont le résultat du travail de plusieurs programmeurs pendant plusieurs mois. L'un de ces projets est basé sur Angular 2, il utilisait TypeScript. Il a été comparé à un projet similaire écrit en utilisant Angular 1 et JavaScript standard. Tous les autres projets sont basés sur React et Node à l'aide de TypeScript. Ils ont été comparés à des projets similaires utilisant du JavaScript simple. Certains indicateurs, tels que la densité des bogues, n'ont été estimés qu'environ. Toutes les équipes travaillant sur des projets étaient composées de développeurs TypeScript expérimentés et novices. Tous les membres de ces équipes ont eu l'opportunité d'interagir avec des mentors plus expérimentés qui les ont aidés à s'adapter dans le domaine du développement TypeScript.
En raison de la petite taille de l'échantillon, les données objectives que j'ai sont trop hétérogènes, il y a trop de bruit en elles, donc, sur la base de celles-ci, il est impossible de faire certains jugements objectifs qui pourraient être faits sur la base de chiffres suffisamment précis et sans risquer trop faites une grosse erreur. Un projet JavaScript a montré une densité d'erreurs de production qui était de 41% inférieure à un projet TypeScript comparable. Dans une autre comparaison, un projet TypeScript a montré une densité d'erreur inférieure de 4% à un projet JavaScript comparable. Dans ce cas, il est évident que le nombre d'erreurs qui ont atteint la phase de lancement du produit est beaucoup plus affecté non pas par l'utilisation de TypeScript dans le projet, mais par la présence ou l'absence d'autres mesures pour garantir la qualité du code. Cela fausse les indicateurs à tel point qu'il devient impossible de les utiliser.
Un si large éventail d'indicateurs objectifs a conduit au fait que j'ai décidé de ne pas les utiliser, en me concentrant sur le rythme de mise en œuvre des opportunités de projet et sur des observations qui indiquent les domaines du cycle de vie du projet dans lesquels la plupart du temps a été consacré. Ci-dessous, en analysant les indicateurs, nous en parlerons plus en détail.
Étant donné que mon analyse a une forte composante subjective, vous devez considérer la possibilité d'inexactitudes dans l'interprétation des indicateurs (cela se reflète dans le diagramme). Mais les conclusions générales de cette analyse peuvent fournir une image réaliste de ce que vous pouvez attendre de l'utilisation d'un projet TypeScript.
Analyse des performances de TypeScriptJe peux déjà entendre les objections concernant les faibles notes des avantages TypeScript, et franchement, je ne peux pas rejeter complètement ces objections. TypeScript, en fait, offre au programmeur des fonctionnalités très utiles et puissantes. Cela ne fait aucun doute.
Afin de comprendre la raison des notes positives relativement faibles et rares dans mon analyse, vous devez bien comprendre avec quoi je compare TypeScript. Il ne s'agit pas «uniquement de JavaScript», mais de JavaScript et d'outils conçus pour un développement efficace dans ce langage.
Tenez compte des indicateurs indiqués dans le diagramme.
▍ Outils de développement
Toolkit est ma fonctionnalité TypeScript préférée, qui est probablement l'avantage pratique le plus fort de l'utilisation de ce langage. Grâce à des outils de haute qualité, la charge cognitive sur le développeur est réduite. À sa disposition sont des conseils sur les types d'interfaces, dans le processus, en temps réel, les erreurs potentielles sont détectées. Si rien de tel ne se produisait lors du développement en JavaScript simple à l'aide de bons plugins, je donnerais à TypeScript une note positive plus élevée. Mais dans notre cas, 0 point est quelque chose que vous pouvez déjà utiliser lors de la programmation en JavaScript, c'est-à -dire avec lequel nous comparons TypeScript, il est déjà à un niveau assez élevé.
La plupart des défenseurs de TypeScript ne semblent pas très bien comprendre avec quoi TypeScript est en concurrence. Le fait est que le choix des outils n'est pas une décision sur l'utilisation de TypeScript ou JavaScript sans outils auxiliaires. Il s'agit de choisir entre TypeScript et l'ensemble de l'écosystème riche d'outils de développement JavaScript. Les outils de complétion de code et de détection d'erreurs pour JavaScript commun fournissent 80 à 90% de ce qui est généralement considéré comme des points forts de TypeScript. Cela se produit, par exemple, lors de l'utilisation d'outils de
complétion de code, d'outils de
sortie de types et de
linters . Lors de l'utilisation du système d'inférence de type et lors de l'application des paramètres de fonction par défaut apparus dans ES6, le développeur a à sa disposition des conseils très similaires à ceux disponibles lors de l'utilisation de code TypeScript avec des annotations de type.
Un exemple d'auto-complétion de code JS standard avec inférence de typeHonnêtement, si vous utilisez les paramètres par défaut pour fournir des indications de type, vous n'avez absolument pas besoin d'annoter le code TypeScript. Il s'agit d'une excellente technique pour réduire le nombre de constructions de syntaxe auxiliaires, qui sont l'un des inconvénients de TypeScript.
Les outils utilisés pour écrire du code TypeScript sont peut-être un peu meilleurs, ils ont l'air plus holistiques, mais tout cela ne suffit pas pour donner à TypeScript une note beaucoup plus élevée et pour couvrir les lacunes de ce langage.
â–Ť Documentation API
Un autre avantage majeur de TypeScript est sa meilleure documentation API. En fait, on peut dire que la documentation de l'API correspond toujours à l'état du code source. La documentation peut même être générée sur la base du code TypeScript. Pour cet indicateur TypeScript, on pourrait également donner une note plus élevée - si, lors de la programmation en JavaScript, on ne pouvait pas utiliser quelque chose comme
JSDoc ,
Tern.js et beaucoup d'outils pour générer de la documentation. Personnellement, je ne suis pas fan de JSDoc, donc TypeScript dans mon analyse sur cet indicateur est très apprécié.
Il convient de noter que, même en utilisant la meilleure documentation intégrée au code du monde, on ne peut pas se passer de documentation réelle, il est donc juste de dire que les capacités TypeScript sont plus susceptibles d'étendre les capacités de compilation de documentation existantes plutôt que de les remplacer.
▍ Type de sécurité
En comparant la sécurité de type TS et JS, il s'est avéré qu'il n'est pas possible de révéler une différence particulière. Les partisans de TypeScript parlent souvent des avantages de la sécurité des types, mais on ne peut pas dire que la
sécurité des types réduit considérablement la densité d'erreur en production. C'est un point important, car l'utilisation de la révision de code et du TDD a un impact sérieux sur le dépannage (le simple fait d'utiliser la technique
TDD réduit les erreurs de 40 à 80%). Si vous combinez TDD avec une analyse de l'architecture des projets, avec une vérification des spécifications et des revues de code, vous pouvez obtenir une réduction de plus de 90% de la densité des erreurs. Beaucoup de ces techniques (TDD en particulier) peuvent vous aider à trouver les mêmes erreurs qui peuvent être détectées avec TypeScript, ainsi que de nombreuses erreurs que TypeScript ne peut pas détecter.
Nous donnons ici quelques calculs Ă partir de
cette étude . Le maximum théorique d'erreurs "publiquement disponibles" pouvant être détectées par TypeScript est d'environ 15%. Les erreurs «publiques» sont des erreurs qui survivent à la phase de développement du projet et se retrouvent dans un référentiel public.
L'étude susmentionnée a permis de surveiller les erreurs connues à l'avance. Cela comprenait la connaissance des lignes de code qui ont été modifiées pour corriger les erreurs, tandis que le problème et sa solution potentielle étaient connus avant la saisie du code. Cela signifie que même la connaissance de l'existence d'erreurs n'a pas permis, à l'aide de TypeScript, de détecter 85% des erreurs "publiques".
Pourquoi TypeScript est-il incapable de détecter autant d'erreurs? Pourquoi dis-je que 15% des erreurs détectées sont le maximum théorique de TypeScript? Pour commencer, il convient de noter que, conformément à l'étude en question, les erreurs de spécifications entraînent environ 78% des erreurs dans les référentiels publics GitHub. L'incapacité à formuler clairement les spécifications des programmes ou l'incapacité de mettre correctement en œuvre les spécifications conduit au type d'erreur le plus courant. Cela conduit automatiquement au fait que la plupart des erreurs dans les projets logiciels TypeScript ne peuvent pas être détectées ou empêchées. Les auteurs de l'étude, entre autres, identifient et classent les erreurs qui ne sont pas détectées par TypeScript. Voici un graphique à barres avec des informations sur ces erreurs.
Erreurs non détectées par TypeScriptL'exemple «StringError» est une erreur qui se produit si une chaîne est utilisée là où une chaîne est nécessaire, c'est-à -dire que les erreurs de types ne se produisent pas, mais le contenu de cette chaîne lui-même provoque une erreur (par exemple, il peut y avoir une URL incorrecte). À l'aide d'une analyse statique, vous pouvez identifier certaines de ces erreurs en examinant le contenu des chaînes et en utilisant des descriptions de ce contenu. . , TypeScript - 15-18% .
, 15% — . TypeScript ?
, , TDD. , TypeScript , . TypeScript, , TypeScript, , , .
, 1000 , . , , , , 100. , TypeScript, , . 80% TypeScript , , , , , TypeScript, , TDD, , , , TypeScript 8% . , , , , TypeScript, . :
- , , 1000 .
- , TypeScript, 900 .
- TypeScript 92 . , TypeScript 8 .
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
â–Ť JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
â–Ť (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
â–Ť , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
â–Ť (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
â–Ť (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
â–Ť , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
TypeScript, , , , — , , TypeScript. TypeScript . , — , , TypeScript.
.
TypeScript , «JavaScript, ». : «JavaScript, ».
! TypeScript.
