Les résultats de référence pour Next.js 12 sont convaincants. Mais est-ce que ça vaut le coup de changer ?

Lors de notre récent événement de team building, j'ai expliqué pourquoi les développeurs JavaScript déplacent leurs outils vers Rust. C'était une conférence plutôt bien accueillie et nous avons décidé que ce serait cool de la partager avec le monde. Alors voilà. Ceci est la version éditée de la conférence, écrite pour la lecture et il y aura un screencast sur notre chaîne Podcast. Alors plongeons-y directement.

Arrière plan

Une tendance courante dans les logiciels est d'écrire les outils que nous utilisons en tant que développeurs pour créer nos applications dans le même langage que nous utilisons pour créer des applications. Par exemple, pip est écrit en Python, Composer est écrit en PHP, Maven en Java, etc. Cela a du sens car la plupart du temps, les personnes qui créent les outils sont également celles qui les utilisent. Il est donc plus facile de travailler simplement dans la langue de son choix.

JavaScript ne fait pas exception. De Gulp et Bower à babel et Webpack, nous avons tout écrit en JavaScript. Cela a bien fonctionné pour nous mais il y avait quelques problèmes.

Le problème avec JavaScript

Pour voir le problème, nous devons examiner les propriétés de JavaScript. JavaScript est un langage de script léger pour les pages Web. Bien sûr, nous l'utilisons maintenant partout, des backends aux bases de données, mais il a été conçu à l'origine pour rendre les pages brillantes en premier et tout le reste en second, ce qui se voit.

C'est un langage interprété qui peut être compilé juste-à-temps et qui est monothread. Oui, oui, je connais la création de plusieurs instances et la communication avec les travailleurs Web… mais à mon avis, ce n'est pas du multi-threading, c'est une solution de contournement vaudou étrange qui essaie de nous distraire du fait que nous n'avons pas de multi-threading natif .

Un problème plus important est qu'il est assez lent sur la console, par rapport aux autres langues.

Alors que JavaScript est génial sur une page, il est un peu nul sur une console.

Ainsi, un groupe de développeurs JavaScript se sont réunis un jour dans une pièce sombre et après un verre de trop, quelqu'un a dit :

« Hé les gars, et si… écoutez-moi… et si nous n'écrivions pas les outils qui construisent notre JavaScript, en JavaScript ?

Il y a eu un halètement collectif, des chaises ont été jetées, des bagarres ont éclaté et une fois la poussière retombée, tout le monde a accepté de l'essayer.

Ok, j'ai peut-être inventé cela mais le résultat est toujours le même, nous créons maintenant des outils de construction JavaScript dans des langages autres que JavaScript.

Mais pourquoi Rust ?

En un mot… rapidité et buffer-overflows .

Rust est un langage de programmation polyvalent multi-paradigme conçu pour la performance et la sécurité. C'est comme C++ mais pour les millénaires et les zoomers. C'est un langage système qui applique la sécurité de la mémoire et a une concurrence "sûre". Il est syntaxiquement similaire à C++ et, plus important encore, il est presque aussi rapide que C++.

Allégations prometteuses

Il existe actuellement un certain nombre de projets qui cherchent à remplacer les outils JavaScript par des outils basés sur Rust. Quelques exemples sont ParcelJS, Deno, ESBuild et le compilateur Web Speedy (SWC). Ils prétendent tous fonctionner plus rapidement que tout ce qu'ils essaient de remplacer et si vous voulez rire, consultez la comparaison esbuild .

Pour cet article, je ne les vérifierai pas tous, mais j'examinerai de plus près SWC via Next.js.

Compilateur Web rapide (SWC)

SWC est une plate-forme extensible basée sur Rust pour la prochaine génération d'outils de développement rapides. Cela signifie qu'il s'agit d'un cadre pour créer des constructeurs. Vous pouvez utiliser SWC pour la compilation et le regroupement. Il faudra des fichiers JavaScript / TypeScript utilisant des fonctionnalités JavaScript modernes et cracher du code valide pris en charge par tous les principaux navigateurs.

Les derniers outils Next.js Rusty

Next.js a introduit un compilateur Rust dans la version 12 basé sur SWC. Sur le site Next.js, ils ont revendiqué un rafraîchissement local environ 3 fois plus rapide et des versions de production environ 5 fois plus rapides.

Cela ressemble à une affirmation vérifiable pour moi. Alors je l'ai testé.

J'ai créé exactement le même projet dans les versions 11 et 12 et ajouté les mêmes 400 composants générés. J'ai utilisé React Benchmark Generator pour cela. La seule différence entre les projets était la version de Next.js, tout le reste était identique.

Les résultats ont été assez convaincants. Voici pour Next.js 11 :

Et pour Next.js 12, voilà :

Next.js 12, a mis 12 secondes pour faire ce que Next.js 11 a fait en 1 minute 40 secondes. C'est environ 8 fois plus rapide. Donc ils n'exagéraient clairement pas.

Je ne m'attendais pas non plus à ce que Next.js 12 prenne 12 secondes. Je suppose que c'était une heureuse coïncidence.

Est-ce que ça vaut le battage médiatique ?

Maintenant, la question évidente est : est-ce que ça vaut le coup ?

L'application que nous construisons à la fin de la journée est la même, n'est-ce pas ? Cela ne change pas l'expérience de l'utilisateur final, mais uniquement l'expérience du développeur, alors pourquoi s'en soucier ? Pourquoi réparer quelque chose qui fonctionnait déjà bien ?

Parce que ça ne fonctionnait pas bien. Comme je l'ai déjà dit, JavaScript est génial sur une page mais nul sur une console. Les machines de développement sont des bêtes puissantes et ne pas utiliser ce pouvoir est un terrible gaspillage. C'est aussi un gaspillage coûteux.

Imaginez que vous faites partie d'une équipe de 20 développeurs travaillant sur un grand projet qui est déployé et testé sur un CI basé sur le cloud. Chaque jour, chaque membre de votre équipe propose plusieurs correctifs et fonctionnalités, voici ce qui est susceptible de se produire.

Si votre CI donne des builds simultanés illimités mais facture à la minute de build ou à la seconde de temps processeur, Next.js vous coûtera littéralement 8 fois plus que Next.js 12.

D'un autre côté, s'il donne un prix fixe et un nombre fixe de builds simultanés, vous allez attendre un moment si votre file d'attente de builds augmente ou vous devrez payer pour augmenter le nombre de builds simultanés que vous pouvez exécuter.

Dans tous les cas, les constructions lentes vous coûtent plus cher en temps ou en argent, ou les deux.

Conclusion

JavaScript est un langage étonnant et Internet ne serait pas ce qu'il est sans lui. Mais nous n'avons pas besoin de l'utiliser pour construire nos outils car il existe des langages plus durs, meilleurs, plus rapides, plus forts pour cela, comme Rust, et ça va. Cela n'enlève rien à JavaScript et ce n'est pas une trahison d'abandonner les outils construits basés sur JavaScript pour des outils plus rapides basés sur Rust. Et avouons-le, je ne vais pas souffrir de plusieurs instances JavaScript juste pour obtenir le multi-threading vaudou.