Pourquoi je suis sceptique quant à la réécriture des outils JavaScript dans des langages "plus rapides"
Pourquoi je suis sceptique quant à la réécriture des outils JavaScript dans des langages "plus rapides", par Nolan Lawson
J'ai écrit beaucoup de JavaScript. J'aime JavaScript. Et plus important encore, j'ai acquis un ensemble de compétences en matière de compréhension, d'optimisation et de débogage de JavaScript que je suis réticent à abandonner.
Il est donc normal que j'éprouve une certaine inquiétude face à la manie actuelle de réécrire tous les outils Node.js dans un langage "plus rapide" comme Rust, Zig, Go, etc. Ne vous méprenez pas, ces langages sont cool ! (J'ai une copie du livre Rust sur mon bureau en ce moment même, et j'ai même contribué un peu à Servo pour le plaisir). Mais en fin de compte, j'ai investi une grande partie de ma carrière dans l'apprentissage des tenants et aboutissants de JavaScript, et c'est de loin le langage avec lequel je suis le plus à l'aise.
Je reconnais donc mon parti pris (et peut-être mon surinvestissement dans un ensemble de compétences). Mais plus j'y réfléchis, plus j'ai le sentiment que mon scepticisme est également justifié par des préoccupations objectives, que j'aimerais aborder dans ce billet.
La performance
L'une des raisons de mon scepticisme est que je ne pense pas que nous ayons épuisé toutes les possibilités de rendre les outils JavaScript plus rapides. Marvin Hagemeister a fait un excellent travail pour le démontrer, en montrant combien il y a de fruits à portée de main dans ESLint, Tailwind, etc.
Dans le monde des navigateurs, JavaScript a prouvé qu'il était "suffisamment rapide" pour la plupart des charges de travail. Bien sûr, WebAssembly existe, mais je pense qu'il est juste de dire qu'il est principalement utilisé pour des niches, des tâches intensives en CPU plutôt que pour la construction d'un site web entier. Alors pourquoi les outils CLI basés sur JavaScript s'empressent-ils de se débarrasser de JavaScript ?
La grande réécriture
Je pense que l'écart de performance est dû à plusieurs facteurs. Pendant longtemps, l'écosystème des outils JavaScript s'est concentré sur la construction de quelque chose qui fonctionne, et non sur quelque chose de rapide. Aujourd'hui, nous avons atteint un point de saturation où la surface de l'API est pratiquement réglée et où tout le monde veut "la même chose, mais plus vite". D'où l'explosion de nouveaux outils qui remplacent presque directement les outils existants : Rolldown pour Rollup, Oxlint pour ESLint, Biome pour Prettier, etc.
Cependant, ces outils ne sont pas nécessairement plus rapides parce qu'ils utilisent un langage plus rapide. Ils peuvent simplement être plus rapides parce que 1) ils sont écrits en tenant compte des performances, et 2) la surface de l'API est déjà établie, de sorte que les auteurs n'ont pas besoin de passer du temps de développement à peaufiner la conception générale. Vous n'avez même pas besoin d'écrire des tests ! Il suffit d'utiliser la suite de tests existante de l'outil précédent.
Au cours de ma carrière, j'ai souvent vu une réécriture de A vers B entraînant une augmentation de la vitesse, suivie de l'affirmation triomphante que B est plus rapide que A. Cependant, comme le souligne Ryan Carniato, une réécriture est souvent plus rapide simplement parce qu'il s'agit d'une réécriture - vous en savez plus la deuxième fois, vous accordez plus d'attention aux performances, etc.
Bytecode et JIT
La deuxième catégorie d'écarts de performance provient des choses que les navigateurs nous offrent gratuitement et auxquelles nous pensons rarement : le cache du bytecode et le compilateur JIT (Just-In-Time).
Lorsque vous chargez un site web pour la deuxième ou troisième fois, si le JavaScript est correctement mis en cache, le navigateur n'a plus besoin d'analyser et de compiler le code source en bytecode. Il charge simplement le bytecode directement à partir du disque. C'est le cache de bytecode en action.
En outre, si une fonction est "chaude" (fréquemment exécutée), elle sera encore optimisée en code machine. C'est le JIT en action.
Dans le monde des scripts Node.js, nous ne bénéficions pas du tout des avantages du cache bytecode. Chaque fois que vous exécutez un script Node, l'ensemble du script doit être analysé et compilé à partir de zéro. C'est l'une des principales raisons pour lesquelles les outils JavaScript et les outils non-JavaScript gagnent en performance.
Grâce à l'inimitable Joyee Cheung, Node dispose désormais d'un cache de compilation. Vous pouvez définir une variable d'environnement et obtenir immédiatement des chargements de scripts Node.js plus rapides :
Code:
export NODE_COMPILE_CACHE=~/.cache/nodejs-compile-cache
Je l'ai mis dans mon ~/.bashrc sur toutes mes machines de développement. J'espère que cela fera un jour partie des paramètres par défaut de Node.
Quant à JIT, c'est une autre chose dont (malheureusement) la plupart des scripts Node ne peuvent pas vraiment bénéficier. Vous devez exécuter une fonction avant qu'elle ne devienne « chaude », donc du côté serveur, il est plus probable qu'elle soit utilisée pour des serveurs de longue durée que pour des scripts ponctuels.
Et le JIT peut faire une grande différence ! Dans Pinafore, j'ai envisagé de remplacer la bibliothèque blurhash basée sur JavaScript par une version Rust (Wasm), avant de réaliser que la différence de performance était effacée au moment où nous arrivions à la cinquième itération. C'est la puissance du JIT.
Peut-être qu'un jour un outil comme Porffor pourrait être utilisé pour faire une compilation AOT (Ahead-Of-Time) des scripts Node. En attendant, le JIT reste un cas où les langages natifs ont une longueur d'avance sur JavaScript.
Je dois également reconnaître que l'utilisation de Wasm a un impact sur la performance par rapport aux outils purement natifs. Cela pourrait donc être une autre raison pour laquelle les outils natifs prennent d'assaut le monde CLI, mais pas nécessairement le frontend du navigateur.
Contributions et débogage
J'y ai fait allusion plus tôt, mais c'est la principale source de mon scepticisme à l'égard du mouvement "tout réécrire en natif".
JavaScript est, à mon avis, un langage de classe ouvrière. Il pardonne beaucoup les types (c'est l'une des raisons pour lesquelles je ne suis pas un grand fan de TypeScript), il est facile à prendre en main (comparé à quelque chose comme Rust), et comme il est supporté par les navigateurs, il y a un grand nombre de personnes qui le maîtrisent.
Pendant des années, les auteurs et les utilisateurs de bibliothèques de l'écosystème JavaScript ont largement utilisé JavaScript. Je pense que nous tenons pour acquis ce que cela permet.
Tout d'abord, le chemin vers la contribution est beaucoup plus facile. Pour citer Matteo Collina :
Citation:
La plupart des développeurs ignorent qu'ils ont les compétences nécessaires pour déboguer, corriger et modifier leurs dépendances. Elles ne sont pas maintenues par des demi-dieux inconnus, mais par des collègues développeurs.
Cela ne fonctionne plus si les auteurs de bibliothèques JavaScript utilisent des langages différents (et plus difficiles !) que JavaScript. Ils pourraient tout aussi bien être des demi-dieux !
Autre chose : il est facile de modifier localement les dépendances JavaScript. J'ai souvent modifié quelque chose dans mon dossier node_modules local lorsque j'essayais de trouver un bogue ou de travailler sur une fonctionnalité dans une bibliothèque dont je dépendais. En revanche, si la bibliothèque est écrite dans un langage natif, je dois consulter le code source et le compiler moi-même, ce qui constitue une importante barrière à l'entrée.
(Pour être honnête, cela est déjà devenu un peu difficile grâce à l'utilisation répandue de TypeScript. Mais TypeScript n'est pas très éloigné du code source JavaScript, et vous seriez surpris de voir jusqu'où vous pouvez aller en cliquant sur "pretty print" dans les DevTools. Heureusement, la plupart des bibliothèques Node ne sont pas minifiées non plus).
Bien sûr, cela nous ramène à la débogabilité. Si je veux déboguer une bibliothèque JavaScript, je peux simplement utiliser les DevTools du navigateur ou un débogueur Node.js que je connais déjà. Je peux définir des points d'arrêt, inspecter des variables et raisonner sur le code comme je le ferais pour mon propre code. Ce n'est pas impossible avec Wasm, mais cela demande des compétences différentes.
Conclusion
Je pense qu'il est formidable qu'il y ait une nouvelle génération d'outils pour l'écosystème JavaScript. J'ai hâte de voir où aboutiront des projets comme Oxc et VoidZero. Les titulaires actuels sont en effet excessivement lents et bénéficieraient probablement de la concurrence. (Je suis particulièrement agacé par le cycle typique eslint + prettier + tsc + rollup lint+build).
Cela dit, je ne pense pas que JavaScript soit intrinsèquement lent, ou que nous ayons épuisé toutes les possibilités de l'améliorer. Parfois, je regarde un JavaScript vraiment axé sur la performance, comme les récentes améliorations apportées aux DevTools de Chromium qui utilisent des techniques époustouflantes telles que l'utilisation de Uint8Arrays comme vecteurs de bits, et j'ai l'impression que nous avons à peine effleuré la surface. (Si vous voulez vraiment un complexe d'infériorité, voyez les autres commits de Seth Brenith. C'est de la folie).
Je pense également qu'en tant que communauté, nous n'avons pas vraiment réfléchi à ce à quoi ressemblerait le monde si nous reléguions l'outillage JavaScript à une élite de développeurs Rust et Zig. Je peux imaginer que le développeur JavaScript moyen se sente complètement désespéré chaque fois qu'il y a un bug dans l'un de ses outils de construction. Plutôt que de donner à la prochaine génération de développeurs web les moyens d'aller plus loin, nous risquons de les former à une carrière d'impuissance apprise. Imaginez ce que ressentira le développeur junior moyen lorsqu'il sera confronté à un défaut de ségrégation plutôt qu'à une erreur JavaScript familière.
À ce stade, je suis un senior dans ma carrière, et j'ai donc peu d'excuses pour m'accrocher à ma couverture de sécurité JavaScript. Cela fait partie de mon travail de creuser quelques couches plus profondes et de comprendre comment chaque partie de la pile fonctionne.
Cependant, je ne peux m'empêcher de penser que nous nous engageons sur une voie inconnue aux conséquences inattendues, alors qu'il existe une autre voie moins périlleuse qui pourrait nous permettre d'obtenir pratiquement les mêmes résultats. Le train de marchandises actuel ne montre aucun signe de ralentissement, alors je suppose que nous le découvrirons quand nous y arriverons.
Source : Why I’m skeptical of rewriting JavaScript tools in “faster” languages
Et vous ?
:fleche: Pensez-vous que ces affirmations sont crédibles ou pertinentes ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: Chaîne de prototypes JavaScript : Guide court et simple, par Mensur Durakovic
:fleche: « L'utilisation incessante de frameworks JavaScript de pointe a contribué à rendre le Web moins accessible », d'après Easy Laptop Finder, selon lequel ces derniers détruisent les performances des sites Web
:fleche: Comment mettre à l'échelle les applications Node.js, par Mensur Durakovic
