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 :
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 :
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 ?
Pensez-vous que ces affirmations sont cr�dibles ou pertinentes ?
Quel est votre avis sur le sujet ?
Voir aussi :
Cha�ne de prototypes JavaScript : Guide court et simple, par Mensur Durakovic
� 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
Comment mettre � l'�chelle les applications Node.js, par Mensur Durakovic
Pourquoi je suis sceptique quant � la r��criture des outils JavaScript dans des langages "plus rapides"
R�pondre avec citation
Envoy� par olikaf
).
). Certains me parleront de l'inf�rence de types qui peut �tre une solution. Mais le d�faut de l'inf�rence de types est que ce n'est pas ce qui se fait de mieux en mati�re de maintenance et de compr�hension de code, surtout pour celui qui n'a pas un IDE ayant la gentillesse de lui indiquer le type implicite.
Partager