Bonjour à tous, je suis Alex et je suis très heureux de vous retrouver dans ce nouvel épisode
de Double Slash, nous sommes le 3 novembre 2020 et on est sur l'épisode numéro 15.
Comme d'habitude, je suis avec Patrick.
Salut Patrick.
Salut Alex.
Salut à tous.
Et du coup, vous pouvez nous soutenir directement en nous laissant un petit commentaire comme
d'habitude sur votre lecteur, player habituel, donc Spotify, iTunes, tout ça.
Ça va nous aider en fait à remonter dans les classements.
On vous remercie.
On passe directement au sujet et de quoi on va parler Patrick aujourd'hui.
Alors aujourd'hui, on va faire un épisode un petit peu spéciale news et notamment sur
les dernières sorties sur octobre.
On a eu quelques releases qui sont sorties sur Webpack, sur React, sur Next.
Donc on va parler un petit peu de tout ça et notamment un article intéressant sur les
générateurs de cistatik, une petite comparaison de vitesse de construction.
Donc on va revenir dessus.
Un petit benchmark.
Oui, un petit benchmark.
Oui, exactement.
Voilà, voilà.
Excellent.
Excellent.
Et bon, on attaque direct.
Une nouvelle version de Webpack, Webpack 5.
Donc Webpack 5 est sortie le 10 octobre.
Donc pour rappel, la version 4, elle date de février 2018.
Donc ça commence à data un petit peu, même s'il y a eu quand même des avancées, des
corrections et des releases entre temps, mais des petites releases.
Donc pour revenir sur Webpack 5, les avancées majeures de cette nouvelle version.
Donc ils annoncent un temps de build beaucoup plus rapide, car aujourd'hui ils ont rajouté
un système de cache persistent.
Donc au niveau du dev, ça va être beaucoup plus intéressant puisque c'est le reproche
qu'on fait souvent à Webpack d'être un petit peu lent au niveau de la compilation
et surtout quand vous vous codez en local sur la machine.
Donc aujourd'hui, on a un petit système de cache persistent qui va vraiment améliorer
les choses.
Donc là, c'est vraiment l'avancée majeure de Webpack 5.
Et ensuite, il y a d'autres petites avancées, comme ils annoncent aussi des bundles un
petit peu plus petits au niveau du poids.
Ils ont amélioré le tree-shaking.
Alors le tree-shaking, c'est quand ils vont éliminer du code qui ne sert à rien
en fait dans votre compilation, du code qui n'est pas utilisé.
Et donc tout ça, il va aller un petit peu plus loin dans l'élimination et il va vous
alléger beaucoup plus les bundles, le bundle final.
Et après, il y a d'autres petites choses, mais la chose qui m'intéressait, enfin qui
est assez, je suis assez curieux de savoir ce que c'est, ils annoncent un module fédération.
Donc ça serait entre différentes compilations, entre différentes builds.
Il serait capable de communiquer ensemble, c'est-à-dire qu'un build serait capable
de charger dynamiquement un autre build.
Donc je ne vois pas vraiment comment ça va fonctionner.
Mais ça semble intéressant à voir.
En tout cas, ça permet d'alléger encore plus les bundles au final et de pouvoir appeler
des fonctions qui sont utiles à un moment donné, si c'est utile.
Et donc question importante, est-ce qu'aujourd'hui, si vous utilisez
Webpack 4, est-ce qu'il faut passer à Webpack 5 ?
Et en fait, ça dépend.
Déjà, si vous utilisez des choses comme...
Et ça dépend, ça va dépendre de quoi, en fait.
Ça dépend, en fait, si tu utilises beaucoup de plugins.
Si tu utilises beaucoup de plugins, c'est pas dit que les...
C'est un peu le même problème.
C'est pas dit que les plugins que tu utilises sont déjà compatibles avec cette version,
même s'il n'y a pas de gros breaking change, mais...
Par exemple, j'ai essayé de passer un projet il n'y a pas très longtemps,
il y a une semaine, 10 jours sur Webpack 5 et ça ne marchait pas.
Donc voilà.
Donc je n'ai pas cherché à comprendre plus loin.
Mais oui.
OK. Donc attention sur la casse.
Est-ce qu'ils utilisent le système de...
Il y a ce module un peu comme les nouveaux Benleurs,
ce type Snowpack,
et tout ça directement dans le navigateur,
où en fait, c'est un build total et global.
Ça reste sur...
Non, ça reste la même chose que...
Il y a un gros changement de paradigme.
Non, non, du tout.
Il vient juste de faire un truc plus rapide.
Webpack reste Webpack,
ça vous fait un bundle que vous allez charger dans le navigateur.
Non, non, ce n'est pas du tout comme Snowpack, tout ça.
Ça reste identique.
Certains systèmes NUXED,
par exemple, la version 3 passera en Webpack 5.
Il y a des systèmes qui vont faire la transition.
Donc ça va améliorer l'expérience.
Oui, ça va améliorer l'expérience de développement,
mais après, ça reste la même chose.
Voilà.
OK.
Ça marche.
Et on passe à React.
Il y a eu des grosses nouveautés sur React.
Ouais, React.
Alors React, déjà, React 17 est sorti officiel de React 17 le 20 octobre.
Donc il n'y a pas très longtemps.
React 17, c'est une version qui n'apporte pas de changement au niveau développement.
En tout cas, j'ai fait l'expérience,
je suis passé d'un React 16, un React 17 sur un projet.
Il n'y a eu aucune casse, aucun changement, rien du tout.
Donc vous pouvez y aller sans problème.
Et qu'est-ce que ça amène alors ?
Au temps, c'est déjà vu.
En fait, la dernière version où il y avait apporté beaucoup de choses,
c'était la React 16.
16 points.
Je ne peux pas dire que connerie.
Je ne sais plus si c'est la 16.18.
Enfin bref, il y a eu vraiment une grosse montée et un grand changement quand on a eu l'arrivée
des hooks dans React.
Là, ce n'est pas du tout le cas.
Donc il n'y a vraiment pas de changement.
C'est vraiment sous le capot, c'est dans le moteur.
Donc il y a deux gros changements.
La première, je ne sais pas qui ça s'adresse.
Apparemment, c'est plutôt pour les gros projets.
Donc c'est une possibilité de faire cohabiter deux versions de React sur un seul projet.
C'est-à-dire que sur un projet, tu peux faire cohabiter une version 16 et une version
17 ou une version 18 quand on va passer à la 18.
Je ne vois pas vraiment l'intérêt.
Mais est-ce que tu...
Peut-être, après je ne sais pas, mais peut-être que tu viens hériter d'un code legacy qui
a une vieille version de React.
Et tu dois quand même dîler avec ça et pour l'instant, tu n'as pas d'autre possibilité.
Par contre, tu viens merger autre chose.
Enfin voilà, ça peut être intéressant d'avoir deux versions.
C'est le cas où vraiment quand tu as une grosse app et tu as du legacy un peu partout,
tu veux faire une nouvelle feature, tu vas passer sur la nouvelle version et le reste
reste sur l'ancienne, petit à petit tu vas le faire évoluer.
Mais bon, je pense que dans 95% des cas, ce n'est pas un truc qui va être très utile.
Enfin en tout cas, pour la plupart des projets.
Et deuxième évolution, après il y a des petites évolutions, mais vraiment ça ne
change pas grand-chose.
Mais la deuxième évolution sur le hook useEffect.
Donc useEffect, c'est un hook qu'on utilise, alors comment expliquer pour les non-reacts.
Il a plusieurs fonctionnalités en fait, il peut être utilisé quand le component est
monté, donc le mounted.
Il peut être utilisé quand un props est changé aussi.
Il y a différents, en fait en fonction des arguments qu'on lui passe, il réagit différemment.
Et surtout, quand on fait un useEffect, on peut retourner une fonction callback qui
marche en fait quand le component est détruit.
Et ce callback de useEffect en fait était synchrone jusqu'à maintenant et il passe
en un synchrone.
C'est-à-dire que si vous avez beaucoup de choses qui sont détruites, comme des écouteurs
d'événements, tout ça, qui peuvent ralentir l'application au moment où ce callback est
effectué, maintenant ça n'a un synchrone donc ça ne bloquera plus.
Ils sentent du compte que ça bloquait un petit peu les grosses applications vu que
c'était un synchrone donc maintenant ça va régler le problème.
Mais après c'est pareil, c'est un cas de figure qui, on est toujours sur les grosses
applis qui vont utiliser beaucoup d'écouteurs d'événements, tout ça.
Donc voilà les gros changements.
Si on résume entre 16 et 17, on ne peut pas dire que ça soit ouf.
Non, c'est pas fou.
En tout cas, si, si, j'imagine qu'ils ont beaucoup bossé dessus et c'est clair.
Mais enfin, en tant que développeur, ça va rien nous changer.
Ça, c'est clair.
Ok, donc en clair, c'est vraiment sous le capot que ça se passe.
Yes, donc passez à la 17 et puis il n'y aura pas de soucis.
Ça va passer sans terminer.

C'est lent.
Grosse nouveauté, pareil, s'il réacte évolu, ben de la même, on va dire à côté, il y a
un Next.js qui passe aussi en version 10 maintenant, qui doit être basé sur réacte 17, je suppose.
Exactement.
Donc il y a eu la conférence.
Je ne sais pas si c'était une, ouais, c'est une Next, en fait.
C'était une conférence Next et pas, et pas vers celle.
Donc c'était vraiment dédié à Next, c'était mardi dernier.
Et donc ils ont annoncé la version 10 de ce fameux.
Alors pour ceux qui ne connaissent pas Next, c'est un framework, on peut dire ça, qui
permet de générer des applications avec un rendu serveur.
Alors à la base, c'était vraiment une application réacte, donc c'est basé sur réacte, qui
permet d'avoir un rendu serveur sans rien faire en fait.
Vous n'avez pas besoin de faire du code serveur, etc.
Tout est déjà inclus.
Vous vous construisez votre projet et votre application réacte à un rendu serveur.
Donc on est déjà la version 10.
Ça fait quand même quelques années qu'il existe.
Je ne sais plus quelle année il a été créée.
Et donc ils ont rajouté la version 10, la support de réacte 17.
Bon, à priori, ce n'était pas compliqué.
Donc puisqu'il n'y a pas de changement.
Apparemment.
Donc peut-être qu'ils utilisent justement toute la puissance sous le capot de 17 pour
faire des améliorations dans leur moteur à eux.
Peut-être.
Je sais pas trop.
Mais en tout cas, ce qui est cool, c'est qu'il y a toujours un support et c'est réactif.
Voilà, ils sont déjà réactis de sort et une ex-js10 sort avec la nouvelle version.
Donc il y a vraiment une grosse réactivité.
Donc ça conforte dans le fait de partir sur ce framework.
Ensuite, ils ont rajouté un component NextImage qui, apparemment, les gens ont demandé un
équivalent à GatsbyImage.
Alors GatsbyImage, pour rappel, c'est un component, un service qui est dans Gatsby
par défaut et qui permet de redimensionner et d'alléger le poids des images, tout ça,
au moment de la compilation.
Et c'est hyper pratique quand on l'utilise au quotidien.
Donc ils ont fait un équivalent pour Next.
Donc c'est un component NextImage.
Vous mettez vos images et lui, au moment de la compilation, il va réduire le poids
de l'image, etc.
Donc c'est vraiment pratique à utiliser.
Donc là, ça vient de sortir avec.
Ils ont annoncé aussi la prise en charge d'internale...
Je n'arrive pas à le dire.
Et 18N, on va dire.
C'est d'ici.
Internationalisation.
Ah, tu l'as bien dit.
Donc directement, d'office par défaut dans le routage de Next.
Donc ça, il y a deux types de prises en charge avec les slashes FR, comme d'habitude,
comme on peut faire dans beaucoup d'applications.
Il y a aussi une prise en charge du domaine routine.
Donc le domaine routine, ça permet d'avoir, en fonction de la langue, peut avoir un point
FR, un point COM ou un point NL.
Je ne sais pas, n'importe.
Et donc ça, c'est d'office dans...
Alors attention, ça ne veut pas dire que ça fait aussi la traduction du texte.
Après, vous devez quand même ajouter une librairie de traduction.
Il dit 18N, Next, ou des choses comme ça.
Mais déjà, d'office dans le routage, il y a déjà un système de prise en charge des
langues.
Donc ça, c'est plutôt pratique.
Voilà.
Et ensuite, ils ont annoncé une feature, alors qu'elle y est pour l'instant à Next.js
et aussi à la plateforme Vercel.
Donc Vercel, c'est le système de déploiement d'applications identiques à Netlify, qui
permet de déployer une application via GitHub.
Un service d'hébergement.
Exactement.
Qui déploie automatiquement votre application quand elle est mise à jour sur GitHub, ou
des choses comme ça.
Enfin, il y a différents process qui prenent en charge beaucoup de langages aussi, même
du PHP.
Donc il est vraiment bien fait.
Si vous ne connaissez pas, je vous recommande de tester.
Et donc là, ils ont annoncé Analytics, qui est donc lié à Next.js.
Donc il ne fonctionne pour l'instant que sur Next.js, mais qui est prévu à être compatible
avec d'autres frameworks.
Et c'est à savoir ajouter un dashboard sur votre dashboard.
En fait, ça rajoute un panneau sur votre dashboard Vercel qui indique en fait les
vitesses de chargement, le first, the line put, des trucs comme ça.
Toutes ces données qui vous permettent de savoir si l'application est rapide, réactive,
etc.
Ça vous donne un score, etc.
Ok.
Donc en fait, quand tu parles d'analytics, on est bien d'accord que c'est des analytics
de performance.
En fait, on pourrait parler un petit peu de monitoring de ton application.
Exactement.
Parce qu'on va aller regarder la vitesse de performance, s'il y a des cases, tout ça,
sur quel commit.
Donc en fait, tu vas monitorer.
Ils ont appelé ça analytics.
Mais on est bien d'accord que tu viens analyser et monitorer la performance de ton application
et de ton déploiement.
C'est ça ?
Exactement.
Rien à voir avec Google Analytics.
Ok.
Ça ne vous donne pas le nom de l'équipe ou de la conversion.
Non, non.
C'est vraiment basé sur la performance de l'application au niveau de chargement,
etc.
C'est tout à peu près les données qu'on retrouve sur Lighthouse.
Mais tu sais, les web, comment ils appellent ça ?
Oui.
J'ai oublié le nom.
Enfin, les données de base qui permettent de savoir si ton site est rapide et de faire
un RSI, l'utilisateur.
Oui, c'est performance, accessibility, SEO, tout ça.
Sauf que, par exemple, sur Netlify, tu as déjà Lighthouse qui peut se faire automatiquement
quand tu te dépouves.
Il va te dire, ok, là tu viens de payer ton plugin.
C'est un plugin que tu rajoutes.
Là, c'est différent parce qu'en fait, c'est les données réelles des visiteurs.
En fait, il y a un système qui prend les données.
Ok, c'est pas basé sur un moment dans ton build où tu fais un test tiers.
Là, c'est du retour d'information de réel user.
Exactement.
Exactement.
Ah ouais.
Donc, du coup, c'est beaucoup plus pertinent parce que c'est basé sur la réalité.
Oui, sur la réalité, sur les visiteurs en fonction de d'où ils sont, etc.
Donc, c'est hyper intéressant et c'est lié aussi au déploiement.
Donc, si tu déploies un moment donné, tu vas, imaginons, tu passes de la version
XJS9 à la version XJS10, tu vas voir un déploiement.
Et là, il va te l'indiquer sur un graphique que c'est à ce moment-là que tu as déployé
et tu vas voir si ton graphique, si la vitesse augmente ou si la vitesse diminue.
Enfin, voilà.
Tu vas vraiment avoir une impact, tu vas pouvoir analyser si ce déploiement, il a eu
une impact négative ou positive sur la vitesse.
Enfin, c'est plutôt bien fait, c'est hyper intéressant.
Donc, du coup, tu prends le comit, tu fais guide blame et tu regardes qui a poussé cette
mer qui vient te péter la perve de l'app et tu fais une fonction qui balance un message
sur Slack direct en mode, ça, c'est pas possible, c'est ta faute, corriges ta merde.
C'est ça ?
Oui.
C'est un peu ça.
Non mais c'est cool parce que tu peux voir tous tes comités, tu es...
Oui, c'est ça, c'est intéressant.
À chaque évolution.
Oui.
Top.
Alors, par contre, c'est une donnée, évidemment, c'est payant.
C'est pas un service qui est gratuit sur Versel, puisque...
Versel, de toute façon, c'est pas très cher.
Enfin, je sais pas si il est tarif, je sais pas sous la main, mais c'est pas un tarif
qui est prohibitif si tu as une app qui tourne, etc.
Et après, ça, c'est une option qui se rajoute en fait.
Je crois que c'est 10 dollars par mois et après, tu payes par le nombre d'appels,
un truc comme ça.
Mais je pense que les données que ça t'apporte, ça vaut largement le tarif.
Mais après, il y a des services de monitoring.
Il faut voir.
Parce que là, c'est sûr qu'en tant que plateforme, ils ont toutes les données et
ils sont au plus proche des données.
Du coup, pour eux, ils viennent toutes internaliser.
Donc, c'est top.
Et nous, ça nous évite de passer par un service tiers, de faire toute la conflit et
de venir surcharger peut-être le client pour récupérer de la data.
Enfin, non, clairement, ça a un coût et ça s'organise, ça se budgetise.
C'est normal aussi que ça passe par un truc payant.
Je crois que c'est chez eux.
Je crois que c'est pas de cookie en plus.
Donc, c'est compatible RGPD.
Il me semble.
RGPD friendly.
Je crois qu'il laisse pas de cookie ou quoi que ce soit.
Parce que c'est vraiment côté server.
Donc, on va bien analyser côté serveur.
Gagné, bien sûr.
Donc, on a analytics à voir.
Je n'ai pas encore testé.
Il faudrait que je fasse un petit site en X pour voir un petit peu ce que ça donne en
vrai.
Mais c'est vraiment intéressant.
Et pour finir sur Next, ils ont sorti aussi durant la conflit.
Une conflit qui était quand même orientée, je reviens quand même un petit peu sur la
conflit.
C'était très orienté, performance, vitesse de chargement.
Il y avait des gars de chez Google qui venaient témoigner à machin.
Le truc classique, j'ai gagné tant de visiteurs avec deux secondes de charge.
Bref, tout classique.
La social proof.
Il faut passer sur cette main.
Merci.
Il faut que ça, machin, optimiser, machin.
Et aussi, qui était basé un petit peu sur le Headless e-commerce.
Donc, petit rappel sur le dernier épisode avec Aurélien.
Donc, on a fait sur le e-commerce.
Donc, ça conforte un petit peu dans ce qu'on disait en fait que le e-commerce petit à
petit est en train de s'orienter sur le Headless.
Et donc, du coup, Next a sorti, alors il s'appelait ça un starter kit, Next.js.com.
Donc, c'est un starter kit basé sur Next.js que tu peux déployer, modifier évidemment,
et qui est déjà prêt à fonctionner.
Et celui-là, pour l'instant, il est connecté à, comment ça s'appelle ?
J'ai bouffé le nom, Big.com.
Allez, O.S.
O.S.
commerce.
Non, c'est Big.com.
O.S.

O.S.


Il a parti vu de ton application.
Exactement.
Il fait un view, la partie visible.
Et donc, tu pourras connecter n'importe quel back-end.
Alors peut-être qu'aujourd'hui, ils n'ont qu'un seul provider.
Pour l'instant, c'est Big.com.
O.S.


Pour l'instant, c'est Big.com.
Mais ils annoncent que, parce qu'il y a déjà les logos quand tu vas sur la page.
Donc, on mettra les liens évidemment.
Il y a déjà les logos comme Shopify, Swel, qu'on a parlé dans l'épisode dernier.
Il pense connecter plusieurs systèmes e-commerce qui fonctionnent avec des APIs.
Et du coup, en un clic, tu peux déployer une app et te connecter à ton back-end que tu utilises habituellement.
Parfait.
Excellent.
Bon, bon système.
On voit que le e-commerce part vraiment sur les ad-lesses.
On est vraiment en train de découpler le back-end du front.
Et qu'on va se retrouver de plus en plus avec du front sans un applicatif.
Soit avec Next, c'est du rendu serveur.
Pour le SEO, ça reste compatible.
On voit vraiment une séparation entre les deux.
Donc, ça conforte un petit peu de ce qu'on disait dans le dernier épisode.
Ça va me aller plus loin même sur la tendance de Jamstack, de Statik, de New Dynamics,
de tous les outils modernes où on vient découpler chaque logique.
On vient coupler et orchestrer tous ces services qui font ça très bien.
Mais on vient séparer les pouvoirs au lieu de tout mettre dans un seul et même instance d'appli.
Et Next étant comme Next, c'est toujours difficile de dire les deux.
Donc, Next étant comme Next, il génère du Statik aussi.
En plus de faire du rendu serveur, il est capable de générer du Statik.
Donc, pour des sites e-commerce, qui peuvent avoir des montées de pics de visites,
comme là on a eu le Black Friday, je ne sais pas comment ça va tourner, on n'a pas eu des chiffres.
Enfin, je n'ai pas vu de chiffres encore.
Mais sur du contenu qui ne va peut-être pas changer,
ou c'est juste la disponibilité, le stock, tout ça, ou le prix qui va changer,
on est totalement dans une logique de performance avec une page qui ne change pas.
C'est juste quelques éléments dynamiques dans la page qui vont changer.
Donc, on est totalement en adéquation avec ça.
Quarraiment, carraiment.
Yes, et du coup, génération Statik, tout ça, Gatsby, ça bouge aussi un peu, non ?
Alors Gatsby, c'est le petit générateur de sites Statik qui fait son bout de chemin,
c'est un peu le mec sur la plage en Normandie qui débarque,
et tu sais, il se fait attaquer dans tous les sens, mais il continue son chemin.
Donc Gatsby, il est vachement critiqué.
Il est beaucoup critiqué, mais en même temps, c'est le générateur qui a fait vraiment évoluer le Schmilblick,
parce que, pour rappel, quand on prend Next ou Next, ils ont implémenté des choses,
parce que Gatsby prenait vraiment de l'ampleur de plus en plus,
et c'est lui qui a fait vraiment avancer la Jamstack avec le Statik.
Après, de toute façon, plus il y a d'acteurs dans la place, plus ça se tire la bourre,
plus c'est intéressant, et surtout, plus ça met les projecteurs sur le problème que résout la Jamstack.
Donc, au final, c'est l'écosystème qui gagne, et c'est nous, Dev, au milieu, qui gravitons dans cet écosystème.
On a la vie plus facile, ça nous fait des choses un peu plus faciles,
et tout le monde y gagne. Je pense que nous, développeurs, on y gagne.
Complètement, oui. Du coup, Gatsby, ce qui est bien, c'est que l'équipe, elle est dynamique,
ils ont fait des levées de fonds, ils se remettent en question, ils écoutent la communauté, ils avancent.
Et donc, ça donne, en fait, quatre choses.
Une évolution déjà de la génération de pages.
Alors ceux qui connaissent Gatsby, jusqu'à il n'y a pas longtemps, pour générer une page,
on était obligés d'utiliser la, enfin, pour générer, si par exemple vous vouliez générer une liste de postes ou d'articles,
vous étiez obligés de passer par l'API et de générer des pages avec, voilà, les écrivies du code, des fonctions,
il y a une create pages qui est disponible, vous faites votre quête, vous créez vos pages avec un template, etc.
Et ça, ça évolue, parce qu'en fait, Next et Nux, ils avaient intégré des systèmes automatiques
avec des variables dans les noms de fichiers. Donc, ils ont évolué leur système, c'est en expérimentale pour l'instant.
Donc, maintenant, pour Gatsby, on pourra générer des pages dynamiquement et comment ça marche.
En fait, on met une variable dans le nom du fichier. Donc, vous avez une page classique dans votre dossier Pages,
vous mettez, soit vous utilisez le slug, soit vous utilisez l'identifiant, soit le nom, enfin la différence que vous voulez.
Et en fait, lui, il va générer, enfin, il y a tout un système, donc on mettra le lien.
Il va générer automatiquement les pages par rapport à une requête et au nombre de résultats.
Et il va vous générer cette page-là plusieurs fois, voilà. Un peu à la manière de Next et Nux.
Donc, c'est une grosse évolution et ça fait surtout écrire beaucoup moins de codes, en fait, parce que c'est vrai que ça fait...
Non, mais là-dessus, c'est clair. Après, enfin, dire que c'est nouveau, oui, c'est...
On se fait plus chier à paramétrer nos routes, quoi.
Enfin, moi, ce que je vois sur là-dessus, c'est quoi, tu gagnes un temps de fou sur la création de ta page et ton layout de page.
Et tu te fais pas chier à paramétrer un router qui, on peut pas dire que ça soit le plus excitant dans l'expérience d'un développeur, quoi.
Par améliorer le router, bon, c'est pas top.
Et là, en fait, ils se mettent juste... Alors, je vais être un peu méchant, mais ils se mettent juste à niveau, quoi.
Non, mais clairement, ils se mettent à niveau de Next et de Nux, quoi.
C'est exactement ça, ils se mettent à niveau parce que, oui, parce qu'à un moment donné, Next et Nux se sont orientés aussi vers le statique,
ce qu'ils ne faisaient pas avant. Avant, c'était plutôt du rendu serveur, etc.
Ils sont orientés vers le statique en s'inspirant, on va dire, entre guillemets de Gatsby,
mais en faisant des choses différentes et en faisant des choses un peu plus performantes.
Et du coup, on revient vers le Gatsby en disant, mais eux, ils font mieux maintenant.
Du coup, ils se remettent en question Gatsby et ils font, OK, on va l'implementer, machin.
Et ça donne ça. Donc, c'est un expérimental. Ça fonctionne déjà, donc, à tester.
Mais l'orientation de Gatsby, de façon, leur but à eux, c'est de... je ne sais pas dire...
C'est presque de devenir le WordPress du générateur de six statiques.
Donc, le but de Gatsby, c'est que ça soit facile à utiliser en fait.
Un développeur sera toujours capable de faire un site en Gatsby.
Mais eux, leur but, c'est que quelqu'un qui n'est pas forcément hyper technique
soit capable de faire aussi un site Gatsby. C'est ça leur but.
Donc, c'est pour ça qu'ils simplifient les procès.
OK.
Et du coup, c'est pour ça aussi qu'ils ont sorti, donc c'est la deuxième truc,
c'est Gatsby admin. Donc, c'est expérimental aussi.
Alors, il y a toujours un flag à mettre quand c'est expérimental au niveau de ton package.json.
C'est une admin en local. Donc, tu fais ton développement en local, machin, tu lances ton local.
Et comme là, jusqu'à aujourd'hui, on avait déjà une interface graffecuelle en local quand tu codées sur du Gatsby.
Voilà, mais on aura une admin en local, pareil, qui te fait résumer en fait des plugins que tu as,
de comment ils sont installés, des paramètres et tout.
Donc, ça, c'est pareil. C'est intéressant. Voilà, toujours pareil.
Pour l'instant, tu peux le faire facilement. Tu vas dans le fissier où il y a les plugins qui sont indiqués
et tu vois ce que tu as mis comme réglage de ça.
Là, ils simplifient encore les choses. Donc, petit à petit, tu vois, je ne sais pas jusqu'où ça va aller,
mais ils essaient de rendre le truc hyper accessible en fait, au nom des brokers.
Par contre, c'est que accessible.
Oui, par contre, c'est que accessible en local.
Oui, que en local pour l'instant.
D'accord.
Après, c'est accessible via le Gatsby Cloud.
Je ne sais pas vu si ils avaient lié ça avec le Gatsby Cloud,
ou t'aurais pu être une interface, tu pourras rentrer sur tuyens, mais je ne sais pas.
Et du coup, qu'est-ce que tu vas pouvoir gérer là-dedans ?
Tu vas pouvoir gérer ton contenu ?
Non, non, c'est vraiment que les paramètres du projet.
Les plugins, les variables, quelques variables globales, tout ça.
Ok, donc en fait, on sort un peu du code,
ça nous met une sorte d'interface graphique au paramètre de Gatsby Cloud.
Oui, je vis ça quelque part, je ne sais plus sur quel projet,
je n'avais vu un truc similaire sur Vue, je crois, je ne sais plus.
Ah, suivre en GUI, c'est...
Ok, et deux autres choses.
Donc, à la manière de Netlify, ils rajoutent Gatsby Function.
Donc ça, c'est en RFC.
RFC, c'est Request for Comments.
RFC, maintenant, tous les gros projets, comme Vue, Gatsby et etc.,
font ça, c'est-à-dire qu'ils ouvrent une sorte d'issue,
et les gens viennent donner des commentaires à tout ça pour faire évoluer.
Ils disent, voilà, j'aimerais implémenter tel truc.
Qu'est-ce que vous en pensez ?
Et chacun vient donner son commentaire,
à dire, on préfère avec ça comme ça, à machin et un bisou.
Donc ils l'ont fait beaucoup pour Vue,
il y a une grosse discussion sur la composition API.
Mais voilà, tous les projets le font maintenant.
Et c'est deux choses, donc la Gatsby Function,
donc il y a des fonctions un peu à la Netlify,
qui vont pouvoir être appelées directement sur Gatsby Cloud.
Donc c'est des fonctions Serverless ?
Oui, c'est ça, c'est des fonctions Serverless,
et qui fonctionneront sur Gatsby Cloud, comme sur Netlify.
Ok, mais après, de toute façon,
ça me paraît difficile de faire des trucs un peu modernes,
que avec du statique.
Un moment donné, il y a toujours besoin de, je sais pas,
envoyer un mail, envoyer procéder un paiement,
ou je sais pas, faire, faire,
mettre à jour la base de données,
ou aller récupérer les infos de la base de données
sur un prix, peut-être, ou des choses comme ça.
Du coup, si on est sur du full statique,
ça devient difficile.
Et on peut solutionner ce problème-là
avec des appels, on va dire Serverless.
Il y a toujours, il y a bien un serveur quelque part,
que les choses soient d'accord.
C'est juste ailleurs, c'est tout.
C'est juste un ordinateur déporté,
mais en tout cas, il va falloir procéder à quelque chose,
et donc, c'est une fonction qui va être exécutée,
qui a pour une mission assez simple,
une tâche simple, envoyer un mail,
envoyer une notification, procéder un paiement.
Et donc, en fait, ils viennent coupler ça.
Donc, en fait, ils viennent renforcer leur écosystème.
De Gatsby Cloud, ouais.
Exactement, de Gatsby Cloud.
Comme ça, il y a un seul point d'entrée.
Je viens générer mon code, je l'éberge,
je fais mes fonctions,
je optimise mes images,
tout à l'intérieur de Gatsby.
Ouais, dans le but, de se croiser en grâce.
Dans le but très clair de concurrencer Netlify,
puisque, voilà, des choses qu'ils pouvaient manquer
sur Gatsby Cloud, qui étaient sur Netlify,
arrivent sur Gatsby Cloud, donc tu n'as plus de raison
de pas utiliser Gatsby Cloud et de partir sur Netlify.
Donc, ils essaient de garder des parts de marché,
de gagner des parts de marché,
mais par contre, c'est toujours orienté à Gatsby.
C'est pas compatible avec d'autres systèmes.
Voilà.
Mais après, oui, comme tu dis,
c'est pas parce que c'est statique, que c'est pas dynamique,
et comme tu dis tout le temps,
static is a new dynamic.
Mais oui, static is a new dynamic, et c'est clair.
C'est clair.
Et pour finir, c'est une basse line.
Et pour finir, on a sur Gatsby,
donc Gatsby Image, j'en ai déjà parlé un petit peu plus haut,
donc un système hyper intéressant, hyper performant,
est très agréable quand on l'utilise au quotidien,
parce que ça fait tout seul,
ça vous comprime les images, tout ça,
ça les compress, ça leur rédimensionne et tout ça.
Bah, ils vont la modifier un petit peu,
et ils essaient de faire en sorte que ça soit
utilisable en dehors des requests,
enfin des graphes QL query,
et pour que ça gère un peu le statique, tout ça.
Donc ça a une grosse évolution aussi,
parce qu'en fait, Gatsby Image,
il est top, mais par contre,
il peut te ralentir la compilation,
puisque c'est à la compilation
qui réduit les images, etc.
Et si tu as un site qui a énormément d'images,
ça peut faire vraiment augmenter le temps de compilation.
Donc c'est... Voilà.
Ils essaient d'autres approches.
Donc ça, c'est un RFC aussi, c'est en discussion.
Donc à suivre, voir comment c'est évolué de ce côté-là.
Voilà, voilà.
Excellent, excellent.
Moi, ce que je vois, c'est que ça bouge pas mal,
surtout ces acteurs, on va dire,
de générations de sites statiques.
Et justement, il y a un super article
qui est sorti sur jamstatique.fr,
je crois, qui a été traduit,
ou justement, il y a un article de comparaison, c'est ça ?
Oui, c'est un article, alors qu'il a été traduit.
Donc c'est un article qui est à la base sur CSS Tricks.
Il s'appelle Cine Davis, je sais pas...
Cine C Davis, exactement.
Et je crois qu'il est un petit peu prof, etc.
Enfin, je sais pas trop ce qu'il fait,
mais il a fait une comparaison entre six générateurs
de sites statiques, donc les six plus gros générateurs,
les plus connues en tout cas.
Et ça a été traduit en français, parce que c'est en anglais,
à la base, enfin, et ça a été traduit en français
par Franck, donc, du site jamstatique.fr.
Donc remercie Franck d'avoir traduit,
d'avoir fait le travail.
C'est un article qui est hyper intéressant,
parce qu'il prend sur six générateurs,
donc les six, c'est Eleventy,
Gadb, Hugo, Jekyll, Next et Next.
Donc c'est six générateurs de sites,
donc il explique en fait,
qu'il y a deux types de générateurs de sites statiques.
Et ça, c'est clairement, ce qu'il faut bien comprendre,
c'est qu'il y a les générateurs de,
lui, il dit de base, donc c'est Eleventy, Hugo et Jekyll.
Quand on dit des générateurs de sites statiques de base,
en fait, c'est qu'ils vont juste générer des fichiers HTML.
Contrairement au système avancé, comme Gadb, Next et Next,
qui, eux, vont générer des applications.
Donc on a deux sortes de générateurs.
On comprend bien que c'est plus facile de générer
un fichier simple HTML que de générer
une application React ou Vue.
Donc ça, c'est déjà, il explique bien qu'il y a deux grosses différences
et que déjà, les avancés, en plus,
font appel à Webpack.
Donc forcément, quand tu vas faire appel à Webpack
pour générer tes pages,
ça va normalement rendre la génération,
la compilation beaucoup plus lente.
Donc tout ça, il explique très, très bien
et il explique aussi comment il a testé, en fait,
ces sites, ces générateurs de sites statiques.
Donc son test, en fait, il t'est basé sur des data en markdown.
Donc il explique, il y a un font-mateur et t'as trois paragraphs
qui sont générés, voilà, des attourments.
T'as pas d'image, donc ça c'est dommage parce que tu vois,
ça ne met pas en jeu le Gadb image.
Et après, la sortie HTML, elle est assez simple.
C'est juste, il dit, basé sur les start-ups
de chaque générateur.
Et surtout important, c'est des tests qui sont faits à froid.
C'est-à-dire qu'il n'utilise pas du tout de cache.
Il faut savoir que quand tu compiles avec NUXT ou Gadb,
ou n'importe, il fait un cache, en fait, qui fait qu'il y a un moment donné,
quand tu fais le développement, tout ça, ça génère plus rapidement.
Donc lui, il le fait sans cache.
Donc c'est vraiment à froid.
Donc c'est forcément le truc le plus long qu'il peut y avoir.
Il n'y a aucun fichier de cache.
Ouais, après, c'est vachement bien de tester son cache.
Parce qu'au moins, en fait, il faut bien avoir un protocole un peu scientifique
pour tester, dire, OK, on prend le parti pris de faire ces tests-là.
Parce que si on teste avec du cache chez là et pas de cache chez l'autre,
en fait, on rajoute des variables et ça peut compromettre le résultat.
Oui, parce qu'il y a un qui peut...
Il peut y en déficiter les cache un peu plus performant que d'autres.
Ça fausse un petit peu le truc.
Donc là, au moins, c'est tout à à plat.
Donc c'est nickel.
Ouais, top.
Et ensuite, il explique qu'il a fait 10 séries de tests avec 3 ensembles de données.
Donc les 3 ensembles de données, la première, c'est un test basique avec un seul fichier.
Donc il compile un fichier.
Après, il a fait un petit site de 1 à 1,024 fichiers.
Et après, les grands sites de 1,064 000 fichiers.
Et donc voilà, c'est trois différents générations de fichiers.
Donc on voit qu'il y a vraiment 64 000 fichiers.
Ça fait quand même ce qu'on commence à faire un gros, gros site.
Donc les résultats, il est...
Donc lui, il partait du principe et Hugo l'annonce sur son site.
Comme quoi, c'est le générateur le plus rapide du monde.
Donc effectivement, dans les résultats, on voit qu'Hugo est quand même le plus rapide.
Mais intéressant aussi, il a vu que Next était assez rapide
et même plus rapide que Jekyll sur 32 000 fichiers.
Donc c'est quand même pas mal puisque Jekyll, pour rappel, ça gêner juste du HTML.
Ça gêner pas une application.
Next est plus rapide que Jekyll sur 32 000 fichiers
et il est encore plus rapide que Jekyll et Eleventy,
qui est censé être hyper rapide Eleventy, avec 64 000 fichiers.
Donc on voit que Next, c'est limite la surprise du test en fait,
parce qu'il est très rapide.
Et même sur un gros site, il peut être plus rapide qu'Eleventy,
qui est Eleventy basé sur Node.js, ne gêner que du fichier HTML.
Donc ça, c'est pas mal.
Après, si on regarde un peu les courbes,
on pourrait s'attendre à une évolution un peu linéaire.
Mais en fait, pas du tout.
Elle est pas linéaire.
En fait, le nombre de fichiers va vachement influencer sur ta charge.
Mais contre toute surprise,
moi, ça m'a surprise, c'était de voir que ces courbes, elles sont pas linéaires.
C'est ce qu'il dit.
Il est assez surpris de penser avoir des choses un peu linéaires.
Il se rend compte qu'il n'y a aucun qui est linéaire.
En fonction du nombre de fichiers,
je ne sais pas ce qui rentre en jeu,
mais après, on mettra le lien, il y a toutes les courbes, il explique bien.
Mais il n'y a aucun fichier, aucun générateur qui est linéaire.
Même Hugo n'est pas linéaire.
Il dit, comme il est rapide, on a l'impression qu'il est linéaire,
mais en fait, il n'est pas du tout linéaire.
Par exemple, pour Hugo, il dit qu'il devient de plus en plus lent
au fur et à mesure que les fichiers augmentent.
Ce qu'il donne, c'est que Hugo, avec un fichier,
il est 170 fois plus rapide que Gatsby.
Ça, normal.
Mais par contre, avec 64 000 fichiers,
il devient seulement 25 fois plus rapide que Gatsby.
On voit que Hugo perd en vitesse avec un nombre d'eux-fis important.
Après, il y a beaucoup de choses qui rentrent en jeu.
Après, je suis complètement d'accord.
Après, il ne faut pas oublier que ça reste quand même ultra rapide dans tous les cas.
On parle de 64 000 fichiers.
C'est énorme.
Il faut aussi raison garder.
Je ne pense pas qu'il y ait beaucoup de personnes,
des grands sites où il y a 64 000 repérences
qui veulent passer sur du statuque et générer du site statuque.
Aujourd'hui, je ne pense pas qu'il y ait beaucoup de sites statuques là-dedans.
Si, justement, des gros taux.
Non, en fait,
comme tu as pu le remarquer,
on en avait déjà parlé ensemble,
il y a de plus en plus de gens qui s'intéressent au générateur de sites statuques.
Et notamment,
ça peut être des sites de presse, de médias, etc.
Par exemple, ils vont écrire 5 articles par semaine.
Donc au fil des années, ça fait beaucoup d'articles.
Et à un moment donné,
il faut aller compiler ces articles.
C'est là où le temps de compilation va quand même être pris en compte.
Parce que tu ne peux pas te permettre de...
Évidemment, maintenant, il y a des...
Après, il incrementale 1000.
C'est ce que j'allais dire.
C'est ce que j'allais dire maintenant.
Maintenant, on a petit à petit des choses incrementales, etc.
qui permettent de ne pas regenerer tout le site à chaque fois.
Mais voilà, c'est des choses qui sont pris en compte.
J'ai une discussion, il n'y a pas longtemps qu'un client.
C'est quelque chose qui rentre en compte
dans le choix du générateur de sites statuques.
Alors, je reviens sur les résultats.
Sans surprise, Hugo est le plus rapide,
mais évidemment, Gatby est le plus lent de tous les générateurs.
Donc, bon, c'est comme ça.
Après, comme il explique, en fait,
ceux qui sont les plus lents en font plus.
Donc, c'est ça aussi la différence.
Après, il faut savoir à peu près...
Donc, pour finir,
en fait, le résumé en gros de l'article,
on mettra tous les liens, tout ça,
il est vraiment intéressant,
c'est qu'en fait,
le choix n'est pas seulement basé sur la vitesse.
En fait, ça dépend surtout de ce que vous avez besoin,
du temps que vous pouvez attendre, etc.
C'est ça, en fait.
On ne peut pas choisir, on ne peut pas dire juste
« Ouais, moi, j'ai un truc rapide, je vais prendre Hugo. »
Ok, non.
Next ou Next, ou Gatby, c'est différent.
Ça vous sort une web app.
Donc, c'est quand même une expérience différente.
Une fois de plus, en fait, c'est pas la techno.
Il ne faut pas être techno-driven,
mais bien, project-driven.
Quelles sont les contraintes ?
De quoi j'ai besoin ?
Et après, c'est toujours des histoires de compromis.
On vient choisir la techno
qui s'adapte plus aux contraintes du projet.
Exactement.
C'est un peu la morale du tout.
Et...
Bien, oui, carrément.
En parlant de Jamstack et de grosses ressources,
il y a MDN qui passe sur la Jamstack.
T'as vu ça, non ?
Exactement.
MDN, donc, suite au déboire de Modilla
depuis le début 2020.
Donc, 2020, c'est vraiment une année de merde.
On peut le dire, même pour Modilla.
Et donc, ils annoncent...
MDN, donc, c'est une documentation en ligne
qui est, enfin, je trouve ça hyper utile.
Il y a souvent des infos intéressants dedans
et que je recommande à tout le monde
de ne serait-ce que lire la doc sur certains éléments,
tout ça, HTML, JS, ça parle de tout,
CSS, JS, tout ça.
C'est une documentation qui est en mode communautaire.
Un peu à la Wikipedia, donc chacun pour les articles, tout ça, machin.
Et ils ont annoncé, donc, jusqu'à maintenant,
en fait, ils avaient un système qui était basé
sur du MySQL et de l'élastique cherche, en fait.
Ils avaient Django en front avec du React,
une sorte de CDN qui se raffirait chez ça toutes les cinq minutes.
Et donc, ça faisait quand même une structure,
une infrastructure qui était un petit peu lourde,
puis avec de plus en plus de mal, en fait, à la maintenir, tout ça.
Il y a un coût aussi d'infrastructure.
Et puis les lecteurs, les contributeurs,
passaient par la même interface, tout ça.
Donc, c'était vraiment pas terrible.
Donc, là, ils ont pris le parti de passer
sur du Jamstack, en fait, complètement.
Donc, ils avaient déjà annoncé avoir migré
vers GitHub toutes leurs documentations,
donc chaque page, en fait, du site mdn.
Et là, ils viennent de révéler, en fait,
donc, ce n'est pas encore complètement déployé,
c'est en beta, ils sont en train de mettre ça en place.
Mais, voilà, ils passent complètement en Jamstack.
Donc, il y aura quand même une partie qui restera
sur Elasticsearch et MySQL.
Ça, ça sera uniquement pour les recherches sur le site.
Mais après, tout le reste va passer en fichiers statiques.
Donc, ils n'annoncent pas du tout,
ils ne donnent pas de techno, en fait, ils ne disent pas
si c'est du Jekyll, du Hugo ou n'importe quoi.
Ça, ils n'en parlent pas du tout.
Juste, voilà.
Ils parlent de l'archi.
Oui, ils parlent de l'archi.
Tout va être sur GitHub en mode guide CMS.
Voilà, ça sera tout le dessus.
Voilà, en fait.
Et après, build.
Ils vont faire un ring de toutes les bases de données.
Ils restent au MySQL, mais il n'y aura plus de documentation de temps.
C'est tout sur GitHub.
Et il y aura une génération, un déploiement,
toutes les 24 heures.
Donc, comment ça va marcher maintenant ?
Les contributeurs, ils vont ouvrir des pools request sur GitHub.
Donc, il y aura vraiment une validation,
voilà, des contributions.
Et toutes les 24 heures en déploiement,
donc, sur du statique.
Et au pire, ils annoncent que si jamais tu as contribution,
elle loupe le 24 heures,
ça sera au plus tard,
ça sera 48 heures.
Donc, dans tous les cas,
tu auras maximum 48 heures.
Ça sera visible sur le site.
Voilà, ça va vraiment alléger toute l'infrastructure.
La performance, évidemment.
Oui, tu m'étonnes.
C'est Microsoft qui va payer.
En fait, ils déplacent tout chez GitHub.
Et eux, ils font des énormes économies
sur toute l'infra et sur l'archi.
Et ils utilisent l'archi des autres.
Donc, celle de GitHub.
J'espère que...
C'est malin, ils ont raison.
Ils ont raison.
C'est GitHub, quand même,
parce que c'est quand même une contribution open-sport.
Non, mais bien sûr.
Bien sûr.
Enfin, c'est un projet qui est super majeur.
Aujourd'hui, en tant que dev,
si tu es dev front,
tu n'as jamais voulu voir MDN.
Tu as arrêté ta vie.
C'est chaud.
Non, tu as pas arrêté ta vie.
Mais en tout cas,
tu as des trucs quand même
qui sont super intéressants
et qui aident vachement.
Donc, je pense que c'est top.
Et puis, en plus,
c'est un peu dans l'air du temps.
Et ça ressemble aussi.
Et ça se rapproche
sur tout le workflow, en fait,
d'une évolution open-source
qui est orientée vers et pour la communauté.
Donc, ça se tient, quoi.
Ça se tient carrément.
Et aujourd'hui, la techno est mature.
Et moi, je trouve ça bien
en termes d'évangélisation un petit peu
de la Jamstack,
parce que c'est un acteur majeur.
Tout le monde connaît MDN,
Mozilla,
et que eux passent
sur une architecture Jamstack.
Ça prouve que l'archi
et la techno, elle est mature.
Et que...
Oui, puis ça va faire un peu déployer
des gros projets.
Oui, puis ça fait baisser
les coûts d'infrastructures.
On voit que...
Attends 24 heures pour ta contribution
sur online.
C'est pas dramatique.
Et d'un autre côté,
l'expérience utilisateur,
le site va charger plus vite.
Il sera plus sécurisé aussi.
Il ne faut pas oublier ça.
Et puis ça coûtera beaucoup plus.
Et après,
une fois de plus,
c'est ce qu'on a besoin
d'une instantanéité pour tout.
Sinon, on met tout en WebSocket.
Ça va super vite tout.
Mais ce qu'on a besoin,
où est le bon sens.
Et une fois de plus,
c'est le projet, la contrainte.
Non, c'est plutôt...
Bonne nouvelle.
Bon, nickel.
Mais je crois qu'on a fait le tour
des news
qu'on avait à vous présenter.
Patrick, tu veux rajouter...
Attends, on n'a pas parlé d'angulards.
Et alors ?
Je sais qu'on est de gulards.
On a pas du parle d'angulards.
Après, on va nous reprocher
de ne jamais parler d'angulards.
Absolument, c'est vrai.
Non, le projet évolue.
Oui, ça, oui.
Le projet évolue.
Il y a quand même beaucoup de boîtes
qui utilisent angulards.
Je vais en crener un petit peu.
Non, ils ont sorti.
Angulards suit le mouvement.
Ils ont enlevé la V1.
C'était fin septembre.
Du premier générateur...
Peut-être que j'ai une connerie.
Il y en avait déjà, mais il me semble pas.
De premier générateur de sites statiques
basés sur angulards.
Il s'appelle Scully.
Petit rappel pour les anciens.
Mulder et Scully.
Comment ça s'appelle, série, déjà ?
Je ne me suis pas suivi plus.
X5, oui.
Je sais pas si c'est un rapport.
C'est à ce moment-là
où on a perdu toutes les jeunes générations
qui n'ont pas connu X5.
C'est vraiment un podcast de vieux.
Ok, vous meurs.
C'est ça.
En tout cas, Scully,
c'est vraiment site statique
ou c'est pour aussi faire du service
à hydrant ring ?
Pour être très honnête,
je ne suis pas hyper
à l'aise avec angulards.
J'ai essayé Scully.
J'ai essayé d'installer et tout ça.
Voilà, je vais être honnête.
C'était galère.
Il fallait me manquer des trucs.
J'ai quand même réussi à le faire.
En gros, ce que j'ai compris,
j'ai l'impression qu'en fait,
Scully, ça se branche
sur un projet angular
que tu as déjà.
J'ai l'impression que ça se branche dessus,
que tu rajoutes une sorte de plug-in
et qu'après derrière, tu vas générer tes pages
avec... Je n'ai pas trop compris
comment ça fonctionne.
Après, les spécialistes angulars,
mais ça va.
Exactement.
Vous nous écoutez.
Vous êtes spécialiste angular.
Vous avez regardé Scully, appelez-nous.
Envoyez-nous un mail.
Vous allez sur le site du podcast.
Vous nous envoyez un mail
et venez,
on parle d'angular,
de l'évolution et de tout ça.
Ouais, c'est vrai qu'on dort.
Ça serait super intéressant.
Nous deux,
on n'est pas du tout à l'aise
sur Angular.
Ça nous ferait super plaisir
d'accueillir quelqu'un qui a un peu plus de recul
sur Angular.
C'est vrai qu'on aurait invité quelqu'un
pour nous parler d'angular.
On ferait peut-être un épisode
là-dessus pour l'évolution du framework.
Carrément.
OK.
Bon, on est tout au long.
On a des actualités,
même si il y a plein de choses qui vont se passer
début novembre aussi.
Oui, dans la communauté Vue et Nug.
Mais peut-être demain.
Ouais, je crois que c'est demain.
Je crois que c'est le 4 et 5.
C'est ça.
Il y a la Vue Toronto-Conf.
Du coup, elle émite.
On fera peut-être un épisode
pour faire un retour de toutes les annonces
qu'ils ont faits.
4 au 6 novembre, exactement.
C'est aujourd'hui.
Aujourd'hui, c'était les ateliers, je crois.
Et 5 au 6, c'est les conférences.
Comme tu l'as dit, on va faire
un épisode pour parler de Vue
et de Nug.
Très prochainement, après cette conférence.
Émanique.
Merci Patrick.
A bientôt.
Ciao.
Merci pour les prochaines épisodes
et références évoquées durant l'émission.