Bonjour à tous, vous êtes sur un nouvel épisode de Double Slash, donc comme d'habitude je
suis Patrick et nous sommes avec Alex, salut Alex !
Salut Patrick, salut à tous !
Donc, on va parler aujourd'hui d'un sujet qui nous tient à coeur puisque on l'utilise
au quotidien en tant que développeur fronte et on va parler des bundler, en fait la nouvelle
génération de bundler, donc c'est des outils qu'on utilise tous au quotidien mais parfois
on ne sait pas vraiment comment ça marche, surtout les nouveaux développeurs on va dire,
je ne sais pas ce qui t'en pense Tom ?
En fait, le truc c'est que ça a vachement évolué sur les dernières années, on est
parti, il y a tout un historique et du coup ce qu'on propose, limite ce qu'on va faire
c'est qu'on va faire un petit historique des bundler, qu'est-ce que c'est, comment
les utilise, par quoi on est passé et surtout qu'est-ce qu'est la nouvelle génération
des bundler et en quoi ça nous facilite la vie nous en tant que dev front, clairement.
Ok, c'est parti !
Yes !
Du coup Patrick c'est quoi un bundler ? C'est quoi le truc ? Qu'est-ce que ça fait en fait ?
Alors, on va partir de pourquoi on utilise un bundler en fait, c'est ça la question,
je ne pourrais pas te dater parce que je ne sais pas, je pense que ça fait à peu près
une dizaine d'années en gros qu'on utilise un bundler, où les premiers bundler sont
apparus, sont apparus, mais avant ça, on avait plusieurs fichiers qu'on importait avec
une, il fallait faire attention à l'ordre d'importation parce que justement tu avais
des dépendances qui venaient d'autres fichiers et la plupart du temps on polluait le scope
global donc on était tous à dans Windows et voilà c'était le bordet en gros, tu avais
des problèmes de variables qui se rentraient dedans, enfin voilà c'était assez compliqué.
Donc la solution c'est quoi ? C'est de découper un module, on découpe un module,
les modules ça fait un scope interne et tu peux utiliser des variables qui ne seront pas
visibles en externe et ça permet en fait en plus de réutiliser le code, d'utiliser des modules
de projet en projet, quand tu fais des fonctions qui font des choses spécifiques, tu les réutilises
d'un autre projet. Donc en gros, pourquoi on avait besoin à un moment donné de très némovable ?
Ok mais en fait si je veux résumer un peu un bundler, en fait c'est que je vais mettre tout mon code
de mon site internet, tous mes assets, mon JavaScript, mon CSS, je vais tout le mettre
en fait dans un seul fichier ou dans un package qui va être mon bundle, mais pour faire ça,
avant je le faisais à la mano et c'était un peu le bordel et maintenant je vais pouvoir le faire
avec des bundlers, c'est ça ? C'est en fait à une sorte de compiler où je vais tout prendre mes assets
et je vais la mettre avec mon site internet. En gros c'est ça, au début tu avais les premiers
bundlers qui faisaient principalement que JavaScript, ils ne s'occupaient pas de CSS tout ça puisqu'on
avait eu évidemment pas toutes ces complications de CSS, c'était beaucoup plus basique le CSS
qu'on faisait à l'époque, mais ouais en gros c'est ça, au début ça prenait que le JavaScript
ça se transformait, c'est à dire ajouter des petites fonctions pour les mettre dans le
navigateur et puis ensuite ça, ça commençait à se complexifier en fait, ça commençait à se
complexifier, le CSS s'est arrivé à mixer dedans, après le HTML puisqu'après on avait aussi
des langages HTML spécifiques comme, comment on s'appelle, moustache, des choses comme ça, tu vois,
des pétignes spécifiques. Voilà, les Twig, Handlebar, tu sais truc là en fait, donc ça commençait
avant à parler après mais ce qu'on pile de plus en plus de choses en fait, après c'est les images,
les icônes enfin et voilà, et c'est devenu de plus en plus complexe et bon on y reviendra après,
mais c'est vrai qu'à un moment donné c'est devenu tellement complexe qu'il y a eu cette fameuse
vague de JavaScript fatigue et bon voilà, on en parlera après mais c'est...
Et donc du coup en fait, je pense qu'aujourd'hui tout le monde connaît Webpack,
c'est le truc on va dire le plus répandu parce que ça a été bien évangélisé, ça a été bien
poussé, néanmoins il y a plein d'autres solutions qui existent aussi et quand on a commencé à vouloir
un peu se structurer et s'organiser, moi je m'en rappelle de Brosify, Boer et du coup
c'est des choses que tu as utilisées toi ? Bien sûr, bien sûr, perso, alors après c'est
une chose qu'on explique bien, il y a des différences entre voilà tout ce qui est...
il y a eu Grunt, enfin il y a eu, ça existe encore, Grunt, Gulp, tout ce qui est Brocoli,
etc, il y en a des dizaines, ce qu'on appelle les Task Runner, donc ils vont exécuter,
tu fais un fichier avec des... alors tu lui dis tu fais ça, tu prends un fichier JS, tu transportes
un machin avec tel plugin, etc, ça c'est des Task Runner et il faut pas les confondre en fait avec
les bundlers, c'est pas du tout la même chose, un bundler il te prend un fichier d'entrée qui va être
app.js par exemple ou index.js et ensuite il va prendre tout ce qui est dépendant à ce fichier
et il va te le concaténer, il va te modifier, enfin voilà en fonction de ce que tu l'as mis comme
fanfile. Donc il y a deux choses déjà bien faire attention, les Task Runner sont pas du tout
pareil que le Bundler et aujourd'hui c'est vrai que comme tu dis Webpack tout ça c'est le plus utilisé
et enfin il y a encore des gens qui utilisent du Gulp ou des choses comme ça mais c'est vrai que
Webpack ou Parcel par exemple se sont largement imposés et ouais voilà, enfin comme tout le monde
j'ai utilisé différents bundlers et donc les Task Runner en fait un exemple ça serait je
prends toutes mes images et je viens dégrader la qualité et je la mets, je prends toutes mes images
et je les mets en 1024 par exemple par 800, c'est mon choix parce que c'est pertinent,
j'en sais rien mais on va dire c'est une tâche et ça je vais lui donner cette tâche à Gulp ou à
Grunt et lui il va exécuter ces tâches là, une fois que j'ai récupéré tous ces fichiers là
je vais les injecter dans mon site internet via en fait mon bundler qui va en fait prendre ces images
là, les injecter dans le CSS, prendre le JS et faire une espèce de petite tambouille pour que ça soit
production ready pour que sur internet ça soit facile et interprétable sinon.
Ouais c'est ça, les bundlers en fait ils te fabriquent un fichier final en fait
qui va être utilisé par navigateur et qui va être compatible avec ton navigateur.
Donc ça peut prendre différentes sources, si je prends l'exemple de Webpack c'est souvent
identifié par l'extension, ça va être JS, CSS, SaaS ou ce que tu veux et ça à partir de cette
extension qui va définir le loader, qui va transformer le fichier, la source et la rendre
browser compatible. Ok donc pour tous les langages de CSS qui sont précompilés,
type SaaS ou... Lesse. Ouais lesse voilà.
Qu'on utilise pour moi. Et ouais qu'on utilise de moins en moins,
pour le coup c'était déjà écrit avec leur nom mais en fait eux ils vont prendre le CSS,
le SaaS et ils vont le transformer en CSS pour que mon navigateur puisse interpréter le truc.
Ok et en termes de perte aussi c'est aussi le rôle de Webpack ou d'autres
bundlers justement de venir m'imifier, concaténer, vraiment optimiser le poids et en
termes de performance c'est eux aussi qui vont essayer de réduire le poids, compresser
le fichier de sortie pour que ce soit le plus léger possible.
Ouais tout à fait en fait au départ de Webpack, alors je prends l'exemple de Webpack parce que
c'est vraiment le plus utilisé, le plus répandu au départ de Webpack et c'est un peu
encore le cas aujourd'hui parce que Webpack a toujours besoin de le configurer. C'est toi qui
va définir dans un fichier de config ce qu'il doit faire. En fait c'est à toi la responsabilité
de lui dire le fichier. Tu vas quand même le concaténer, tu vas le réduire en taille,
tu vas l'optimiser etc. Il ne le fait pas forcément automatiquement Webpack. Après on va le voir
après, enfin on va le voir pour la suite. Maintenant on a des nouvelles générations de
leurs qui font ça automatiquement. Ok et pareil ils vont aussi faire tout ce qui est chunk
où ils vont découper le JS, enfin je vois par exemple sur les prémoirs modernes, on va découper
le JS pour que quand j'arrive sur la page login, je ne vienne pas charger tout le JavaScript de
toute mon application mais que je charge que la page de login puis j'arrive sur la page de
mon dashboard. Je récupère le JS uniquement de mon dashboard, ça c'est ce qu'on appelle le chunk,
on va découper et ça aussi c'est la responsabilité de Webpack ou c'est la responsabilité du
developer de bien faire ses imports un peu malin. Webpack c'est ça, c'est toujours la responsabilité
du developer. Webpack a offert cette possibilité, je ne sais plus à quelle version, 2, 3, plutôt la
3 je crois et c'était à toi de faire l'import d'une façon qui chunk le fichier et qui justement
comme tu dis, qui ne te charge pas un énorme bundle JS au chargement de l'application parce qu'il
faut savoir que en fait quand le navigateur va charger un fichier JS il va le parser, il va
aller le lire, plus ce fichier JS est lourd, plus il est gros et plus le parser prend du temps,
le parser ça prend du temps et c'est à ce moment là que le browser des fois quand on va visiter
un site on a un ralentissement au niveau du site la première visite et c'est pour ça qu'on va
chunker, on va séparer en plusieurs fichiers pour éviter d'avoir des gros fichiers et Webpack
a offert cette possibilité là et après c'est à toi vraiment d'utiliser les imports correctement
pour dire à celui là tu ne me sépars, celui là tu me sépars mais il ne le fait pas automatiquement
Ok donc c'est une option que moi je dois bien configurer pour ça correctement
En fait aujourd'hui quand on utilise on commence à être mal habitué en tant que dev parce que
quand tu utilises Next, tout les choses comme ça ou Next, ça le fait automatiquement, ça va séparer
Ouais mais moi c'est quand même vachement bien quoi, j'ai pas besoin de m'en offrir, oui on
devient façon on est dev, on est définir mais en fait avec les Next ou les Next quand tu fais
des pages en fait, celui automatiquement il va séparer, il va chunker en fonction des pages
mais si tu utilises Webpack dans un projet voilà que tu as, configurer toi-même
il va pas le faire automatiquement, ça a toi de configurer le truc
Après utiliser la magie c'est bien comprendre la magie c'est mieux
et c'est toujours intéressant de comprendre le truc
Ok ok je comprends un peu mieux
Après ce qui est en fait Webpack il y a un peu de Tueil Match on pourrait dire
mais avant Webpack il y avait quoi c'était Brosify, Bower tout ça
Ouais alors l'historique, il y en a eu beaucoup avec des projets qui sont mort
Alors cela là la liste c'est on peut dire qu'ils sont encore existants
Brosify il est encore existant et il est encore utilisé, il a évolué
il y a des plugins tout ça qui existe, ça date de 2011 en fait
et lui sa première fonction de Brosify en fait c'était de juste pouvoir utiliser
et Require et les modules export
Tu vois le système de Node.js, Require tu vas appeler un module
tu vas exporter aussi un module, ça c'est pas compatible dans le navigateur
ça il sait pas ce que c'est le navigateur donc en fait la possibilité de Brosify
t'apportais cette possibilité justement de découper un module et de pouvoir utiliser ça
il te faisait un bundle et hop ça marchait dans le navigateur et ça c'était déjà une bonne avancée
Excellent et après il y a eu Brunch qui existe encore je crois
Ouais Brunch c'est alors moi j'avais utilisé, je pense que c'est mon premier bundleur que j'ai utilisé
il existe encore, il est encore évolué et c'est quelque chose qui marche très très bien
et je pense qu'il est moins connu que Webpack par exemple
mais par contre il est vraiment top Brunch parce qu'il nécessite très peu de configuration
et il arrive tout seul à détecter les fichiers, à les compilés etc
Brunch pour ceux qui ne connaissent pas je vous recommande d'aller jeter un coup d'oeil
mais c'était pas mal du tout à l'époque ça date un petit peu aussi mais ouais c'est pas mal
Après on a eu la génération Webpack qui est quand même
qui est portée par un mec de chez Microsoft il me semble
A l'époque je connais
A l'époque il était pas chez Microsoft
Je crois qu'il était indépendant à l'époque
Comment il s'appelle ?
D'accord, j'ai oublié son nom
Oui moi aussi
Ah bon, qu'importe, toujours est-il que en fait
je pense qu'il a été assez vite adopté
par contre j'ai pas trop compris en fait pourquoi il a été adopté
et qu'est ce qui a fait le succès de Webpack
parce que clairement c'était quand même une usine à gaz à configurer quoi
C'était quand même hyper, ça reste toujours compliqué je trouve
Alors ça nous permet d'avoir un niveau de granularité hyper précis
de pouvoir vraiment contrôler notre bundle de sortie
par contre ouais c'est un enfer à configurer quoi, vraiment compliqué
et néanmoins c'est lui qui s'est quand même plus imposé aujourd'hui
On va dire dans toutes les stacks modernes
la plupart c'est Webpack qui est installé
Non ?
Ouais, la plupart des projets, enfin aujourd'hui et ça en train de changer
utilise Webpack
et ouais comme tu dis Webpack c'est alors
moi j'ai utilisé la première version de Webpack
la 2 je crois, j'ai commencé et franchement ça a beaucoup beaucoup beaucoup évolué
et c'est beaucoup plus simple aujourd'hui
mais à l'époque c'était une vraie année
mais aujourd'hui encore il y a quand même pas mal de
alors heureusement comme je te disais tout à l'heure
il y a des produits comme NUX, MEX ou d'autres produits
la Vucie et la Il y a des choses comme ça qui font tout automatiquement
qui font tout configurer automatiquement et toi tu touches plus du tout la config de Webpack
et pour ceux qui ont déjà tenté d'éjecter une config Webpack
on peut voir que c'est très complexe
des trucs comme la Vucie et la Il y a des choses comme ça
on peut voir que c'est extrêmement complexe
si on éjecte et qu'on essaie de configurer ça même
en fait Webpack il y a des gens qui veulent pas mettre les mains dedans
au niveau de la config
moi je les comprends
parce que moi je fais partie de ces gens là
moi je peux rentrer dans Webpack mais je me porte
ah oui c'est clair
c'est clair surtout qu'aujourd'hui on peut dire qu'on est
honnêtement tous les projets se ressemblent
et on fait à peu près toujours la même chose
surtout que enfin là on a un peu standardisé les produits
les outils en fait
style CSS, CSS, GIS la plupart du temps tu utilises du Babel
enfin voilà c'est à peu près toujours la même chose
on a des images, on a des IPOs, des SVG, des choses comme ça
donc finalement là petit à petit les projets se ressemblent de plus en plus
ça c'est un petit peu standardisé
il y a de moins en moins de trucs exotiques
et les configs sont près de sur les mêmes
et puis les standarts se sont stabilisés aussi
ouais c'est ça
qu'est ce qu'on attend en termes de navigateurs
parce que depuis tout à l'heure on parle des bundlers
mais c'est parce qu'on est quand même limité par notre navigateur
qui pendant des années n'a pas trop évolué
et aujourd'hui avec Chrome, Chromium et toutes les navigateurs
dits modernes donc Chrome et Edge, Firefox
aujourd'hui ils acceptent de plus en plus de JavaScript
et ils sont surtout mis à jour de plus en plus facilement
et ceux de manière automatique
ce qui nous permet en fait d'avoir des taux d'adoption
sur des nouvelles fonctionnalités assez rapides
et pouvoir le pousser en prod assez facilement
et pas être limité par justement des fonctionnalités JavaScript
qui sont natives dans le langage
mais qu'on ne peut pas utiliser parce qu'ils ne sont pas compatibles
avec les navigateurs actuels
et donc merci, ça amène d'autres problèmes
mais les Chrome et Google et Chromium et Edge
et toute cette standardisation qui nous a facilité la vie
ça amène d'autres problèmes
Attention parce que ça va pas faire plaisir à tout le monde
Bien sûr, c'est pour ça que je parle de d'autres problèmes
Oui, des d'avoueux sur la suprématie de Chrome en ce moment
et de la façon dont ils imposent certains standards etc
on se retrouve un petit peu avec les mêmes problèmes
qu'à l'époque avec Internet Explorer
ou c'est eux qui font la messe
C'est eux qui font la messe et qui imposent un peu leurs standards
et que ils ne s'attendent pas les autres
Enfin bref, ça pourrait faire un épisode complet là-dessus
C'est un autre truc
Oui, c'est ça
Heureusement aujourd'hui, disons que les nouveaux développeurs
les juniors, tout ça qui arrive aujourd'hui
je l'ai déjà dit dans plusieurs épisodes
mais il se rend un peu vieux quand je dis ça
Ok, boomer
mais c'est vraiment plus simple aujourd'hui, ça c'est clair
les navigateurs ont fait des normes progrès
les outils de frontes ont fait des normes progrès
C'est quand même super easy aujourd'hui de faire des projets
de stress avec du NUX
mais vraiment
en 2014, 2013, 2015, c'était encore une autre histoire
Mais tant mieux
pour reprendre un peu l'histoire
il y a quand même des choses qui ont été vachement plus faciles
moi quand j'ai découvert Parcell, Parcell.js
tout de suite c'était...
c'est une tuerie
Wow, c'est un bonheur, c'est tout facile
c'est tout facile à utiliser
et ça pour le coup
ça a été une grosse révolution
parce que ça venait d'égager toute la partie config
En fait Parcell, c'est un peu une réponse
à Webpack, en gros
comme je te disais Webpack, c'est compliqué à configurer
moi j'aime bien configurer Webpack
et je peux te dire que sur certains projets
j'ai déjà passé des demi-journées
voire des journées à configurer
exactement comme je voulais Webpack
faire le Dev Server, etc
la config qui te fait faire la production comme tu veux
et tu peux passer vraiment du temps
et ça ça a vraiment provoqué
ce qu'on appelait le javascript fatigue
c'est à dire que les mecs ils en avaient marre
et ça m'est arrivé aussi
de passer du temps, des heures
à configurer tes outils
tu travailles même pas sur le projet
tu as même pas commencé à travailler sur le projet
tu configures tes outils et ça te prend déjà des heures
et là à un moment donné
il y a eu un javascript fatigue
et en gros Parcell c'est un peu une réponse à ça
Parcell c'est un projet
qui fait halluciner tout le monde
la première fois que tu le utilises
parce que tu l'installes
et en fait t'as rien à configurer
ça marche
et ça c'est magique
mais moi j'adore ça
j'adore ça
et pour le coup c'est vraiment un truc qui me soule
de faire de la config avant de bosser
moi ce que je veux bosser
c'est faire ma fonctionnalité
jouer dans ma page
pour pouvoir avancer
mettre mes champs
mettre quand je clique là il se passe ça
que là en fait c'est de la pure config
et c'est hyper ingrat
c'est hyper ingrat
et puis encore plus quand tu fais
ne serait-ce qu'une mise à jour
tu passes de Wattpack 4
à Wattpack 5
enfin tu dois recommencer tes config
tu pète un câble
et après elle va expliquer à ton client
j'ai passé une demi journée
à faire la config
ouais
t'as sorti quoi comme picture
c'est quoi les nouvelles fonctionnalités
non non mais en fait c'est pour le futur
non non
moi je paye pas ça
et ouais c'est compliqué
donc parcelles

contrairement ouais on va quand même
expliquer parcelles contrairement aux autres
à Wattpack par exemple
t'as 0 config de base
enfin en tout cas la 1
la première version
t'as 0 config de base
c'est à dire que tu
de souvenir tu fais un html
tu vas importer
un fichier CSS dedans
et un fichier JavaScript
et ensuite la ligne de commande
je sais plus que c'était parcelles
parcelles CLI
et tu lui disais index.html
et lui automatiquement
il va détecter un CSS qui est un JS
et il va aller les chercher
et il va aller compiler
et je crois qu'il remontait tout
c'est à dire ok là je vois que c'est du SAS
bon bah du SAS il faut que je le compile
il avait cherché la dépendance
en fait le compiler de SAS
si tu as du vue
il avait cherché le vue
il avait cherché toutes les brésiliers
qui correspondaient à ton projet
tu avais rien à faire
tu le voyais, tu allais charger les trucs
donc ça c'est pas bon
truc de fainé
c'est un plaid
après ça
je veux dire
Wattpack parcelles
c'est quand même
gravité
c'était un gros standard
par contre maintenant
on voit sortir
ce que moi j'appelle
la nouvelle génération de bundler
et c'est ce qui
y a fait aussi
qu'on fait cet épisode
c'est
surtout
tous les nouveaux
qui utilisent ESM
et on va définir ce que c'est
mais je parle de snowpack
de rollup
et de vite
mais
qu'est ce qui vient différer
de cette nouvelle génération
et de la précédente
c'est l'évolution
de la navigation
tout simplement
rollup
il est pas tellement différent de Wattpack
il ressemble même pas au Wattpack
parce que tu as aussi de la config à faire
par contre il était un petit peu plus
rollup en fait
c'est un petit peu changé
mais il t'a conseillé
par exemple si tu fais un package NPM
que tu vas distribuer
voilà on a une source
rollup c'est l'outil idéal
pour pouvoir télécharger une dépendance
et la note de nom
rollup on peut pas
même s'il est utilisé dans cette nouvelle génération
dans le vite
rollup il est à peu près
équivalent à Wattpack
mais bon
voilà
et donc en fait
je parle de Snowpack
voilà Snowpack
oui Snowpack
et en fait eux la grosse
la grosse nouveauté
c'est qu'ils utilisent
les ES modules
donc
ECMAScript
truc que je n'arrive pas à dire
ESM
on dira ESM pour le récent de l'épisode
et eux en fait ils utilisent
cette nouvelle
fonctionnalité qu'on a maintenant
dans les natigateurs
c'est un nouveau standard
et en plus je crois qu'il y a un taux d'adoption
si on fait un petit tour
sur Kenaiuse
je crois que ESM
et c'est 92%
en fonction des pays
ESM
si vous allez sur keneius.com
ils vont regarder
les ESM
ouais c'est 92% des brosers
dans le monde après
je ne suis pas regardé pour la France exactement
mais en gros tous les navigateurs modernes
l'utile
enfin le support
bon après ça dépend du projet
ça dépend de vos clients etc. la cible etc.
c'est toujours pareil
mais ouais dans l'ensemble là on peut dire qu'on
peut déjà assurer
en gros je ne sais pas si t'en penses mais on peut dire que si tu lances un projet
ou tu destines
à
des navigateurs
tes clients, tes cibles sont
la plupart équipés de Chrome etc.
normalement ça tourne pas
tu peux y aller
tu peux y aller direct après si tu as
un cible qui est plus
business
dans les entreprises des choses comme ça
ou potentiellement
ils auront peut-être de l'internet explore
parce que le parc n'a pas été mis à jour
là c'est un peu complexe
mais
la grosse révolution
avec ces bundles
c'est qu'en fait
on n'a plus
en dev en fait
c'est instantané
avant dans webpack
on était oubliés sur chaque modification
il y avait un espèce de watcher
qui regardait ok tu as modifié le fichier
login.js
alors je vais
rebundler, je reprend tout
je rebundle
et je te mets à jour ton navigateur
ce qui fait qu'il y avait un temps de compulation
qui était juste hallucinant
et
en fait à chaque action
je rajoute un point virgule
je relance la machine
que là en fait avec usm
chaque fichier
est décomposé
si on est un bon développeur
et on a
séparé nos fichiers
mais sinon on ne tient pas
on ne tient pas
tout le bénéfice
des modules
mais là ce qui est super cool c'est que si je modifie
mon login.js
ou vu
gsx ou whatever
en fait c'est que ce fichier
qui va être mis à jour dans mon navigateur
donc c'est
40.000 secondes
c'est juste ultra
ultra rapide
et c'est ça qui fait la grosse
grosse différence non ?
ben ouais c'est ça
en fait
en gros
on va quand même rendre
les honneurs
je pense que c'est snowpack qui est un petit peu ouvert la voie là-dessus
d'accord
je pense que c'est snowpack qui a vraiment
fait voir que c'était possible d'utiliser usm
ça arrivait qu'on pouvait l'utiliser en mode de l'aide etc
c'était un peu
c'est un peu ce qui a fait la suite
en fait comme vite qui est pas vite
il est assez récent il n'a même pas un an
je crois
et vite a suivi
et puis après voilà ça évolue
ouais c'est exactement ça
en fait
je vais quand même faire un petit rappel
sur le système de module rapidement
pour comprendre en fait ce que c'est usm
donc comme on disait
au début c'était
en fait le système qui est common.js
alors common.js
c'est ce qu'on utilise dans le mode depuis toujours
c'est ce qu'on utilisé dans Rosaryfile
et aussi enfin ce que faisaient vos Rosaryfile
c'était les req-wire
et aussi les modules export
le module tu dis req-wire
après tu dis telle module réacte par exemple
et il va te l'importer et tu peux faire tes modules
tu vas faire un module export avec tes fonctions
que tu vas définir et il va t'exporter des modules
donc ça c'est le module common.js
ensuite il y en a deux autres qui sont un peu moins connues
alors AMD je passe rapidement dessus
il est
enfin je sais même pas s'il est beaucoup utilisé celui-là
c'est Pinsynchronous module definition
et UMD
UMD c'est
Universal module definition alors UMD
nous en tant que dev on ne l'utilise pas tellement
par contre
si tu vas voir le code source de webpack
et de rollup tu verras qu'il est utilisé en fait
si tu vas analyser un petit peu le bundle
tu verras comment eux
comment eux en fait ils utilisent
comment ils compilent un peu les dépendances tout ça
c'est avec UMD en fait
tu te regarde vraiment en détail
et comme tu disais ESM
alors ESM qu'est ce que c'est
donc McMastrick module
c'est tout simplement
ce qu'on utilise depuis toujours dans webpack
mais qui n'était pas disponible dans les browser comme tu dis
c'est import et export en fait
quand tu fais import, form, react
et export, tu sais que tu fais machin
bah ça c'est simplement ça en fait
mais ça n'existait pas dans les browser
donc on l'utilise
c'était pas implémenté
c'est pas implémenté en fait
et en fait on l'utilise
quand on fait des applications on l'utilise
quand tu fais tes applications vues n'importe
tu es import, tu export, tu sais tout ça
mais ensuite webpack lui il transformait ça
c'était pas du tout le lui par le browser
il le transforme, il te fait ton bundle
donc c'était pas interprétable
de manière native alors que maintenant
en fait la nouvelle génération
92% de browser aujourd'hui
ça veut dire import et export
voilà
et donc ça change notre manière
de faire du dev
parce que, enfin non ça change la manière
de compiler notre application
parce que
il y a des, le navigateur
bah les fixés sont c'est pareil
ce qu'on écrit
et puis alors
oui on va faire
notre bundle pour
pour la prod après moi
ce que je trouve super intéressant c'est
en tant que développeur
expérience quand je suis
sur mon projet
je suis en train de développer
là c'est monstre
monstre rapide, j'ai l'impression
d'avoir un truc
c'est ultra rapide
et c'est vraiment sympa
et en fait tu te rends compte que bah t'attendais
quand tu fais la somme
de seconde que t'as attendu
que ton bundle
se fasse
ou juste que tu recharges
ok tu refais
t'as fait ton code
tu t'attends le résultat, tu test ton résultat
non c'est pas bon je le refais
et en fait bah là tu te rends compte que
tu gagnes vraiment du temps
et c'est ultra ultra ultra rapide
ouais bah en fait
maintenant on va parler principalement de VIT
mais en fait
la première fois que tu, enfin je sais pas si ça t'a fait pareil
mais la première fois que j'ai utilisé VIT
en fait j'ai lancé
j'ai utilisé avec VIT 3 je crois
j'ai lancé
et c'était tellement rapide
ça marche pas en fait non ?
qu'est ce qui se passe ?
Wattrung, attend il s'est rien passé
mais en fait non c'était déjà compilé
c'est
exactement ça
et là tu fais ah ouais
d'accord et après tu commences à faire tes modifs
et là tu fais mais non
mais non mais c'est pas vrai
il y a vraiment un effet wow
ouais c'est tellement VIT
et il porte très très bien son nom
que la première fois que tu l'utilises
t'as luci
t'as les fait wow ou tu fais c'est pas possible
et qu'après en fait
quand tu retournes sur un projet qui utilise du voie de pack
c'est là ou tu le dis ?
c'est lanc
alors qu'avant
ça te semblait pas super long
et puis là d'un coup tu fais mais c'est hyper lanc en fait
mais de toute façon c'est comme ça pour tout en fait
avant on avait
des 56K pour des modems
après on est passé à la DSL
après à Numérys à machin
et maintenant quand tu as la fibre et machin
et quand tu reviens
sur ta génération précédente
tu fais
wow mais c'est lanc
c'est lanc mais c'est insupportable
mais parce que voilà on est habitué
et on prend
sans doute des mauvaises habitudes
mais clairement
oui ça va pour le coup ça va vraiment vite
pourquoi le nom français
ça fait une recherche là-dessus ?
oui
en fait c'est très simple
ce qu'il faut comprendre c'est que le mec qui est derrière
vite c'est Evan Yu
qui est le fondateur
de vue
qui
à mon avis doit nourrir
un amour secret pour la langue française
parce que
il a appelé son...
déjà vu à la base c'est français
déjà le mot vu c'est français
vite
c'est français aussi
il explique
en français
vite c'est fast
donc voilà tout est dit
donc non pour le coup
c'est vraiment bien
après
j'avais peur que le projet
s'orientent vraiment que sur vue
mais en fait pas du tout
et je pense que c'est super malin
de la part
du créateur
d'avoir vraiment
hyper ouvert
et d'avoir fait quelque chose
de vraiment framework
agnostique
ou pour le coup
vite
tu peux l'utiliser avec React, avec vue, avec Svelte
avec tout
avec tout et pour le coup
en fait
ouais tu utilises
t'utilises ta stack
que t'as l'habitude d'utiliser en termes
de framework.js
et tu viens juste brancher
ton bonheur et tu profites
en fait de ton instantanément
de l'expérience de dev
voilà
c'est super facile
après tu peux venir l'améliorer
avec des systèmes de plugin
aussi
mais mine de rien
c'est hyper facile
on est quand même bien loin
de la configuration
que Webpack pouvait offrir avant
en fait on est
il prenne l'exemple souvent de Parcell
en fait
parce qu'il n'y a pas de config de base
et comme tu dis
on en parlait
hier pourquoi
il y a plusieurs
Benleur qui existent
pourquoi vite aujourd'hui
parce que je veux dire que ce n'est pas qu'il existe
depuis un petit moment
ça fait un an ou deux ans
et pourquoi vite d'un coup il perce comme ça
vite tout le monde en parle
tu vois plein de vidéos dessus
ça a l'air d'être vraiment tendance
ça buzz quoi
il y a la communauté vue derrière etc
et Vanu aussi qui est très fort
mais pourquoi alors il faut savoir que vite
ils ont un peu du mal à le prononcer les américains
pour une fois c'est pas moi qui ai du mal à prononcer en anglais
c'est eux qui ont du mal à prononcer en français
ils ne savent pas du tout
ça fait du tout comme le prononcer
c'est très drôle
c'est très drôle
en fait vite il faut le voir un peu comme parcelle
donc il fait
énormément de choses
out of the box
il est capable de compilier du css
des images, des images, tout ce que tu veux en fait
et ça déjà c'est ça
très grande force
donc c'est top
en plus d'être rapide
il fait plein de choses sans rien faire
et comme tu dis
framework agnostic
ce qui fait que, et ça c'est très malin
parce que ça veut dire
qu'il va être vite
adopté par les autres communautés
que vue en fait
ça m'étonnerait pas rapidement
on le voit apparaître dans next.js
par exemple
nukes normalement ils vont l'implementer
dans la version 3
enfin on va vite voir
vite pour la peine
on va vite le voir implémenter
dans d'autres choses que du vue
c'est ça je pense c'est très intelligent d'avoir fait ça
par contre est-ce que tu peux l'utiliser
par exemple
sur ta production
ou pour le coup il faut que
tu aies une sorte de rétro compatibilité
parce que ton client fait
que voilà
est-ce que tu peux
l'utiliser
pour faire ton bonheur de production
pour expliquer comment il fonctionne vite
comme tu le disais
en mode dev
il utilise les osm
donc avec ma strip
je n'arrive pas à le dire non plus
avec ma strip
les import export
directement de la page html
par contre ce qu'il fait lui
il a fait une conf
en fait Evan il a fait une conf
les dernières je ne sais plus après l'été
quand il commençait à vraiment
parler de vie
il a expliqué comment ça fonctionne
il expliquait qu'il pouvait y avoir
des problèmes en utilisant les osm
par exemple
quand tu as des dépendances avec npm
tu vas mettre des packages
on réacte vu ce que tu veux
après tu as d'autres dépendances
tu vas mettre Axios
et après tu as des dépendances de dépendance
et il y a un gros risque avec ce système là
c'est qu'à un moment donné tu vas te retrouver
avec des milliers de téléchargements
il va y avoir un waterfall qui sera hyper long
et ça c'était un gros souci
quand il commençait à travailler dessus
donc ce qu'ils ont fait
et c'est plutôt intelligence
ils ont dévisé en deux modules
en fait en mode dev
toutes les dépendances
tout ce qui est librairie vu
il va faire une sorte de bundle
ça il va le prébundle
donc il va faire un fichier
de toutes les dépendances
pourquoi ? parce que ça ça change très peu
à part que quand tu installes une nouvelle dépendance
il va rebundler
mais sinon ça change très peu pendant que tu codes
ton application
et ensuite tout ce qui est code source
ça marche avec usn
donc ça va partir
d'une balise script
avec le module
où tu vas faire un import
app.js par exemple
et tu vas
initier ton application
et à partir de cet import
il va aller chercher tous les autres imports
voilà
et comme tu dis à chaque fois que tu vas modifier
un fichier de ton code source
de ton application
il va changer que ce fichier
il va pas changer tout ton application
et c'est là où c'est hyper rapide
excellent
c'est ultra ultra rapide
et après question initiale
c'était ce qu'on utilise en prod
parce que j'ai fait coup
oui
donc pour l'instant
en prod
vite, n'utilise pas les ESM
enfin n'utilise pas les modules
il fait comme ou pas qu'il fait un bundle
pour l'instant
mais c'est lui qui le fait
ou tu dois faire appel à un autre
non c'est lui qui le fait
tu n'as rien à configurer
aujourd'hui il utilise rollup
pour faire le bundle de prod
ça va changer normalement
il va utiliser usbuild
usbuild dans quelques temps
alors il estime
il estime bien sur la page de vite
aujourd'hui usbuild est encore un peu jeune
et il manque encore des choses
pour je ne sais plus exactement
le chunk
il manque encore quelques
tu fichiers en prod
on peut utiliser en prod
donc pour l'instant c'est rollup
il va faire un bundle
comme webpack
que tu vas apporter
en fichiers GGS
donc
aujourd'hui pas d'esm
en prod mais ça viendra
le projet va évoluer
dès que on est à 92%
peut-être que quand on sera à 95%
il va dire aujourd'hui c'est bon
on peut y aller
après il y a peut-être aussi
quand usbuild sera un peu plus avancé
bon bah là il pourra
en fait
c'est pas gênant
on peut déjà utiliser
vite là tout de suite maintenant
et on fait un bundle
on va dire classique
pour la prod mais on profite
de toutes l'expérience de dev
instantanément
tout de suite
on va dire à quel moment on peut
implémenter
cette nouvelle génération de bundler
bah
demain tout de suite
là je peux l'utiliser
enfin moi je recommande de l'utiliser
clairement
et puis en plus il va évoluer
donc non non
aujourd'hui si quelqu'un se pose
la question est-ce que je peux utiliser en prod
et je me suis posé la question il y a 2 mois
bah oui
tu peux l'utiliser en prod
peu
ça fonctionne
très bien même et très rare
et c'est là comme tu dis
au quotidien quand tu deves
en fait
quand tu passais une journée de dev à faire une application
c'est vrai que malgré tout
ces petites secondes
que tu gagnes à chaque recompile
ça fait beaucoup
à la fin de la journée
ouais ouais et à la fin de la semaine
et tout ça
bien sûr et après
encore plus si t'as une machine
qui n'est pas super performante
tu vois ça c'est aussi un truc
c'est une question
que je me pose depuis quelques mois
parce que je me rends compte
que pour le dev
enfin je sais pas de toi
moi quand j'ai commencé le dev
j'avais un ordinateur
mais il était pas super puissant
c'était un modèle premier prix
même les mac premiers
premier prix
je l'ai appelé
c'est premier bien
c'était macbook je sais plus quoi
et ça faisait le job
et aujourd'hui
quand tu réfléchis depuis quelques années
on a besoin de plus en plus de puissance
quand on met 16 gigarames
et ça fait plusieurs mois
je me dis mais c'est pas normal
quand on fait des applications web
il y en a besoin d'avoir des ordinateurs hyper puissants
il y a quand même un truc qui va pas
en fait moi je le vois
à chaque fois que je bosse
à côté d'un collègue
et pour le coup qu'il y a une machine
moins puissante et il fait un NPM
install
et là il décolle
mais ça prend 20 ans
parce que son disque dur
il tourne
enfin c'est pas du SSD parce qu'il a pas de RAM
parce que ça prend 20 ans
et alors qu'on est sur la même connexion
donc il y a même pas cette
différence de vitesse de connexion
juste
sur la machine on a la même connexion
je fais un NPMI
lui il va prendre un café
il revient tranquille
sérieux ?
oui non c'est hallucinant
et je lui dis là mon pote
je crois qu'il est temps de passer
il est temps d'investir
oui mais là c'est pas normal
c'est un temps plus que de travailler
alors est-ce que VIT va régler ce problème
je sais pas est-ce que ça demande peut-être
moins de ressources quand il va en devre
je sais même pas
si il y a des benchmarks
et puis est-ce que vraiment
c'est significatif
ça peut être pas mal quand même
juste sur VIT
si parce que si
qu'on pile pas tout le fichier tout ça
de dépendance tout ça je sais pas
à ce niveau aujourd'hui je trouve qu'il y a
un petit souci
de devoir avoir des machines hyper puissantes
pour faire des devs web
mais il faut bien que
les producteurs de machines
revendent des machines
c'est pas trique
enfin
excellent tout ça
et bah
moi je pense qu'on a bien parlé
un peu de tous les bundlers
de toute la nouvelle génération
et je pense qu'il faut au-delà
d'en parler et d'écouter
je pense qu'il faut aussi tester
parce que c'est
le côté un peu magique
il est surtout
quand tu test
quoi
et pour le coup
on peut même aller
sur les sites de VIT
ils ont un discord
le site est bien fait
t'as la possibilité d'avoir
un get started immédiat
où tu peux jouer avec tout de suite
et être super
la vue si elle est là
il te propose l'option aujourd'hui vite
si tu choisis VIT 3
je crois que tu te propose aussi
pour le sens
ouais après je pense aussi
pour les devs qui
qui font pas vue mais qui veulent
autre chose mais qui veulent quand même
tester VIT il y a possibilité
et il y a des starter kit
qu'on fleurit
partout de manière officielle
sur le site ou sur GitHub
starter kit VIT plus
ce que tu veux
il y a moyen de trouver un peu
ton bonheur
donc c'est plutôt cool
yep
mais bah parfait
écoute un grand merci Patrick
merci à tout le monde
d'avoir écouté
l'épisode jusqu'au bout
et puis bah
pensez à nous mettre un petit pouce
un petit like, un petit commentaire
ça fait toujours plaisir
on vous dit à bientôt
ciao ciao
on va pas trouver Double Slash sur le plateforme de podcast préféré
et sur le site internet du podcast
www.flash-podcast.fr
sur le site vous allez retrouver
tous les viendres épisodes, des références
évoquées durant l'émission