đŸ—» Snowpack đŸ—» le remplaçant de webpack ?

#webpack#snowpack#vitejs#bundler
Article disponible en: English

AprĂšs webpack, esbuild et vitejs, prenons le temps d’étudier le cas de snowpack. Ce dernier semble se faire un petit nom dans l’écosystĂšme des bundlers depuis quelques annĂ©es maintenant. Je vous propose donc qu’on Ă©tudie ses fonctionnalitĂ©s, ses points forts mais Ă©galement ses points faibles.

Snowpack

Snowpack c’est quoi ? C’est un packager d’application web qui propose :

  • une expĂ©rience de dĂ©veloppement riche et performante
  • un mode production qui propose les features nĂ©cessaires Ă  l’optimisation des assets du site.
# npm:
npm install --save-dev snowpack
# yarn:
yarn add --dev snowpack

ESModule dans le navigateur

Les packagers comme webpack et rollup se reposent sur la construction d’un arbre de dĂ©pendances qui sont analysĂ©es et packagĂ©es Ă  chaque modification. L’étape de build des fichiers modifiĂ©s reste nĂ©cessaire, cependant l’opĂ©ration de packaging (fusion des diffĂ©rents modules sous la forme de bundle qu’on envoie au navigateur) n’est plus nĂ©cessaire. Nos navigateurs savent maintenant gĂ©rer les ESModules, il n’est donc plus nĂ©cessaire de packager nos modules sources pour les fusionner.

C’est la mĂȘme idĂ©e qu’Evan You a repris dans Vite

Avec ce principe, la modification d’un fichier ne dĂ©clenche que le build de ce fichier, et ce fichier uniquement. Vous pourrez avoir un projet avec des milliers de modules javascript, le temps de build Ă  chaque modification ne se retrouvera pas affectĂ©. Pour les dĂ©pendances (vendors), Snowpack les build une fois pour toutes et les mets en cache pour ne le refaire que si celles-ci ont changĂ©es.

Voici un schĂ©ma prĂ©sent dans la doc de Snowpack montrant bien l’intĂ©rĂȘt d’éviter le packaging en dev.

explication du mode de fonctionnement de snowpack qui se consentre sur le build uniquement

Si vous utilisez un projet Create React App, il vous suffit d’ajouter Snowpack en dĂ©pendance, vous n’avez rien Ă  changer si vous n’avez pas Ă©tendu la config de webpack. Je vous invite Ă  tester snowpack grĂące aux gĂ©nĂ©rateurs de templates:

npx create-snowpack-app react-snowpack --template @snowpack/app-template-react

Rassurez vous! Snowpack n’est pas compatible qu’avec React, vous pouvez utiliser Vue, Svelte ou bien juste du javascript.

Une config riche (trop)

À la maniĂšre de webpack, snowpack propose de configurer son utilisation par un objet. Je dois vous avouer qu’aprĂšs avoir jouĂ© avec vite, je suis un peu déçu. Je vois une maigre page de documentation qui semble pourtant dĂ©crire de nombreuses clĂ©s paramĂštrables.

Si vous venez de webpack, vous ne serez pas perdu, c’est trĂšs ressemblant sans pour autant ĂȘtre exactement la mĂȘme chose.

Eviter de toucher la configuration par dĂ©faut peut ĂȘtre une excellente idĂ©e.

Une belle collection de plugin

Snowpack n’est pas si rĂ©cent que ça. Une communautĂ© a su se construire pour mettre en place un Ă©cosystĂšme de plugin riche. Certains de ces plugins semblent “core” car sous le scope @snowpack mais de nombreux packages sont portĂ©s par quelques personnes indĂ©pendantes du projet. C’est rassurant sans l’ĂȘtre, j’ai personnellement connu des mises Ă  jour de webpack bloquĂ©es/retardĂ©es en attendant la compatibilitĂ© de certains plugins qui n’étaient plus maintenus.

plugins list page screenshot

MĂ©fiez-vous des plugins que vous utilisez!

Contrairement Ă  Vite qui propose nativement plein de fonctionnalitĂ©s assez sympathiques, snowpack fonctionne lui comme webpack en se basant sur les plugins pour enrichir l’API. C’est un pari, il peut ĂȘtre compliquĂ© de garder cet Ă©cosystĂšme de plugin Ă  jour et performant pour continuer de garantir l’intĂ©rĂȘt d’une migration sur snowpack.

Du Server Side Rendering

Snowpack propose une solution pour implĂ©menter vos applications avec du server-side rendering. Force est de constater que le besoin du SSR se fait encore ressentir sur nos applications frontend pour des raisons SEO ou bien de performance de rendu. Malheureusement, cotĂ© packager d’application, cela reste encore compliquĂ© et il reste souvent nĂ©cessaire de faire deux builds:

  • un build pour le client aka le Navigateur
  • un build pour le server Node

Double build, double peine !

La technique proposĂ©e par Snowpack reste limitĂ©e mais ça reste correct. Je vous propose une lĂ©gĂšre amĂ©lioration de l’implĂ©mentation en ajoutant les mĂ©caniques de rendu server bufferisĂ©.

const {readFileSync} = require('fs');
const {startServer} = require('snowpack');
const server = await startServer({ ... });
const runtime = server.getServerRuntime();

app.use(async (req, res, next) => {
  const importedComponent = await runtime.importModule('/dist/MyReactComponent.js');
  const MyReactComponent = importedComponent.exports.default;
  const html = ReactDOMServer.renderToNodeStream(React.createElement(MyReactComponent, null));
  // Directly write the head of page
  res.write(`
    <html>
    <head>
      <title>Hello 👋</title>
    </head>
    <body>
    <div id="app">
  `)
  // Render bufferized version of App
  html.pipe(res, { end: false });
  // When buffer end, we add the closing tags of page
  html.on('end', () => {
    res.write(`
      </div>
      </body>
      </html>
    `);
    res.end();
  });
});

Webpack, esbuild, vite, snowpack, on part sur quoi ?

Clairement aprĂšs cette sĂ©rie d’article oĂč j’ai essayĂ© d’étudier cette nouvelle gĂ©nĂ©ration d’outils pour bundler les applications, je dois avouer que je suis trĂšs surpris. On voit clairement que le support des ES Modules dans le navigateur marque l’entrĂ©e dans une nouvelle Ăšre. Comme le rappelle Sindre Sorhus dans son dernier article, avec la fin du support de Node 10 et les capacitĂ©es de nos navigateurs actuels, il n’est maintenant plus nĂ©cessaire de cibler du CJS.

Les stratĂ©gies de cache et l’usage des modules CJS semblent aujourd’hui bien dĂ©passĂ©es pour nos besoins en environnement de dĂ©veloppement. On voit bien que Vite et Snowpack proposent cette nouvelle mĂ©canique qui semble ĂȘtre vraiment performante. Faire un build once for all des librairies et de chaque fichier source est une super idĂ©e pour ne pas souffrir d’un temps de dĂ©marrage trop lent de nos grosses applications web.

Gardons à l’oeil Esbuild

Cependant, la performance de ces nouveaux outils repose aussi essentiellement sur Esbuild. L’idĂ©e d’utiliser une stack plus optimisĂ©e pour lire, parser, combiner des modules JS ou TS avec des langages qui permettent une gestion IO et mĂ©moire plus fine est vraiment la clĂ© de voute de cette nouvelle gĂ©nĂ©ration d’outils. Avant mĂȘme de choisir s’il faut rester sur webpack, ou utiliser Vite et Snowpack, il est certain qu’il faudra suivre de prĂšs Esbuild. Cette lib n’a pas fini de nous surprendre. Il faut Ă©galement s’intĂ©resser Ă  un outil comme SWC qui est un concurrent direct d’Esbuild. Il y a certainement d’autres outils en cours de crĂ©ation dans le mĂȘme genre.

J’utilise webpack et je l’ai beaucoup configurĂ©

Si vous ĂȘtes dans cette situation, vous pouvez malheureusement ĂȘtre contraint de conserver webpack. Ce n’est pas une mauvaise nouvelle, c’est un trĂšs bon outil qui est loin d’ĂȘtre obsolĂšte. Il y a fort Ă  parier que la team de webpack va nous proposer encore de nouvelles amĂ©liorations de performances qui passeront peut-ĂȘtre par l’usage des ESModules.

Vous pouvez Ă©galement tenter d’utiliser snowpack en environnement de dĂ©veloppement. Il existe d’ailleurs un plugin pour utiliser webpack dans le build de prod de snowpack.

Je souhaite vraiment réduire la configuration du build de mon application

Si vous ne souhaitez plus conserver vos fichiers de configuration webpack qui peuvent ĂȘtre parfois difficilement maintenable, l’alternative proposĂ©e par Vite peut ĂȘtre une super option. Gardez seulement Ă  l’esprit que cette solution reste jeune.

Quitte à utiliser Vite, je vous conseille de minimiser la configuration que vous pourriez lui apporter. Cela vous permettra plus facilement de suivre les nouvelles versions qui risquent d’arriver dans les mois qui viennent.

J’utilise un CLI qui gùre ma configuration de build pour moi

Vous utilisez VueCLI, CRA, ou autre et vous n’avez pas Ă©jectĂ© votre configuration. Vous n’aimez pas trop toucher Ă  la configuration de build de votre application car les outils sont complexes et vous ne souhaitez pas passer un temps monstre Ă  les configurer. Je vous recommande donc de rester un maximum avec la configuration par dĂ©faut de votre projet tant que les performances de celle-ci ne vous gĂšnent pas.

Cependant, rien ne vous interdit de tester les outils comme Vite qui marchent directement sans configuration avec vos projets dĂ©jĂ  gĂ©nĂ©rĂ©s. Si le temps de dĂ©marrage de votre environnement de dĂ©veloppement devient trop important, cela peut vraiment ĂȘtre une solution intĂ©ressante pour vous.

Et c’est dĂ©jĂ  la fin ?

Je pense avoir fait le tour des nouveaux outils proposĂ©s par la communautĂ© pour packager nos applications web. Si vous avez d’autres outils qu’il serait intĂ©ressant d’examiner, n’hĂ©sitez pas Ă  me le proposer sur un rĂ©seau social comme Twitter. À bientĂŽt pour de nouvelles pĂ©rĂ©grinations javascriptesques !👋

Merci Ă  JĂ©rĂ©mie pour la review đŸ€—


Ecrit par Antoine Caron qui vit et travaille Ă  Lyon et dĂ©veloppe des choses utiles Ă  Bedrock. Tu devrais le suivre sur Twitter. N’hĂ©sites pas Ă  aller voir ses confĂ©rences sur la page dĂ©diĂ©e. Si vous voulez voir mon parcours pro, mon CV est disponible ici en 🇬🇧.

Si vous aimez le contenu de ce blog, ou bien qu'il vous a aidé, s'il vous plait, considérez donner à la fondation Abbé Pierre que je soutiens personnellement.
“On n’est jamais heureux que dans le bonheur qu’on donne. Donner, c’est recevoir.”