Turbopack, optimis� pour JavaScript et TypeScript, �crit en Rust, est-il vraiment 10x plus rapide que Vite ?

Turbopack, le successeur de Webpack bas� sur Rust, con�u pour faciliter le d�veloppement d'applications web modernes,
peut prendre 1,8 seconde pour d�marrer, tandis que Vite prend 11,4 secondes

Dirig� par le cr�ateur de Webpack, Tobias Koppers, Turbopack, le successeur de Webpack bas� sur Rust ne regroupe que le minimum de ressources n�cessaires au d�veloppement, le temps de d�marrage est donc extr�mement rapide. Sur une application comportant 3 000 modules, le d�marrage de Turbopack prend 1,8 seconde. Vite prend 11,4 secondes et Webpack 16,5 secondes. Turbopack prend en charge d�s le d�marrage les composants de serveur, TypeScript, JSX, CSS, etc. De nombreuses fonctionnalit�s ne sont pas encore prises en charge.

L'architecture de Turbopack tire les le�ons d'outils comme Turborepo et Bazel de Google, qui se concentrent tous deux sur l'utilisation de caches pour ne jamais faire deux fois le m�me travail. Turbopack est construit sur Turbo : un framework open source de m�morisation incr�mental pour Rust. Turbo peut mettre en cache le r�sultat de n'importe quelle fonction du programme. Lorsque le programme est ex�cut� � nouveau, les fonctions ne seront ex�cut�es que si leurs entr�es ont chang�. Cette architecture granulaire permet � votre programme de sauter de grandes quantit�s de travail, au niveau de la fonction.

Pi�ce jointe 627871

Pour un debut, Turbopack sera utilis� pour le serveur de d�veloppement Next.js 13. Il alimentera HMR � la vitesse de l'�clair et prendra en charge les composants de serveur React de mani�re native, ainsi que TypeScript, JSX, CSS, etc. � terme, Turbopack alimentera �galement les constructions de Next.js � la fois localement et dans le cloud. Il sera possible de partager le cache de Turbo avec toute votre �quipe, gr�ce � Vercel Remote Caching. Les utilisateurs de Webpack peuvent �galement s'attendre � une migration incr�mentale vers le futur bas� sur Rust avec Turbopack.

Turbopack est si rapide parce qu'il est construit sur une biblioth�que r�utilisable pour Rust qui permet le calcul incr�mental connu sous le nom de moteur Turbo. Voici comment cela fonctionne :

Mise en cache au niveau des fonctions

Dans un programme �quip� d'un moteur Turbo, il est possible de marquer certaines fonctions comme �tant � � m�moriser �. Lorsque ces fonctions sont appel�es, le moteur Turbo se souviendra de l'objet avec lequel elles ont �t� appel�es et de ce qu'elles ont retourn�. Il les enregistrera ensuite dans un cache en m�moire. Voici un exemple simplifi� de ce � quoi cela peut ressembler dans un bundler :

Pi�ce jointe 627868

Nous commen�ons par appeler readFile sur deux fichiers, api.ts et sdk.ts. Nous regroupons ensuite ces fichiers, les concat�nons ensemble et obtenons le fullBundle � la fin. Les r�sultats de tous ces appels de fonction sont enregistr�s dans le cache pour plus tard. Imaginons que nous soyons sur un serveur de d�veloppement. Vous enregistrez le fichier sdk.ts sur votre machine. Turbopack re�oit l'�v�nement du syst�me de fichiers, et sait qu'il doit recalculer readFile("sdk.ts") :

Puisque le r�sultat de sdk.ts a chang�, nous devons le regrouper � nouveau, qui doit ensuite �tre concat�n� � nouveau. Il est important de noter que le fichier api.ts n'a pas chang�. Nous lisons son r�sultat dans le cache et le passons � concat � la place. Du temps est gagn� en �vitant de le lire et de le regrouper � nouveau. Imaginez maintenant cette situation dans un vrai bundler, avec des milliers de fichiers � lire et de transformations � ex�cuter. Le mod�le mental est le m�me. Vous pouvez �conomiser d'�normes quantit�s de travail en vous souvenant du r�sultat des appels de fonction et en �vitant de refaire le travail qui a d�j� �t� fait.

Le cache

Le moteur Turbo stocke actuellement son cache en m�moire. Cela signifie que le cache durera aussi longtemps que le processus qui l'ex�cute - ce qui fonctionne bien pour un serveur de d�veloppement. Lorsque vous ex�cutez next dev --turbo dans Next v13, vous d�marrez un cache avec le moteur Turbo. Lorsque vous annulez votre serveur de d�veloppement, le cache est effac�.

Pi�ce jointe 627872

Dans le futur, l��quipe en charge pr�voit de faire persister ce cache - soit dans le syst�me de fichiers, soit dans un cache distant comme celui de Turborepo. Cela signifierait que Turbopack pourrait se souvenir du travail effectu� � travers les runs et les machines. Cette approche rend Turbopack extr�mement rapide pour calculer les mises � jour incr�mentales des applications. Cela optimise Turbopack pour la gestion des mises � jour dans le d�veloppement, ce qui signifie que votre serveur de d�veloppement r�pondra toujours rapidement aux changements.

� l'avenir, un cache persistant ouvrira la porte � des constructions de production beaucoup plus rapides. En se souvenant du travail effectu� au cours des cycles, les nouvelles constructions de production ne pourront reconstruire que les fichiers modifi�s, ce qui pourrait entra�ner un gain de temps consid�rable.

Source : Vercel

Et vous ?

:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Next.js 13 est disponible, elle apporte Turbopack, le nouveau successeur de Webpack bas� sur Rust, sur une application comportant 3 000 modules, le d�marrage de Turbopack prend 1,8 seconde

:fleche: La version 12 de Next.js, l'outil de d�veloppement open source construit autour de Node.js, est disponible, avec un compilateur Rust 17x plus rapide que Babel et une priorit� aux modules ES

:fleche: Next.js 11 est disponible, elle am�liore le temps de d�marrage de 24 % et r�duit de 40 % le temps de traitement des modifications

Le concurrence entre Vite et Turbopack peut �tre b�n�fique.
Cependant, il reste � v�rifier que Turbopack est vraiment plus rapide que Vite et quels sont leur p�rim�tre technique respectif.
Actuellement, des tests ont commenc� � �tre fait et on est loin des "10x plus rapide que Vite"
https://twitter.com/youyuxi/status/1585887853036195841

Turbopack, optimis� pour JavaScript et TypeScript, �crit en Rust, est-il vraiment 10x plus rapide que Vite ?
Le d�veloppeur Evan You oppose un benchmark utilisant le tout nouveau Next 13 et Vite 3.2

Dans un article r�dig� le 26 octobre, nous pr�sentions Turbopack, un syst�me de construction et de regroupement incr�mental optimis� pour JavaScript et TypeScript, �crit en Rust. Aujourd�hui Vercel affirme que sur les applications � grande �chelle, Turbopack se met � jour 10x plus vite que Vite et 700x plus vite que Webpack. Pour les plus grosses applications, la diff�rence est encore plus marqu�e, avec des mises � jour jusqu'� 20 fois plus rapides que Vite. Afin de voir plus clair et de v�rifier les affirmations de Vercel, le d�veloppeur Evan You a effectu� un benchmark utilisant le tout nouveau Next 13 et Vite 3.2.

Turbopack est actuellement en version alpha. Il n'est pas encore pr�t pour une utilisation en production. Mais NextJS permet d'utiliser Turbopack avec next dev --turbo alors le serveur de d�veloppement NextJS v13 est maintenant aliment� par Turbopack.

Dirig� par Tobias Koppers, le cr�ateur de Webpack, Turbopack ne regroupe que le minimum de ressources n�cessaires au d�veloppement, le temps de d�marrage est donc extr�mement rapide. Sur une application comportant 3 000 modules, le d�marrage de Turbopack prend 1,8 seconde. Vite prend 11,4 secondes et Webpack 16,5 secondes. Turbopack prend en charge d�s le d�marrage les composants de serveur, TypeScript, JSX, CSS, etc. De nombreuses fonctionnalit�s ne sont pas encore prises en charge.

Pi�ce jointe 628823

L'architecture de Turbopack tire les le�ons d'outils comme Turborepo et Bazel de Google, qui se concentrent tous deux sur l'utilisation de caches pour ne jamais faire deux fois le m�me travail. Turbopack est construit sur Turbo : un framework open source de m�morisation incr�mental pour Rust. Turbo peut mettre en cache le r�sultat de n'importe quelle fonction du programme. Lorsque le programme est ex�cut� � nouveau, les fonctions ne seront ex�cut�es que si leurs entr�es ont chang�. Cette architecture granulaire permet � votre programme de sauter de grandes quantit�s de travail, au niveau de la fonction.

Dans divers documents marketing de Vercel, on retrouve la phrase � Turbopack est 10x plus rapide que Vite �. Cette phrase est r�p�t�e y compris un tweet, un article de blog et des courriels de marketing envoy�s aux utilisateurs de Vercel. Les graphiques de benchmark sont �galement inclus dans la documentation de Turbopack, montrant � l'origine que Next 13 avec Turbopack est capable d'effectuer un React Hot-Module Replacement (HMR) en 0,01s alors qu�avec Vite, cela prend 0,09s.

Initialement, Vercel n'a pas inclus de liens vers les benchmarks qu'ils ont utilis�s pour produire ces chiffres dans les documents marketing ou la documentation. Le d�veloppeur Evan You dans sa qu�te de v�rit� a d�cid� de v�rifier les affirmations avec un benchmark utilisant le tout nouveau Next 13 et Vite 3.2. L'essentiel de sa m�thodologie consiste � comparer les performances de HMR en mesurant le delta entre les deux horodatages suivants :

• le moment o� un fichier source est modifi�, enregistr� via un processus Node.js s�par� surveillant les changements de fichiers ;
• l'heure � laquelle le composant React mis � jour est rendu, enregistr�e via un appel � Date.now() directement dans la sortie de rendu du composant.

M�thodologie

1. Les deux projets sont cr��s � partir des commandes suivantes :
   
   npx create-next-app@latest ;
   npm init vite@latest # select React preset
2. genFiles.(m)js est ex�cut� dans chaque projet pour g�n�rer 1000 composants. Tous les composants sont import�s dans le composant racine de l'application (dans le cas de Next, le composant racine de la page) et rendus ensemble. Cette �tape est d�j� r�alis�e et les fichiers sont d�j� archiv�s, mais le script est inclus pour r�f�rence
3. Pour Next, app/page.js poss�de la directive "use client", ce qui lui permet d'effectuer le rendu en mode client. Cela est n�cessaire pour assurer une comparaison correcte, car les composants du serveur entra�nent une surcharge HMR non n�gligeable (4 fois plus lente)
4. Pour Vite, vite-plugin-swc-react-refresh est utilis� pour que la transformation React JSX & HMR utilise swc au lieu de Babel. La raison pour laquelle le plugin React par d�faut de Vite utilise Babel est que l'utilisation de swc entra�ne 58 Mo de poids d'installation suppl�mentaire (alors que Vite lui-m�me fait 19 Mo) pour une am�lioration marginale de HMR. Cependant, pour les besoins de l'�valuation comparative, Evan You utilise les m�mes transformations que celles utilis�es par turbopack afin que la comparaison soit ax�e sur les m�canismes HMR des deux outils
5. pour chaque projet, nous ex�cutons watch.(m)js dans un processus Node s�par� pour obtenir l'horodatage exact du changement de fichier. Ceci est utilis� pour marquer le d�but de HMR
6. D�marrez les projets (vite et next dev --turbo), puis �ditez les fichiers suivants pour tester HMR :
   
   • Next: app/page.js (root) and app/comp0.jsx (leaf)
   • Vite: src/App.jsx (root) and src/components/comp0.jsx (leaf)

Les composants �dit�s affichent tous Date.now() dans leur sortie. L'horodatage final rendu dans le DOM est utilis� pour marquer l'ach�vement de HMR. Le benchmark mesure �galement les chiffres dans deux cas diff�rents :

• le cas "root", o� le composant importe 1 000 composants enfants diff�rents et les rend �galement ensemble ;
• le cas "leaf", o� le composant est import� par la racine mais n'a pas d'importations ou de composants enfants propres.

Nuances

Avant de passer aux chiffres, il y a quelques nuances suppl�mentaires qui m�ritent d'�tre mentionn�es :

• si Next utilise React Server Components (RSC) ;
• si Vite utilise SWC au lieu de Babel pour les transformations React.

React Server Components

Next 13 a introduit un changement architectural majeur dans la mesure o� les composants sont d�sormais des composants serveur par d�faut, � moins que l'utilisateur n'opte explicitement pour le mode client avec la directive use client. Non seulement c'est le mode par d�faut, mais la documentation de Next recommande �galement aux utilisateurs de rester en mode serveur autant que possible pour am�liorer les performances de l'utilisateur final.

Le benchmark initial d�Evan You a mesur� les performances HMR de Next 13 avec les composants root et leaf en mode serveur. Le r�sultat a montr� que Next 13 �tait en fait plus lent dans les deux cas, et la diff�rence �tait significative pour les composants leaf.

Pi�ce jointe 628824

• Enregistr� sur 5 cycles
• Temps en ms
• Test� sur Mackbook Pro M1

En ajoutant la directive use client au composant root de Next pour passer en mode client, Next HMR s'am�liore de mani�re significative, allant 2x plus vite que Vite :

Pi�ce jointe 628825

Transformations SWC vs. Babel

L�objectif est de faire en sorte que le benchmark se concentre uniquement sur la diff�rence de performance HMR. Les transformations React HMR et JSX ne sont pas des fonctionnalit�s coupl�es aux outils de construction. Elles peuvent �tre effectu�es via Babel (bas� sur js) ou SWC (bas� sur rust). Esbuild peut �galement transformer JSX, mais ne supporte pas HMR.
SWC est significativement plus rapide que Babel (20x en mono-fil, 70x en multi-c�urs).

La raison pour laquelle Vite utilise actuellement Babel par d�faut est un compromis entre la taille de l'installation et l'aspect pratique. La taille de l'installation de SWC est assez lourde (58MB dans node_modules alors que Vite lui-m�me ne fait que 19MB), et de nombreux utilisateurs s'appuient encore sur Babel pour d'autres transformations, donc un passage � Babel �tait quelque peu in�vitable pour eux. Cependant, cela pourrait changer � l'avenir.

Plus important encore, l'impl�mentation de Webpack dans le m�me benchmark utilise �galement SWC.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

use std::{ fs, path::Path, process::{Child, Command, Stdio}, };   use anyhow::{anyhow, Context, Result}; use regex::Regex;   use crate::{ bundlers::Bundler, util::{ npm::{self, NpmPackage}, wait_for_match, }, };   pub struct Webpack; impl Bundler for Webpack { fn get_name(&self) -> &str { "Webpack CSR" }   fn prepare(&self, install_dir: &Path) -> Result<()> { npm::install( install_dir, &[ NpmPackage::new("@pmmmwh/react-refresh-webpack-plugin", "0.5.7"), NpmPackage::new("@swc/core", "1.2.249"), NpmPackage::new("react-refresh", "0.14.0"), NpmPackage::new("swc-loader", "0.2.3"), NpmPackage::new("webpack", "5.74.0"), NpmPackage::new("webpack-cli", "4.10.0"), NpmPackage::new("webpack-dev-server", "4.11.0"), ], ) .context("failed to install from npm")?;   fs::write( install_dir.join("webpack.config.js"), include_bytes!("webpack.config.js"), )?;   Ok(()) }   fn start_server(&self, test_dir: &Path) -> Result<(Child, String)> { let mut proc = Command::new("node") .args([ (test_dir .join("node_modules") .join("webpack-dev-server") .join("bin") .join("webpack-dev-server.js") .to_str() .unwrap()), "--port", "0", ]) .env("NO_COLOR", "1") .current_dir(test_dir) .stdout(Stdio::piped()) .stderr(Stdio::piped()) .spawn() .context("failed to run `webpack-dev-server` command")?;   let addr = wait_for_match( proc.stderr .as_mut() .ok_or_else(|| anyhow!("missing stderr"))?, Regex::new("\\[webpack\\-dev\\-server\\] Loopback:\\s+(.*)")?, ) .ok_or_else(|| anyhow!("failed to find devserver address"))?;   Ok((proc, addr)) } }

---

Le noyau de Vite ne repose pas sur Babel. L'utilisation de SWC au lieu de Babel pour g�rer les transformations React ne n�cessite aucune modification dans Vite lui-m�me - il suffit de remplacer le plugin React par d�faut par vite-plugin-swc-react-refresh. Apr�s le changement, une am�lioration significative pour Vite dans le cas de root a �t� constat�, rattrapant ainsi Next :

Pi�ce jointe 628826

Il est int�ressant de noter que la courbe de croissance montre que Next/turbo est devenu 4x plus lent dans le cas de la racine par rapport au cas de la feuille, alors que Vite est devenu seulement 2,4x plus lent. Cela implique une courbe o� Vite HMR �volue mieux dans des composants encore plus grands.
De plus, le passage au SWC devrait �galement am�liorer les m�triques de d�marrage � froid de Vite dans les benchmarks de Vercel.

Performances sur diff�rents mat�riels

Comme il s'agit d'un benchmark mixte qui implique � la fois Node.js et des parties natives de Rust, il y aura une variance non-triviale sur diff�rents mat�riels. Les chiffres affich�s par Evan You ont �t� recueillis sur un MacBook Pro M1. D'autres utilisateurs ont ex�cut� le m�me benchmark sur diff�rents mat�riels et ont rapport� des r�sultats diff�rents. Dans certains cas, Vite est plus rapide avec root, alors que dans d'autres, Vite est significativement plus rapide dans les deux cas.

Apr�s la publication du benchmark d�Evan You, Vercel a publi� un billet de blog clarifiant leurs m�thodologies de benchmark, et a rendu leur benchmark disponible pour une v�rification publique. � Turbopack et Next.js 13.0.1 sont sortis, corrigeant une r�gression qui s'est gliss�e avant la sortie publique et apr�s que les premiers benchmarks aient �t� effectu�s. Nous avons �galement corrig� un bug d'arrondi incorrect sur notre site Web (0,01s → 15ms). Nous appr�cions le travail d'Evan You qui nous a permis d'identifier et de corriger ce probl�me �, �crit Vercel.

You Yuxi, le cr�ateur de Vue.js, estime que la concurrence pour les logiciels libres doit �tre fond�e sur une communication ouverte, une comparaison �quitable et un respect mutuel. Il a donc �t� d��u et inquiet lorsqu'il a vu que Vercel utilisait des donn�es soigneusement s�lectionn�es, non �valu�es par des pairs et trompeuses pour son marketing, un sc�nario qui ne se produit g�n�ralement que dans le cadre d'une comp�tition commerciale.

Sources : Evan YOU, Turbo

Et vous ?

:fleche: Quel est votre avis sur le sujet ?

:fleche: Trouvez-vous pertinent le benchmark r�alis� par Evan YOU ?

Voir aussi :

:fleche: Turbopack, le successeur de Webpack bas� sur Rust, con�u pour faciliter le d�veloppement d'applications web modernes, peut prendre 1,8 seconde pour d�marrer, tandis que Vite prend 11,4 secondes

:fleche: Next.js 13 est disponible, elle apporte Turbopack, le nouveau successeur de Webpack bas� sur Rust, sur une application comportant 3 000 modules, le d�marrage de Turbopack prend 1,8 seconde

Un benchmark sur un seul type de machine, est-ce encore vraiment un benchmark ?

Citation:

---

Turbopack est actuellement en version alpha. Il n'est pas encore pr�t pour une utilisation en production.

---

Tout est dit.

Qui plus est, on parle de performances en d�marrage.
Hors en production, on ne s'amuse pas � r�g�n�rer les caches toutes les secondes, �a ne change pas visiblement les performances du JS.

d'autant plus que le mode production de turbopack n'est pas encore disponible. cela dit de mon cot� sur des vrais projet j'ai remarqu� des sacr�s gains de perfs en dev par rapport � webpack 5 , mais c'est pas encore au niveau pour cr�er des benchs repr�sentatifs, je serais convaincu lorsque la config des loaders sera pleinement g�r� ( d'ici la ils vont sortir webpack 6 malgr� que les devs webpack soit un peu inactifs en ce moment)

J'aurai toujours plus confiance dans un programme compil� avec rustc qu'avec du Javascript ou meme du Typescript meme si c'est toujours un peu mieux. Mais j'aime trop Rust pour etre de bonne foi.