TypeScript a été rendu public le 1er octobre 2012 (à la version 0.8), après deux ans de développement interne chez Microsoft.
10 ans plus tard, Daniel Rosenwasser, Senior Program Manager, TypeScript, a décidé de faire le point sur les doutes des premiers jours, le parcours du langage tout en indiquant les espoirs de Microsoft à l'endroit de TypeScript.
Les premiers jours
Lorsque TypeScript a fait ses débuts, il y avait beaucoup de scepticisme - et c'est compréhensible. Pour certains utilisateurs de JavaScript, une équipe essayant d'apporter des types statiques à JavaScript aurait pu ressembler à un complot diabolique ou à une blague.
Mais les fonctionnalités avaient du mérite, non? Vérifier le type, détecter les bogues avant même d'enregistrer votre fichier et obtenir des fonctionnalités d'éditeur riches comme la complétion de code, la navigation et les refactorisations*? Nous savions que les équipes à l'intérieur et à l'extérieur de notre entreprise rencontraient d'énormes défis avec des bases de code JavaScript complexes, et nous savions que JavaScript allait être utilisé partout. Alors, qui ne voudrait pas d'outils puissants pour l'aider à l'écrire ? Pour l'équipe, il y avait une vision de ce que TypeScript pourrait être, et en fait, si vous repensez à notre premier article d'annonce, la proposition de valeur était en grande partie la même qu'aujourd'hui !
Heureusement, cette vision a trouvé un écho chez d'autres. Dès le début, nous avons construit une communauté petite, mais travailleuse et enthousiaste, désireuse d'expérimenter et de vivre l'expérience alors que nous étions encore en train d'itérer, d'apprendre et de construire quelque chose qui n'avait même pas encore atteint la version 1.0. Nous avons vu de nouveaux efforts passionnants comme le projet DefinitelyTyped, de nouveaux membres de la communauté aidant sur StackOverflow et notre outil de suivi des problèmes, des auteurs écrivant des livres et des didacticiels pour le langage, et de nouvelles bibliothèques pariant sur TypeScript. Ces développeurs patients, travailleurs et énergiques ont jeté les bases de la croissance de la communauté TypeScript.
Pourtant, la plupart des développeurs JavaScript n'étaient pas sûrs de TypeScript. Alors, comment cette équipe allait-elle convaincre les développeurs JavaScript de la valeur des types statiques dans un langage typé dynamiquement*? "Types versus pas de types" a été un sujet… controversé, et cela remonte à au moins un demi-siècle dans le monde de la programmation.
Mais nous voulions vraiment créer des outils JavaScript étonnants grâce à la puissance des types.
Est-ce que cela pourrait être fait ?
Résister à l'épreuve du temps
La vérité est que cela a nécessité une approche de développement complètement différente de celle à laquelle nous étions habitués, suivie de persévérance, de sensibilisation et d'empathie. TypeScript devait être libre et open source, et fait d'une manière vraiment ouverte. Il devait également interagir de manière transparente avec JavaScript existant, co-évoluer avec JavaScript et ressembler à JavaScript. TypeScript n'a jamais cherché à créer un langage séparé, distinct et normatif. Au lieu de cela, TypeScript devait être descriptif - innover dans le système de type autour des conventions et des modèles trouvés "dans la nature" de l'écosystème JavaScript. Cela nous a permis de rencontrer les gens là où ils se trouvaient, et cette philosophie correspondait vraiment bien aux objectifs de conception du projet.
Il est en fait surprenant de constater à quel point les objectifs de conception de TypeScript ont résisté.
Par exemple, certains objectifs de conception comme
- « n'imposer aucune surcharge d'exécution sur les programmes émis » ;
- « s'aligner sur les propositions ECMAScript actuelles et futures » ;
- « préserver le comportement d'exécution de tout le code JavaScript » ;
- « éviter d'ajouter une syntaxe au niveau de l'expression » ;
- « utiliser un système de type structurel cohérent et entièrement effaçable »
indiquent vraiment à TypeScript d'être simplement un vérificateur de type pour JavaScript, en ajoutant uniquement la syntaxe nécessaire à la vérification de type.
Nous nous sommes donc concentrés principalement sur le système de type et avons évité d'ajouter de nouvelles syntaxes et comportements d'exécution. Cela peut sembler évident 10 ans plus tard, mais les langages de programmation essaient souvent de se différencier en fonction de l'apparence de leur code exécutable. De plus, de nombreux langages typés guident leur comportement d'exécution en fonction des types.
Mais ces approches n'ont aucun sens lorsqu'on essaie de s'appuyer sur JavaScript et de s'y intégrer. Le JavaScript non typé devait fonctionner de la même manière lorsqu'il était collé dans un fichier TypeScript, et la conversion de TypeScript en JavaScript devait être aussi simple que la suppression de types. Il nous a fallu quelques faux pas au début pour nous en rendre compte, mais c'était une opportunité d'apprentissage et l'équipe a évité la syntaxe d'exécution pendant une bonne partie de 10 ans. De nos jours, lorsqu'il manque à TypeScript une fonctionnalité d'exécution utile, nous ne nous contentons pas de l'ajouter à TypeScript. Nous travaillons au sein de TC39 (l'organisme de normalisation JavaScript) pour guider ou défendre les nouvelles fonctionnalités afin que tous les développeurs JavaScript puissent en bénéficier.
Un autre principe réussi est que TypeScript n'a pas essayé d'être tous les outils de la boîte à outils. L'un de nos non-objectifs n'est pas de « fournir un pipeline de construction de bout en bout. Au lieu de cela, rendre le système extensible afin que des outils externes puissent utiliser le compilateur pour des workflows de construction plus complexes ».
Il y a eu de nombreuses fois où TypeScript a reçu des demandes pour être un linter, un bundler, un optimiseur/minifier, un build orchestrator, un bundler (encore), et plus encore. Les lignes ne sont pas toujours clairement définies, en particulier lorsque TypeScript fait déjà beaucoup en tant que vérificateur de type, compilateur et service de langage. Dans l'écosystème JavaScript, où les meilleures pratiques ont continué d'évoluer au fil des ans, il était extrêmement important que TypeScript reste étendu et flexible pour répondre à différents besoins. Compte tenu de tous les différents bundlers, différents runtimes, différents orchestrateurs de build et différents linters au cours des dernières années, il a été crucial que TypeScript s'intègre bien à chacun d'eux sans essayer de les déplacer. Nous avons eu le privilège de collaborer avec les auteurs d'outils dans cet espace, car nous travaillons tous pour rendre TypeScript et JavaScript plus faciles à utiliser.
Retour à aujourd'hui
Aujourd'hui, TypeScript est un langage florissant utilisé par des millions de développeurs à travers le monde. Dans les enquêtes et les classements de langages comme l'enquête annuelle de StackOverflow, le rapport Octoverse de GitHub et le classement des langues de Redmonk, TypeScript s'est toujours classé dans le top 10 (sinon 5) des langages les plus utilisés et les plus appréciés.
Bien sûr, le contexte est important - l'utilisation de TypeScript est fondamentalement liée à celle de JavaScript, et chaque développeur TypeScript est également un développeur JavaScript. Heureusement, même lorsqu'on demande aux développeurs JavaScript s'ils utilisent TypeScript et s'ils l'aiment - comme dans l'enquête sur l'état de JS - la réponse est un "oui" retentissant !
Le succès d'aujourd'hui est bien au-delà de ce que l'équipe principale imaginait TypeScript il y a encore quelques années, et encore moins il y a dix ans. L'équipe principale a travaillé dur sur TypeScript, mais nous savons que l'élément fondamental qui a permis ce succès est la communauté. Cela inclut les contributeurs externes à TypeScript, les auteurs de bibliothèques et les développeurs de tous les jours qui ont parié sur TypeScript et ont prouvé que le langage tenait la route, les contributeurs DefinitelyTyped, les organisateurs de la communauté, les experts qui ont pris le temps de répondre aux questions et ont enseigné aux autres et tracé un chemin pour les nouveaux arrivants - chaque utilisateur de TypeScript, du fond du cœur, merci. Vous avez participé à la construction de quelque chose de formidable.
Certains exemples d'adoption de TypeScript
Après avoir réécrit Angular en TypeScript, Google a approuvé le surensemble JavaScript de Microsoft pour ses développements internes
Du 5 au 7 avril 2017, Google a tenu la ng-conf, sa conférence mondiale dédiée à Angular, à Salt Lake City aux États-Unis. À cette occasion, l’équipe Angular a annoncé que TypeScript est désormais approuvé par Google comme langage pour ses développements en interne. Le processus a duré deux ans : en 2015, Google et Microsoft ont annoncé que, pour sa version 2.0, le framework JavaScript Angular serait réécrit en TypeScript en non en AtScript comme c’était prévu.
Chrome et l'interprétation native de TypeScript
En 2015, l'équipe de V8, le moteur JavaScript de Chrome, a publié des précisions sur les évolutions du moteur. Elle envisageait l'ajout d'un système de typage à JavaScript afin de permettre au compilateur des optimisations qui n'étaient alors pas possibles en JavaScript. Il s'agissait précisément du projet SoundScript.
Malgré la popularité de TypeScript, lorsqu'il a été demandé à la communauté francophone des professionnels de l'IT quels sont leurs langages les plus détestés en 2022, plus de la moitié des répondants a indiqué JavaScript, contre 3% pour le surensemble JavaScript qu'est TypeScript. Ironique ou pas ? À vous de décider.
Source : Microsoft
Et vous ?
Que pensez-vous de JavaScript ? TypeScript ?
Avez-vous déjà utilisé l'un ou l'autre ? Pour des projets personnels ou en entreprise ?
Si vous n'avez utilisé ni l'un ni l'autre, prévoyez-vous de le faire ? Pourquoi ?
Que pensez-vous des autres surensembles JavaScript ?
Lequel a votre préférence ?
Quels sont les éléments de TypeScript qui vous intéressent le plus ou sont susceptibles de le faire ?
Quelles limites trouvées vous à l'adoption ou l'utilisation de TypeScript ?
Voir aussi :
Introduction au langage TypeScript
Pourquoi utiliser TypeScript ?
Le top 25 des langages de programmation les plus populaires auprès des DevOps : TypeScript a détrôné JavaScript en tant que langage préféré
Ruby est en 3è position, d'après CircleCI
TypeScript 4.9 Beta est disponible et apporte la restriction des propriétés non listées avec l'opérateur in, ainsi que la vérification de l'égalité sur NaN