Initialement créé chez Microsoft puis publié en tant que projet open source sous la licence Apache 2.0, TypeScript est souvent décrit comme un « sur-ensemble de JavaScript » ou « JavaScript avec des types ». Depuis son annonce en 2012, il est devenu l’acteur dominant parmi les “saveurs” JavaScript selon le rapport State of JS 2020 (il a été utilisé par 78% des répondants). C’était également le troisième langage le plus apprécié dans la récente enquête auprès des développeurs de Stack Overflow, derrière Rust et Clojure.
TypeScript comprend quatre composants : le langage de programmation lui-même ; un vérificateur de type fournissant un typage statique facultatif pour JavaScript ; un compilateur qui transforme le code TypeScript en code JavaScript ; et un programme de services linguistiques qui utilise le vérificateur de type pour indiquer aux éditeurs, tels que VS Code, comment fournir des utilitaires utiles aux développeurs.
Bon nombre des premiers utilisateurs de TypeScript étaient les développeurs du framework JavaScript, en particulier les équipes derrière Angular et Dojo. “Fondamentalement, là où TypeScript m’a d’abord intéressé, c’est qu’il a introduit des interfaces dans le langage”, a déclaré Dylan Schiemann, PDG de Living Spec et créateur du framework Dojo, à The New Stack.
“Sans définition d’interface, vous ne pouvez pas échanger une dépendance en toute sécurité car vous ne savez pas ce que la dépendance est censée faire”, a déclaré Schiemann. “Donc, si vous étiez un auteur de framework ou que vous construisiez une grande application, vous n’aviez aucun contrôle sur le comportement de quelque chose comme avant. Nous avions été mordus par cela, alors Dojo a été l’un des premiers à adopter TypeScript pour cette raison.
Dactylographie statique
La prise en charge de TypeScript pour le typage statique ne doit pas non plus être sous-estimée. JavaScript est toujours typé dynamiquement, ce qui peut entraîner une variété de bogues difficiles à détecter dans les bases de code plus importantes. Le framework Vue, par exemple, est 100% construit avec TypeScript à partir de la version 3avec la documentation officielle indiquant qu'”un système de type statique peut aider à prévenir de nombreuses erreurs d’exécution potentielles à mesure que les applications se développent, c’est pourquoi Vue 3 est écrit en TypeScript”.
“Lorsque le monde est passé à ES6, ils sont également passés à TypeScript.”
-Dylan Schiemann, PDG de Living Spec et créateur du framework Dojo
En 2015, Google a décidé qu’Angular 2 serait également construit à l’aide de TypeScript, citant le typage statique comme l’une des raisons. Ryan Cavanaugh, le principal ingénieur responsable du langage TypeScript chez Microsoft, estime que cela a été un stimulant majeur pour une adoption plus large de TypeScript. Lors d’une discussion avec Ryan Donovan de Stack Overflow, il a déclaré :
“… si vous regardez les graphiques pour TypeScript, littéralement n’importe quel graphique – étoiles GitHub, téléchargements, demandes d’extraction – vous pouvez voir le moment exact où cette annonce Angular est sortie. Et le graphique change juste. Il ne regarde jamais en arrière. Vous ne pouvez plus voir ce petit virage dans la courbe parce que la courbe a continué. Ce fut un véritable point d’inflexion.
Et je pense qu’il est intéressant que les gens pensaient à l’époque que TypeScript allait être exactement ce que les gens d’Angular utilisent et pas grand-chose d’autre. Cela ne s’est pas avéré être le cas. Évidemment, nous sommes toujours populaires parmi les développeurs Angular. Mais cela a été un véritable générateur d’élan pour nous.
À l’inverse, Schiemann estime que c’est l’arrivée d’ECMAScript 6 qui a déclenché le point de basculement : « Je pense que lorsque le monde est passé à ES6, ils sont également passés à TypeScript, parce qu’ils se sont dit : “Eh bien, si je vais suivre cette voie , laissez-moi regarder TypeScript pendant que je fais ça.”’”
L’importance de la communauté
De l’avis de Schiemann, la gestion de la communauté par Microsoft est encore plus importante.
“Si les gens de TypeScript n’étaient pas du tout dignes de confiance en tant qu’équipe, je pense que les gens n’auraient pas adopté TypeScript”, a-t-il déclaré. “Le truc, c’est qu’avec Anders [Hejlsberg] vous avez cette personne qui est super intelligente, mais super accessible. Et toute l’équipe est comme ça – ils sont comme l’équipe la plus humble et la plus modeste avec laquelle j’ai jamais travaillé, avec ce niveau d’aptitude technique.
Schiemann a expliqué que lorsque l’équipe derrière Angular a commencé à utiliser TypeScript, elle l’a forgé pour ajouter une fonctionnalité dont elle avait besoin appelée Decorators. Voyant cela, l’équipe TypeScript a tendu la main et a suggéré de travailler ensemble pour ajouter la fonctionnalité dans TypeScript lui-même.
“Et puis, lorsque React est devenu plus largement adopté, l’équipe TypeScript a dit:” Eh bien, que diriez-vous de travailler avec l’écosystème React pour aider à améliorer TypeScript pour qu’il fonctionne avec React “, puis ils ont fait la même chose lorsque Svelte a commencé à gagner en popularité . Ils font donc du bon travail en contactant les frameworks et en disant : “Hé, comment pouvons-nous vous aider ?” »
Cette ouverture a porté ses fruits, l’équipe Svelte (comme Vue) adoptant TypeScript pour sa version 3. chez Facebook, qui possède son propre vérificateur de type Flow JavaScript, TypeScript est même utilisé, y compris pour des projets tels que le framework de test JavaScript Jest.
Outils de développement
L’accent mis par Microsoft sur la communauté s’étend également aux outils de développement ; une autre raison citée par l’équipe Angular pour sa décision d’adopter le langage. Le propre code VS de Microsoft prend naturellement en charge TypeScript, mais le serveur de langage TypeScript fournit un ensemble commun d’opérations d’éditeur, telles que la complétion d’instructions, l’aide à la signature, le formatage du code et la mise en page. Cela simplifie le travail des fournisseurs d’IDE alternatifs, tels que JetBrains avec WebStorm (et certains de leurs autres IDE).
Ekaterina Prigarachef de projet WebStorm chez JetBrains, a déclaré à New Stack que “cette intégration fonctionne parallèlement à notre propre prise en charge de TypeScript – certaines des fonctionnalités de la prise en charge du langage sont alimentées par le serveur, tandis que d’autres, par exemple la plupart des refactorisations et le mécanisme d’importation automatique, par le propre support de l’IDE.
La disponibilité de TypeScript Language Server réduit la charge de développement pour les fabricants d’outils.
Les détails de l’intégration sont assez complexes. Prigara a poursuivi: «Les suggestions d’achèvement du serveur sont affichées mais elles pourraient, dans certains cas, être améliorées avec les suggestions de l’IDE. Il en va de même pour la détection d’erreurs et les correctifs rapides. Le formatage est effectué par l’IDE. Les types inférés affichés au survol, si je ne me trompe pas, proviennent du serveur. Mais il y a toujours une solution de secours fournie par l’IDE au cas où le serveur mettrait trop de temps à répondre.
Cependant, la disponibilité de TypeScript Language Server réduit toujours la charge de développement pour les fabricants d’outils. Pour cette raison, il est utilisé par un grand nombre d’outils et de frameworks de vérification – par exemple ESLint pour le type et Vue pour son support Typescript. En effet, l’angle d’outillage est si important que, selon Schiemann, “l’équipe TypeScript ne fournira pas une fonctionnalité qui ne peut pas être réalisée assez rapidement pour un IDE”.
De plus, comme TypeScript est un compilateur, il peut compiler une base de code pour prendre en charge les navigateurs et environnements plus anciens. Ajoutez à cela un linter et la prise en charge intégrée de la documentation, et il est facile de comprendre pourquoi TypeScript est si convaincant. “À ce stade, je ne peux pas imaginer vraiment écrire quoi que ce soit d’important sans cela”, a déclaré Schiemann, “parce que cela m’aide simplement à écrire un code plus clair et plus facile à maintenir.”
Pas le Microsoft de ton père
Compte tenu de l’histoire de Microsoft avec l’open source, il est intéressant de réfléchir à la façon dont nous en sommes arrivés là.
Lorsque TypeScript a été lancé pour la première fois, le comité TC-39 – qui est chargé de maintenir et de développer la définition de JavaScript – n’avait pas réussi à parvenir à un consensus sur ECMAScript 4. Cela était en partie dû à Microsoft : Allen Wirfs-Brock, le représentant de Microsoft au TC -39, considérait le langage comme trop complexe pour son propre bien, s’inquiétant de “la capacité du Web à ‘digérer’ des changements aussi importants”. Les outils JavaScript tels que Dojo, JQuery et MooTools ont dominé le paysage du développement Web en 2012, mais l’écriture d’applications à grande échelle en JavaScript est restée difficile.
La raison en est, selon Anders Hejlsberg, que « JavaScript n’a jamais vraiment été conçu pour être un langage de programmation pour de grosses applications. C’est un langage de script. Il n’a pas de typage statique, mais plus important encore, il manque peut-être certains des mécanismes de structuration dont vous avez besoin dans les grandes applications, comme les classes, les modules et, peut-être, les interfaces.
Comme le note Hejlsberg, une option populaire à l’époque consistait à tirer parti des écosystèmes matures existants, puis à transpiler l’application en JavaScript. L’exemple le plus connu est peut-être Google Web Toolkit (GWT), qui a exploité l’écosystème Java, permettant aux développeurs d’écrire du code en Java et de travailler avec des IDE tels qu’Eclipse et IntelliJ. ScriptSharp a adopté une approche similaire pour les développeurs souhaitant utiliser C# et l’écosystème .NET.
Le défi était que si vous vouliez tirer parti de quelque chose de l’écosystème JavaScript, vous deviez d’abord l’encapsuler ; et, comme le dit Hejlsberg, “vous êtes en quelque sorte à bout de bras à tout moment de la chose que vous visez.”
Étant donné que TypeScript est basé sur JavaScript, tout programme JavaScript est également un programme TypeScript valide.
Une solution aurait été d’ajouter des choses comme des classes et des modules au langage, mais ce n’est pas la victoire directe qu’elle pourrait, à première vue, sembler être. Comme l’architecture logicielle, la conception du langage implique un ensemble complexe de compromis. Le succès initial de JavaScript était au moins en partie dû au fait qu’il était relativement facile pour les concepteurs Web de saisir et de créer des scripts fonctionnels, même s’il s’agissait d’un langage difficile à maîtriser. En ajoutant des fonctionnalités pour prendre en charge des bases de code plus volumineuses, vous augmentez également la courbe d’apprentissage et rendez plus difficile son utilisation pour les tâches de script simples pour lesquelles il était initialement prévu.
Plutôt que de changer JavaScript lui-même, la solution de Microsoft consistait à créer un nouveau langage par-dessus, en ajoutant les éléments qu’ils considéraient comme manquants pour les développeurs travaillant sur des applications plus complexes – telles que le typage statique, les classes et les modules – et en laissant JavaScript comme un simple script. langue pour ceux qui en avaient besoin.
Cela signifiait que TypeScript pouvait toujours bénéficier de l’écosystème JavaScript plus large. Étant donné que TypeScript est basé sur JavaScript, tout programme JavaScript est également un programme TypeScript valide.
Et, bien sûr, être open source a permis à une communauté de se développer autour du langage.
Pourtant, il était facile à l’époque d’être sceptique. Microsoft s’était acquis une mauvaise réputation dans la communauté open source. En 2001, Steve Ballmer, alors PDG de Microsoft, a déclaré que “Linux est un cancer”. La société a parrainé l’attaque du droit d’auteur de SCO sur Linux, a affirmé que Linux violait des brevets Microsoft sans nom et a forcé les fournisseurs Android basés sur Linux à payer pour des revendications de brevet douteuses.
L’équipe TypeScript a rejoint le TC-39, faisant partie de la communauté plus large qui tente d’améliorer JavaScript.
Les observateurs à long terme de l’industrie se souviendront également de l’utilisation par Microsoft de “embrasser, étendre et éteindre”, en particulier dans la seconde moitié des années 1990, conduisant à des incompatibilités délibérées de navigateur, empêchant le rendu correct des documents Office dans des navigateurs autres qu’IE, et brisant La portabilité de Java.
En revanche, l’équipe TypeScript a maintenant rejoint le TC-39, faisant partie de la communauté plus large essayant d’améliorer JavaScript, plutôt que de chercher à le remplacer. De plus, TypeScript a toujours fonctionné comme un projet open source approprié. Lors du traitement des problèmes, Prigara de JetBrains m’a dit : « Nous nous appuyons principalement sur les informations accessibles au public (feuille de route, problèmes, commits) sur GitHub. Nous avons un contact pour leur PM, mais en général nous préférerions déposer un problème sur GitHub.
Schiemann a accepté. “Une chose que l’équipe TypeScript m’a dit”, a-t-il dit, “c’était [that] lorsqu’ils adoptaient pleinement l’open source, ils recevaient toujours des demandes d’entreprise telles que “pouvez-vous ajouter cette fonctionnalité à TypeScript pour l’entreprise X”, et ils répondaient “eh bien, non, vous devez ouvrir un problème dans GitHub, faites votre cas et peut-être fournir un PR. Si vous voulez cette open source, vous devez l’exécuter comme un projet open source ».
En fin de compte, TypeScript a gagné grâce à Microsoft étant de bons intendants et citoyens open source.
Image caractéristique adaptée d’une photo de Christina Morillo de Pexels.