Il y a quelque temps, j'ai fait une demi-observation, demi-blague sur LinkedIn. La grande réécriture de la chaîne d'outils JavaScript a débarqué. Les anciens outils sont devenus ringards, leur performance poussive blâmée pour ralentir le code. Il est difficile de suivre les branchés, mais leur promesse est la vitesse. C'est une période étrange : JavaScript est omniprésent mais perd du terrain dans son propre jardin. Les outils sont plus rapides, la configuration plus facile, les abstractions plus épaisses. Nous écrivons, configurons et attendons moins. Nous regroupons, livrons et corrigeons à chaud plus. Ce qui se passe entre le code et le produit devient plus facile à ignorer. Les benchmarks brillent en vert. Alors pourquoi gâcher la fête ?

Pour un langage écrit en dix jours, JavaScript a accompli l'impensable. Il s'est échappé du navigateur et a tout avalé. Beaucoup écriraient des serveurs et des outils en JavaScript. Il est arrivé sur les téléphones, les consoles, les microcontrôleurs, votre frigo. S'il comprend les bits, il peut exécuter JavaScript. Malgré sa popularité, il n'a jamais eu la vie facile. Les tentatives pour le remplacer ont commencé tôt : VBScript et JScript de Microsoft, ActionScript de Macromedia/Adobe, Dart de Google, CoffeeScript. Quand nous ne remplacions pas, nous patchions : jQuery, Lodash, Moment.js. JavaScript ne restait pas immobile. Les versions d'ECMAScript ont apporté des fonctionnalités. TC39 a continué à proposer des propositions. Puis TypeScript a réussi en acceptant que JavaScript n'allait nulle part.

Un langage pour les gouverner tous est une bénédiction et une malédiction. Nous avons passé des décennies sur la malédiction, oublié la bénédiction. À mesure que JavaScript se répandait, il mangeait sa propre nourriture pour chien. Node.js a permis des outils dans le même langage. Si quelque chose cassait, les développeurs pouvaient vérifier le code, comprendre les bugs, peut-être corriger, soumettre une pull request. Au moins ils pouvaient blâmer le...