Introduction
Pour la deuxième année consécutive, j’ai eu la chance de pouvoir participer aux 3 jours du Breizhcamp grâce à Slickteam.
Lors de ce salon, plusieurs conférences ont particulièrement attiré mon attention. Dans cet article, nous allons nous concentrer sur une d’entre elles qui s’intitule “Parcel.js : le bundler dont vous rêviez ;)”, présentée par Mathieu ANCELIN.
C’était une conférence de 25 minutes divisée en deux parties.
Tout d’abord, elle présentait rapidement plusieurs autres bundlers JavaScript avec leurs avantages et inconvénients, pour ensuite se concentrer sur l’un d’entre eux qui est particulièrement intéressant : Parcel.js.
Petit point technique
Avant de démarrer, une courte définition de ce qu’est un bundler JavaScript peut être utile.
Un bundler JavaScript est un outil qui permet de prendre tout notre code (JavaScript, et parfois d’autres langages, comme nous le verrons…), puis rassemble le tout ainsi que toutes ses dépendances dans un ou plusieurs gros fichiers JavaScript pour rendre l’application plus compacte et rapide, entre autres.
Quelques bundlers JavaScript
Comme dit précédemment, le début du talk se concentrait sur d’autres bundlers (au sens large) JS existants et présentait leurs avantages et inconvénients.
Les descriptions faites des bundles correspondent au moment où Mathieu Ancelin s’en servait, certaines améliorations ont peut-être été faites depuis…
Browserify
Avantages : Outil simple à prendre en main, en lignes de commandes. On donne les fichiers en entrée, le nom du fichier que l’on souhaite en sortie, avec un certain nombre d’options, et l’outil se charge de tout mettre en un bundle. Tout cela rend sa prise en main simple et rapide.
Inconvénients : Lorsque l’on souhaite faire un bundle un peu “poussé”, sur un projet un peu conséquent, avec du minify, de l’uglify, du Babel, etc… la ligne de commande se retrouve avec un grand nombre d’options, ce qui la rend illisible, surtout intégrée aux scripts npm.
Grunt
Avantages : Durant le talk, aucun avantage particulier n’est ressorti de l’utilisation de ce “Task Runner”, si ce n’est que c’était très utilisé (à l’époque où Mathieu Ancelin s’en servait), il était donc possible d’assez rapidement trouver de l’aide pour la construction de ses fichiers de configuration.
Inconvénients : Fichiers de configuration très rapidement lourds et peu réutilisables. Il était difficile de comprendre tout ce qui était fait dans ces fichiers de configuration à cause de leur taille et leur complexité.
Gulp
Avantages : A peu près la même philosophie que Grunt mais un peu mieux pensé grâce à l’utilisation de pipes qui permettait d’ordonner un enchaînement d’actions de façon claire.
Inconvénients : Malgré cet avantage par rapport à Grunt, l’outil restait bas niveau, il fallait indiquer quoi faire sur quels fichiers de façon un peu répétitive, ce qui amenait à de très gros fichiers de configuration. Cela faisait qu’on se contentait de faire un bon fichier de configuration, puis on le réutilisait un peu dans tous les projets, sans trop comprendre, et en croisant les doigts pour que ça marche…
Brunch.io
Avantages : L’arrivée de Brunch a amené de grosses améliorations, notamment le fait qu’il y ait plus de conventions que les précédents outils, tout en étant plus déclaratif. Cela a apporté la possibilité d’utiliser des plugins au sein même de l’outil que l’on décide d’activer ou non selon les besoins. Cela dans le but d’éviter de devoir préciser quel traitement effectuer sur quels fichiers, puisque chaque plugin sait ce qu’il a à faire.
Inconvénients : Aucun inconvénient particulier n’est ressorti de Brunch.io, mais l’arrivée de Webpack a un peu “effacé” l’utilisation de cet outil…
Webpack
Avantages : Le principal avantage qui ressortait de Webpack dès sa sortie a été le fait qu’il sache gérer beaucoup de types de fichiers (JS, SASS, LESS, PNG, etc…). En plus de cela, tout un tas de plugins existent pour Webpack et permettent d’étendre encore les possibilités de l’outil.
Inconvénients : Tout comme certains des outils vus précédemment, les fichiers de configuration arrivent très rapidement à une taille conséquente et deviennent incompréhensibles.
Parcel.js à la rescousse
Parcel.js reprend les mêmes principes de base que Webpack, c’est-à-dire que l’outil sait gérer beaucoup de ressources différentes (JS, SASS, etc…). Il se charge ensuite de les regrouper pour créer un ou plusieurs gros fichier(s) de bundle.
Un peu d’histoire
Parcel.js a été créé par Devon Govett (travaillant chez Adobe) en décembre 2017 suite aux problèmes de Webpack précédemment vus (énormes fichiers de configuration, problèmes de performances…).
Mais… Parcel.js, ça a quoi de plus ?
Malgré le fait d’avoir la même idée de base que Webpack, Parcel.js va agir avec une philosophie totalement opposée :
Zéro configuration (ou presque) ;
Pas de plugins à ajouter ;
Transformation automatique des modules ;
Code splitting ;
HMR (Hot Module Reload) ;
Tree Shaking (expérimental).
Cela aura pour impact de ne plus avoir de fichier de configuration trop long et incompréhensible, puisque beaucoup de choses sont gérées de base, et sans plugin.
Liste des langages gérables par Parcel.js de base, sans configuration
Durant le talk, une ressource est donnée afin d’avoir une liste d’articles utiles pour apprendre à utiliser Parcel dont voici le lien.
Demo
La suite et fin de la conférence s’est faite avec une démonstration très convaincante de Parcel.js. Je ne vais pas la décrire ici puisque ça n’aurait pas d’intérêt, mais voici la démo en vidéo.
Conclusion
Ce talk m’a permis de voir ou revoir d’anciens bundlers JS que je connaissais, ou non, ce qui a été très intéressant de mon point de vue.
Cela a permis de constater la diversité des outils disponibles, et tous les comparer afin de se faire une idée sur chacun d’entre eux.
Parcel.js est un bundler que je ne connaissais pas avant ce talk, mais celui-ci m’a complètement convaincu de sa souplesse et sa puissance, notamment grâce à la démo qui en a été faite.
N’oubliez pas que vous pouvez retrouver la vidéo de la conférence sur YouTube :
Slickteam