Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash.
Bonjour les devs, on va aujourd'hui, donc ce n'est pas un épisode de news, on va parler
aujourd'hui de Next.js.
Voilà, refaire un petit peu l'historique de Next.js, pourquoi il a été écrit, etc.
Donc refaire un petit peu le point et bah comme d'habitude, nous sommes avec Alex.
Salut Alex.
Salut Patrick, salut tout le monde.
Eh ben je suis super content de revenir sur toute la jeunesse d'un projet qui aujourd'hui
en fait est admis pour tout le monde.
Ça marche, c'est facile, c'est trop bien, ça nous facilite la vie.
C'est Out of the Box est devenu un standard mais c'est toujours bien de comprendre un peu
l'histoire de ce framework et de toute l'évolution technologique qui a eu derrière et je trouve
que tu as eu une super idée de revenir avec cet épisode-là.
Et même si je ne te cache pas que je ne suis pas un grand fan de React, néanmoins on ne
peut pas nier le fait que ça a marqué en tout cas en tant que Dev Web, ça a eu un
impact hyper, hyper, hyper fort.
Donc non, c'est top, c'est top.
Ouais, bah alors pour revenir avant l'idée, je l'ai eu tout simplement parce que en
fait je ne sais plus une personne à poser la question sur Next.js, vend mois à Next.js
et puis quoi pour Dubalk et tout ça.
Et puis j'ai regardé les réponses, tout ça.
Moi j'ai répondu, puis j'ai regardé les réponses et puis je me suis rendu compte
qu'en fait aujourd'hui c'est vrai que quand tu arrives dans le développement même depuis
trois, quatre ans tu vois, si tu as commencé la Covid à développer, tu n'es plus vraiment
junior tu vois, mais Next.js c'est facile, ça fait du et c'est serre tout seul machin,
ça marche en fait et finalement tu te dis ça a toujours été comme ça.
En fait non, ça a pas toujours été comme ça.
Donc c'est pour ça que je me suis dit mais en fait ça serait pas mal de faire un historique
sur pourquoi on a créé Next.js à la base mais vraiment pourquoi et quelle solution
il a apporté.
Et voilà.
Quel problème il résout tout simplement.
C'est ça en fait, parce qu'il a résouté des problèmes tels début en fait en 2016,
donc c'est pour ça.
Yes.
Donc voilà.
J'ai fait, oui pardon, je vais dire.
Non mais pour le coup t'as fait un truc où t'as récupéré en fait un peu tout l'historique
et t'as fait une sorte de timeline alors on mettra les deux sites et les deux sites que
t'as fait.
Par contre tu les as fait à la main ou ?
Alors le texte c'est mon texte.
Je n'ai pas généré par ailleurs ou quoi.
C'est pas moi qui l'ai écrit.
Je me suis fait assister un petit peu pour retrouver quelques infos mais alors ça je
l'ai fait avec Bolt.
Je lui ai dit fais-moi une timeline avec, je lui ai donné le bloc de texte ou ça, je
lui ai dit fais-moi une timeline et il m'a fait un truc tout pourri je trouve.
Je sais pas ce que tu en penses moi, je trouve ça super pourri avec des couleurs bizarres
et tout.
Ah ça fait le job, ça fait le job, on voit tout l'historique de la timeline.
Non c'est plutôt pas mal.
Il m'a fait un site en plus avec des liens bidons à propos et tout je sais pas, ça
me déconne.
Bon bref, voilà.
Donc c'est marrant quand même de faire.
Moi j'aime bien tester un peu, voir ce qui me sort et tout.
Donc ça c'est cool, ça c'est Bolt et après j'ai utilisé un autre outil, ça s'appelle
Gamma.
Donc tu connais aussi, c'est un système, alors ça c'est assez magique.
Il te crée des slides en fait, des présentations à partir de texte tout ça mais tu peux faire
aussi une donnée à un prompt.
Par exemple dans les exemples, fais-moi l'histoire de la tomate ou je sais pas quoi, la génèse
de la tomate ou je sais pas quoi, il te fait des slides sur la tomate avec des photos
de tomate et tout.
Donc là c'est cool parce qu'il te fait des présentations, il va chercher les images
et tout, il t'adapte un petit peu le texte et tout.
Donc c'est plutôt efficace.
Après c'est pas parfait, mais après j'ai pas passé deux heures dessus et j'aurais
pu peaufiner et tout mais c'est pas mal quand même, Gamma.
Ok.
Bah oui, c'est plutôt le rendu est super propre et on va s'appuyer justement là-dessus
pour parler du sujet du jour qui est Next Yes.
Et est-ce que toi tu te rappelles de la date exacte de la première version de Next Yes
ou pas ?
Ah tu me poses une col, je l'ai vu, c'est 2016 mais après exactement le mois, je sais
plus du tout mais…
Ouais c'est 2016, ça c'est sûr.
Donc il y a quasiment dix ans, la prochaine ça fera dix ans.
Ok.
Dix ans de Evolution, c'est clair qu'il s'en est passé.
Aujourd'hui on est à la version combien ? C'est quoi ? 15 ? 16 ?
C'est la 15, ouais.
C'est la 15.
Ok.
D'ailleurs, ouais du coup 2015 et puis…
Voilà, maintenant on en parlera la fin mais il n'y a plus de grosse révolution mais…
Yes.
C'est pas mal.
Et ok, allez si on attaque tout de suite et pourquoi en fait on a eu la jeunesse de Next
et pourquoi Next est apparu, pourquoi il est arrivé comme une solution évidente ?
Bah en fait tout simplement, alors déjà réacte, je rappelle ça a été créé en 2013,
donc ça fait déjà plus de dix ans.
Donc voilà.
Donc pendant plusieurs années jusqu'en 2016 à peu près, on faisait des SPA, donc
Single Page Application qui était exécuté dans le navigateur.
Évidemment dans le navigateur.
Donc on a rapidement eu une problématique, donc c'est cool de les SPA dans le navigateur
quand tu fais une anémie, tu fais un internet ou des choses comme ça, mais qui n'ont pas
besoin de SEO.
La problématique, tu la rapidement quand tu as besoin de faire du SEO et que quand
un robot qui va croller comme Google tout ça, il arrive sur ton site et il ajuste
un site vide en fait.
C'était le problème qu'on avait avec les SPA.
Donc il a fallu rapidement faire du SSR.
Donc ça veut dire générer l'application côté serveur.
Donc qu'elle soit rendue en marqueup HTML et pour que le robot puisse croller le contenu
et puis l'indexer quoi.
SSR Server Side Rendering.
Au moment où l'appel se fait, en fait c'est le serveur qui génère le HTML et notre
navigateur récupère le HTML directement déjà construit et donc beaucoup mieux pour le SEO.
C'est ça.
D'ailleurs il y a encore des gens qui pensent surtout des spécialistes SEO qui pensent
encore que les applications JavaScript ne sont pas indexables.
Ils sont restés là-dessus en fait.
Donc j'en ai des fois qui me disent non mais c'est déjà JavaScript, c'est pas possible.
Mais si, si, maintenant oui.
Donc voilà.
En 2015-2016, on avait...
Donc c'était possible en fait à cette époque-là de faire du SSR.
Alors à l'époque c'était principalement ré-accruteur qu'on utilisait pour faire
le routing au niveau d'application et on avait du Redux, des choses comme ça, voilà,
pour faire le state et tout ça.
Pendant longtemps Redux c'était l'outil principal pour le state management au niveau
de réact.
C'était le standard.
C'était le standard.
C'était le standard très très verbux etc.
Mais c'était le standard, il y avait quasiment que ça en fait au niveau de réact.
Ouais.
Et donc on pouvait faire du SSR.
Seulement c'était assez compliqué en fait.
Alors React avait dès le début implémenté une API qui s'appelait Render to String qui
permettait, côté serveur, de rendre l'application en souffrant la HTML.
Donc ça déjà ça marchait nickel.
La problématique c'est que dans ton application tu vas avoir différentes routes et forcément
différentes datas à injecter en fait.
Et c'est là où ça se complique parce qu'en fait il faut rendre le HTML avec les data
à l'intérieur.
Et là du coup ça devient compliqué parce qu'il faut trouver alors quelle route, quelle
data, les chercher, les faits de chez, des fois un asynchronous et en plus les injecter
et rendre l'application.
Donc les SSR ça se faisait mais ça devenait une complication au niveau de la gestion des
datas tout ça.
Donc ça se faisait et c'est pour ça que j'ai mis un exemple de projet.
J'ai donc il y a plus de 9 ans sur GitHub.
Voilà j'avais fait Universal App React donc voilà le projet à 9 ans déjà.
Donc ça c'est un exemple de ce qu'on faisait à l'époque avec du webpack, du Redux etc.
De l'express.js et on faisait un rendu serveur etc.
Mais c'était hyper complexe, hyper complexe, très verbeux, beaucoup de code etc.
C'était très difficile à maintenir.
9 ans quoi.
9 ans.
Ouais plus de 9 ans.
Ce repo à 9 ans quoi.
Ouais bravo.
Et donc c'est ce que justement quand Next.js est sorti parce que c'est justement ce que
Next est venu solutionner en fait.
La simplicité de faire du SSR.
C'est surtout ça en fait l'arrivée de Next.js qui est ce que ça a changé en fait.
Ok.
Voilà.
Donc en fait il faut se rappeler quand Next.js est arrivé les premières démos c'était
en fait les premières vidéos c'était, j'ajoute un fichier dans un dossier à l'époque
et c'était toujours le même c'était appages.
Ouais c'est ça.
Et tu mettais un fichier index et tu tapais en fait si tu faisais un retour, une fonction
de component React et tu avais de suite une page qui s'affichait slash la page d'accueil
et c'était hyper rapide donc c'était le file routing.
Ouais en fait c'est le file routing system qui est aussi venu révolutionner le truc
parce que à l'époque j'étais pas dans l'écosystème React mais j'étais dans l'écosystème
Vue mais la problématique était la même.
Ton VueRouter ou ton ReactRouter il fallait en fait t'avais un fichier énorme de JSON
avec où tu venais en fait mapper tu dis ok bah mon router tel URL tu vas interpréter
tu vas l'appeler comme ça et tu vas pointer vers tel composant et ce composant sera interprété
en tant que page.
Et ça en fait alors quand t'avais deux pages ça allait à peu près mais dès que t'avais
une dizaine de pages voire après quand t'avais des pages dans des pages ou en fait t'avais
une implication ok bah la catégorie ou la catégorie puis après l'article ou les choses
comme ça ouah t'avais un fichier de config qui était juste énorme et c'était un verbeu
et ta source d'erreur était mais juste monstrueuse quoi.
T'étais sûr de tromper une fois sur quatre et donc c'était l'enfer et là rien que le
fait de mettre le fichier le bon fichier dans le bon dossier et tout de suite s'est interprété
avec l'URL avec les paramètres avec et il est automatiquement interprété en tant que page
ouah mais ça c'était déjà game changer.
Ça c'est l'arrivée déjà le file routing c'est déjà énorme et aujourd'hui on aurait
bien sûr on aurait dit mal à s'en passer ça c'est clair.
Ah bah donc ça c'était la première feature qui est arrivée avec Next.js donc déjà
au-delà du SSR c'était déjà génial de pouvoir faire le file routing.
Ensuite on avait l'environnement en fait l'environnement direct.
T'avais un environnement de dev, un environnement de production où tu faisais un build et puis hop
c'était prêt à être déployé en fait donc ça c'était pas mal aussi pas besoin de config etc.
Et surtout un rendu côté serveur en fait on avait déjà voilà on avait donc on crée une
application React et on avait aussi du SSR automatique en fait on mettait ça sur versel donc
à l'époque qui s'appelait Now.
On déployait ça direct et en fait on avait une fonction qui s'appelait GetInitialProps
où on injectait les données qui devaient être dans le component et donc côté serveur
il récupérait ça il injectait et il rendait l'application déjà construite en fait.
Et c'était hyper simple en fait contrairement aux ripos que je vous ai,
qu'on a vu juste avant, le mon ripo qui était hyper compliqué,
voilà ça devenait tout facile en fait.
Donc c'était donc voilà quand on revient en 2016 c'est vraiment la révolution
ce nouveau système hyper simple à utiliser et faire du SSR facilement etc.
avec Direct.
Ouais et c'est là où en fait on y a eu un peu cette effervescence de tout l'écosystème JS
où ça annonçait vraiment une grosse révolution parce que
avant c'était vraiment mais hyper hyper complexe et hyper verbeux.
On passait des heures et des heures à faire de la configuration
et là en fait on respectait la convention et c'est un peu la doctrine convention
over configuration et donc on respecte la convention et ça marche tout tout de suite.
Et ça mais extraordinaire extraordinaire.
Et je rappelle aussi après on a eu la vague un petit peu JS fatigue
où justement on avait marre de faire de la config et on faisait passer notre temps
à configurer des tools.
Je rappelle que l'époque en 2016 on n'avait que Webpack, on avait Babel Webpack, Redux,
ceux qui étaient déjà développeurs à l'époque savent à quel point c'était compliqué
rinque de Webpack et tout ça avec les résolveurs.
Bref l'enfer.
Un gros point aussi qui t'as mis sur la slide c'est le code splitting
qui devient en fait un peu un nouveau standard.
Alors pour ceux qui ne connaissent pas le code splitting c'est vraiment l'idée.
On va prendre très très simple.
On arrive sur la page admin donc j'ai mon login et mon password et en fait
je vais récupérer toute mon application alors que je ne suis que dans la page de login.
Donc c'est un peu un non-sens et le code splitting permet de venir découper
chaque fichier sur chaque page et chaque page est récupéré au moment où on arrive
directement sur la page en question.
Ce qui fait qu'au lieu de récupérer un énorme paquet où il y a tout dedans
on vient récupérer de manière incrémentale ces petits bouts de code au fur et à mesure.
Et donc ça en fait on gagne des performances de ma boule parce qu'en fait on vient récupérer
que le fichier sur lequel on est.
Ce qui fait que quelqu'un qui ne navigue jamais sur la page contact par exemple
n'a pas le code contact récupéré en amont.
Alors que avant sans ce code splitting vu que l'application était construite côté client
il était obligé de récupérer l'intégralité du site parce qu'il était construit dans le
navigateur et là il s'affichait même si en fait la personne ne naviguait pas sur la page contact
il était néanmoins en fait le code était néanmoins dans son navigateur.
Et donc ça c'était une grosse révolution en termes de perf ça.
Oui oui c'était intégré direct donc tu avais ton code qui était en fonction des routes qui
était séparée et ça chargait au fur et à mesure.
Donc c'était aussi une fonctionnalité qui n'aide pas mais qui était déjà configurée,
qui était déjà prête à utiliser.
Mais ça nous apportera d'autres problèmes plus tard on en reviendra vers 2020.
Ensuite on avance donc voilà le framework évolue etc petit à petit.
On arrive en 2019, grosse avancée sur la version 9 en fait où on nous amène le système de
routing de file routing toujours mais où on peut mettre des files routines dynamiques.
C'est à dire entre crochet on va mettre des paramètres qui doivent récupérer et donc on a
des URL maintenant qui sont dynamiques et qui permettent en fait d'avoir une page qui
affiche différents types d'articles de blogs etc en fonction du slug ou des choses comme ça.
Donc ça c'est une révolution parce que ça amène pas mal de choses et ça simplifie aussi pas
mal le file routine.
D'ailleurs, oui.
D'ailleurs aujourd'hui tout le monde s'en est inspiré et on a quasiment ça sur tous les
frameworks front du système dynamique.
C'est exactement ce que je voulais dire c'est aujourd'hui c'est devenu un standard.
C'est vraiment le standard et on imagine difficilement comment on faisait avant.
Aujourd'hui c'est tellement confortable.
Mais ce n'est pas si vieux que ça en fait.
Ce n'est pas si vieux.
Non, non, ce n'est pas si vieux.
On parle de 2019 donc version 9 et il y a aussi une nouvelle fonctionnalité,
get server side props qui permet de récupérer des données plus simplement côté serveur pour la
Ensuite on avance 2020 donc là on a vraiment passé quelques années mais c'est après vraiment
ça va changer.
On arrive sur l'année génération statique.
C'est cette super hype.
Je rappelle qu'en 2020 on est début Covid, Gatsby devient hyper populaire.
Moi j'ai des fous de Gatsby en fait à l'époque.
La première version du site de Double Slash était en Gatsby.
Oui d'ailleurs oui c'est vrai.
Donc le statique devient hyper populaire parce que c'est cool, on fait des sites qui charge vite etc.
Donc NXJS se sent un petit peu obligé de s'adapter et de faire une fonctionnalité de
génération statique.
Donc c'est là où on a le ssg qui arrive sur NXJS.
On a des nouvelles API, get static props, get static pass et get server side props.
C'est des API qui permet de récupérer les data pour générer les pages et les déployer
déjà construite en HTML directement.
Donc là quand on déploie on a un site HTML.
Et Patrick est-ce qu'on peut faire une ellipse et de revenir encore plus longtemps avant.
Dans les années 90 on se rappelle que les sites statiques c'était le standard.
C'était un truc totalement basique où on avait du HTML et on déployait ça sur nos serveurs
qui à l'époque on déployait ça via FTP.
Et en fait la personne récupérait ce site statique et on naviguait.
C'était directement interprété dans notre navigateur parce qu'on avait rien besoin de faire.
C'était natif.
Et donc la grosse critique qu'on avait eue à cette époque là c'est qu'avec tout ce
mouvement qu'on appelait la jamstack, la JavaScript API markup où on venait
regenerer des sites statiques mais avec des outils modernes.
Donc en fait on utilisait les outils modernes type next, nukest et après astro et tout ça.
Mais pour faire des choses qu'on faisait déjà avant sauf qu'on les faisait différemment
et on a utilisé ces nouveaux outils qui nous permettaient de revenir sur du statique.
Donc en fait c'est comme si on refaisait ce qu'on faisait déjà avant mais avec d'autres outils
et l'approche était différente mais le résultat final lui est totalement identique.
Alors ouais le résultat final est identique quand on est...
Alors l'avantage c'est que avec les outils modernes tu es vite de...
Par exemple c'était un header, un footer tout ça, tout ce qu'est le layout et tout.
Tu vas éviter de le répéter c'est toujours le même qui va se se mettre dans toutes les pages
alors qu'à l'époque on avait vraiment une duplication de code où on avait des outils
comme Dreamweather, Frontpage et des trucs comme ça donc qui géraient ça tout seul.
Mais oui avec les outils modernes c'est beaucoup mieux géré.
Après tu as deux types de statiques, tu as le statique Astro et Hugo ou des choses comme ça
où c'est vraiment du HTML et quand tu cliques sur un lien la page est rechargée sur une autre page
alors que quand on prend du Gatsby ou du Next.js ou du Next,
une fois que c'est chargé la première page on passe en mode application.
Là tu vas naviguer dans l'application il n'y a pas de rechargement de page.
Tu as deux types de statiques.
Après chacun boise l'utilité de l'un ou l'autre mais il faut préciser.
Exactement. Et petit ellipse temporel là-dessus.
Ouais, on est assez vieux pour avoir connu pas les années 80 mais dans les années 2000 à peu près
quand on codeille au début.
Bref, donc ça c'est cool le statique prendre l'ampleur tout ça mais on arrive à un moment où on est bloqué.
D'ailleurs j'avais fait un article dans ce site jamstatique.fr.
C'était quoi déjà ?
Jamstatique.fr.
J'avais fait un article en fait parce que j'avais fait un POC pour un client avec qui je travaille toujours
qui était intéressé par le statique mais la problématique c'est qu'ils avaient beaucoup de pages
donc plus de 20 000 pages en fait d'articles en fait.
Et on s'est rendu compte que pour déployer au niveau de ce POC tout ça en fait c'était pas possible.
On ne pouvait pas déployer 20 000 pages c'est à dire que construire 20 000 pages au moment du déploiement
c'était beaucoup trop long, c'était beaucoup trop compliqué etc.
Donc ça ne matchait pas et souvent ça plantait même en 40 minutes le site n'était toujours pas déployé.
Enfin bref ça ne marchait pas et j'avais fait un article dans ce jamstatique.fr pour dire qu'il y en a un problème ça ne marche pas.
Et c'est là où est arrivé la génération statique incrementale.
Donc voilà.
Donc c'est une fonctionnalité qui est arrivée en juillet 2020 donc sortiez de confinement je crois.
Petit souvenir, désolé.
Next.js a implémenté ça en fait c'est tout simplement la possibilité de déployer un site sans toutes les pages de construite.
C'est à dire qu'on va déployer le site mais par exemple on ne va pas construire tous les articles du blog.
On ne va pas construire certaines pages etc.
On va le déployer et quand quelqu'un va arriver sur un article par exemple qui n'existe pas, qui n'a pas été construit
et bien Next va le construire, va construire la page et va la renvoyer.
Et ça en fait c'est une génération statique incrementale.
Ça permet justement de déployer des sites avec énormément de pages, énormément de data rapidement
et ensuite les pages sont générées à la demande.
Et ça c'était la réponse à la problématique justement de ne pas pouvoir déployer du statique en grande quantité.
Mais ça en plus c'est vraiment brillant comme approche parce que la première personne qui demande l'article est légèrement pénalisé.
Sa réponse est un petit peu plus longue.
Sauf que le résultat en fait il est caché, il est enregistré en cache.
Ce qui fait que la deuxième personne elle l'aura de manière instantanée parce que la page a déjà été construite.
Et donc ça c'est vraiment mes monstres puissants et malins parce qu'en fait on vient vraiment optimiser.
Par contre il y a un couplage assez fort entre l'applicatif et pour le coup le serveur et l'infrastructure où est stocké le site.
Parce que si on n'a pas l'infrastructure qui est en capacité de digérer et d'absorber ce type de fonctionnalité, ça ne marche pas.
On est bien d'accord.
C'est là aussi où Next.js est souvent réputé, Vercel est très bien, comment dire, il le vende comme ça.
Next.js fonctionne très bien sur Vercel.
Vercel fonctionne en mode serverless en fait.
Mais cette génération d'incrémentale en fait fonctionne très bien sur Vercel.
Après quand on est en self hosting, on va faire tourner sur un serveur avec du Node.js derrière.
C'est un petit peu plus compliqué et surtout pour la fonctionnalité suivante et je vais vous expliquer.
Puisque là, ça c'est cool, on sort des sites, ça génère la page à la demande mais on a une problématique.
La rédaction veut modifier un article.
Je change le titre ou je change la faute.
Comment je fais pour changer la page qui a été générée en fond ?
Elle a été générée, elle a été visitée.
C'est pas possible à l'époque.
Donc il faut redéployer le site.
Ou alors on peut mettre une date, précisons dans la génération d'incrémentale tout ça.
On pouvait mettre une date de péremption de la page pour qu'elle se rafraîchisse au bout de X-Temple.
Si la date est trop longue et que la personne a la rédaction modifier le texte, il faudra attendre qu'elle soit périmée pour être renouvelée.
Donc ça peut être long si jamais c'est une énorme faute dans le titre, c'est très gênant.
Donc en 2022, Next.js sort une fonctionnalité qui, pendant longtemps, est restée uniquement disponible sur Next.js.
Et c'est aussi un peu pour ça que des gros surversales.
Non, non, sur Next.js vraiment.
C'est une fonctionnalité qui est interne à Next.js, qui restait très longtemps, je ne sais pas si aujourd'hui il y a d'autres.
Je crois que Nox le fait maintenant.
Mais pendant longtemps c'était le seul framework de faire.
Et ce qui fait qu'il y a des gros sites, Booking.com, tout ça, qui sont sur Next.js, sont passés sur ce type de techno comme Next.js.
Parce que il y avait cette fonctionnalité.
C'est la revalidation à la demande.
C'est-à-dire, ils appellent ça le on-demand-ISR, incremental statique régénération.
C'est-à-dire qu'on va... Il y a un API, donc il y a les routes API.
On va pouvoir appeler cet API et dire un valide-moi 7 URL.
Un valide-moi la home par exemple.
Donc ça invalide automatiquement la home.
Et donc quand tu retournes sur la home, elle est régénérée automatiquement.
Et donc là on peut invalider les URL qu'on veut et donc rafraîchir les pages comme on veut.
Très propre.
Très très très très très puissant.
C'est vraiment lui.
Mais garantie.
Mais comme toujours, à chaque fois qu'on a là indirectement,
c'est un système de mise en cache de toute façon,
on est venu construire quelque chose et on l'a mis de côté pour que le prochain le récupère.
Intrasecment, de manière inévitable et immédiate,
ça amène le problème de comment on fait pour invalider ce cache.
Et donc ça c'est le fait d'avoir un endpoint où on peut dire
« Ok, bien celle-ci tu la dégages et tu invalides le cache.
Sans passer par la régénération du site, le rebuild et le redéployment,
ça c'est Game Changer, c'est clair.
C'est la fonctionnalité qui fait que c'était génial d'utiliser Next.js.
Surtout si tu as ton CMS, quand tu vas éditer une page,
tu as mis en place un webbook qui va appeler la pays et qui va dire « Cette page,
il faut la regenerer parce qu'elle a été modifiée. »
Et là, ça devient automatique et t'es tranquille.
Et surtout, je pense que c'était un énorme frein pour les gros sites
qui génèrent beaucoup beaucoup beaucoup de pages.
Sans cette fonctionnalité là, comme tu l'as dit, c'était pas possible.
Ah c'était bloquant.
C'était complètement bloquant.
Et donc grâce à ça, je pense que peut-être l'explosion de l'utilisation de Next.js
sur des gros sites de production est arrivée à ce moment.
Ah oui, c'est ça.
Sans surprise.
Carrément.
On avance encore un peu.
Donc on est toujours en 2022, mais on est en octobre 2022.
Gros sortis, grosses évolutions et grosses switches de Next.js.
Et pourquoi ? Alors déjà, on va commencer pourquoi il y a eu ce switch.
Tout simplement qu'en 2022, on arrivait à un moment où tout ce qui était bundle JavaScript, etc.
Parce qu'il faut rappeler que quand Next.js, NUX ou n'importe quoi se charge,
ils charge aussi une grosse partie de l'application.
Donc on a souvent un gros bundle.js de base qui est chargé.
Après, il y a l'hydratation.
Enfin, le browser va faire fonctionner l'application, etc.
Donc il y a tout un système de rendu de l'application qui est un petit peu long.
Parce qu'il y a beaucoup de JavaScript, etc.
Et là, on est devenu à un moment donné sur les tests de performance des sites.
C'était moins en moins bien noté.
C'était même pénalisé d'avoir beaucoup de JavaScript, etc.
Donc, on commençait à avoir un problème de SEO puisque les sites étaient un peu trop lent, etc.
Voilà, lent, pénalisé parce qu'il y a trop de JavaScript, etc.
Donc on a vraiment un problème à ce moment-là.
Et donc la solution, c'est ce switch complet de Next.js vers un nouveau système,
l'approuteur, donc c'est un nouveau répertoire appp.
Où on a un nouveau système de component, etc.
De route un petit peu plus complexe.
Et on a des serveurs component qui sont des serveurs.
Enfin, c'est des components par défaut maintenant.
Quand tu crées un component dans le répertoire appp,
c'est par défaut un serveur component.
Et pour que ce soit un client component, il faut marquer useClient en haut.
Donc on a tout un système, un nouveau paradigme, un nouveau truc à apprendre.
Malgré tout, le système Pgiz fonctionne toujours.
Et même aujourd'hui dans la version 15, il fonctionne toujours.
Donc les sites qui sont sur le système Pgiz continuent à fonctionner.
On peut faire les mises à jour et tout ça, mais normalement, tous les nouveaux sites que tu développes,
tu dois partir sur l'approuteur puisque c'est l'avenir de Next.js.
Voilà.
Donc ce que ça apporte, en fait, tout simplement,
les serveurs component, la première chose, c'est que parfois on a des components
qui sont là juste pour afficher du texte.
Il n'y a pas besoin qu'ils soient interactifs.
Donc autant avoir un serveur component qui va être là juste affiché.
Et celui-là ne sera pas inclus dans le bundle.
Donc ça va alléger le bundle.
Tous les serveurs component qu'on va faire, ils ne sont pas dans le bundle final.
Donc moins de JavaScript envoyés dans le navigateur.
On a un système de streaming.
Streaming, ça permet d'avoir certains éléments qui sont chargés par la suite.
Donc on charge rapidement la page.
Et ensuite, des petits blogs qui sont chargés ensuite,
donc qui ne sont pas importants, etc.
Qui ne sont pas forcément importants pour les CEO.
Et puis on évite tout ce qui est JavaScript inutile.
Donc c'est vraiment une version, la version 13, je crois.
Si je ne me trompe pas, c'est la 13 ou la 2, je ne sais plus.
C'est une grosse version.
Ouais, 13.
Et c'est une grosse version et ça vient aussi changer le paradigme, comme tu l'as dit.
Et je pense que c'est ça qui a été...
Ça n'a pas été de souvenir parce que ce n'est pas très, très, très vieux.
Ça n'a pas été très, très bien accueilli parce que ça a cassé quand même beaucoup les codes
et le paradigme initial changé.
Donc difficile à faire la migration.
La migration n'était pas facile.
Il fallait faire de l'éducation.
Il fallait accompagner ce changement pour comprendre l'intérêt.
La migration est quasiment impossible.
C'est-à-dire que tu dois quasiment réécrire ton application.
Parce qu'on n'est vraiment pas du tout entre les serveurs component et les clients component.
Par rapport à ce qu'on faisait avant, c'est rien à voir.
Donc il faut réécrire une bonne partie d'application.
Il y a plein de choses à écrire.
Il y a un nouveau système de fetch aussi qui est inclus avec du cache, etc.
Tout est changé.
En fait, ils auraient presque pu changer le nom de Next.js et faire un nouveau framework.
Parce que c'est tellement différent qu'on ne peut quasiment pas migrer un page.js à un app-router.
Déjà, ça s'était mal perçu.
On a déjà vu d'autres frameworks où ça s'est passé comme ça.
Ça s'est mal passé aussi sur Angular.
Quand tu as un truc qui marche bien et tout, on te dit qu'il faut tout changer.
Tu comprends pas.
Pourquoi je vais tout changer ?
C'est trop proye.
J'ai des sites de clients qui sont toujours sur le page-router.
Et ce n'est pas prévu que ça change de suite.
C'est tellement de travail et de budget qu'ils n'ont pas prévu.
Tant que ça marche, on l'utilise.
Il y a beaucoup d'évangélisation.
On voit que Versel depuis fin 2022, ils sont à fond dans les vingéliations.
Espiquer les serveurs component.
Il y a encore des gens qui ne comprennent pas comment ça marche.
Ça a été une super...
J'ai déjà fait des sites avec l'app-router.
C'est top du top.
Mais c'est devenu beaucoup plus compliqué.
Il y en a beaucoup de personnes qui ne comprennent pas comment ça fonctionne.
Et c'est très compliqué.
Versel depuis fin 2022 fait beaucoup d'évangélisation de tutos.
Avec leurs relations développeurs.
Mais il faut éduquer surtout sur des changements de paradigme comme ça.
Ils n'ont pas le choix.
Donc il y a grand coup, il y a grand renfort de devrais,
de vidéos YouTube,
de sponsorisation d'événements,
de formation, de tout ça.
Pour justement expliquer ce paradigme-là
et quel est le bénéfice sous-jacent.
Parce qu'un développeur qui ne comprend pas pourquoi il doit tout réécrire son application
ça va être difficile pour lui d'aller demander de l'argent à son client
ou d'aller justifier à son project manager, à son CTO ou à son CEO
en disant qu'on il faut qu'on change tout.
De manière très pragmatique, à quoi ça va servir, ça marche, ça fonctionne.
Ok, mais si on a une vision à long terme
et on est en capacité d'expliquer le bénéfice sous-jacent de cette migration
ça sera plus facile d'aller vendre cette migration.
Et donc d'où l'importance de bien comprendre les tenants, les aboutissants
des évolutions possibles
et de la rupture que ça a amené à ce moment-là.
Clairement.
Voilà, donc dernier slide, c'est...
Vous avez un détail ?
Ouais, c'est ça.
Depuis fin 2022, comme je l'ai dit,
donc l'évangélisation, tout ça
mais depuis il n'y a pas eu de grosses versions,
donc on a 13, 14, 15, on a la 15
et les migrations se font sans problème.
C'est juste des améliorations de performance, des optimisations,
quelques néboles API, mais on n'a pas de gros changements
et comme je le dis, là, Versel, ils passent leur temps à évangéliser.
Simplement.
Mais voilà, l'historique en gros de Next.Jazz.
Après, il y a aussi ce couplage
avec l'infrastructure qui est quand même toujours un peu intéressant
et voilà, souvent on va mettre ça sur un serveur classique.
Soit aujourd'hui, il y a le serverless
qui a été justement poussé par Versel, tout ça
et il y a aussi cette notion de edge,
donc de edge computing où on vient du serverless
ok mais du serverless, ce n'est pas sans serveur,
déjà, mais ça va exécuter du code
sur un bout de serveur quelque part.
Sauf que ce serveur-là, potentiellement,
il peut être loin de notre utilisateur final.
Et aujourd'hui, Versel qui avant était juste des CDN classiques
ou en fait, c'était des énormes SSD partout dans le monde.
Maintenant, en fait, on va pouvoir exécuter du bout de code
parce que le runtime, donc l'exécution de ces JavaScript,
maintenant peut se faire sur des plus petits serveurs
qui sont proches de l'utilisateur.
C'est ce qu'on appelle le edge, le edge runtime.
Et donc, le fait de passer sur ces routers,
sur ce approuteur et donc sur ce SSR par défaut
va nous permettre aussi de déployer au plus proche de l'utilisateur.
Et donc, en fait, c'est à la fois un gain pour l'utilisateur
mais aussi pour l'infrastructure qui va être répartie
et déployée partout.
Et donc, il y a toute cette effervescence du edge
et aujourd'hui, on voit avec les runtime qui peuvent se mettre partout.
Next en fait profite aussi de cette évolution d'infrastructure.
Alors, justement, Next, par rapport à...
Si on prend une Next, par exemple, Next, j'ai retrait mal.
Enfin, tu n'as pas de provider comme ça.
Tu ne peux pas changer facilement de provider.
C'est le défaut de Next.
Oui, mais clairement, quand tu vas sur Versel,
oui, c'est du edge, plus ou moins, serveur less machin, CDN.
Par contre, c'est difficile d'aller sur Cloudflare avec un NXJS
ou des choses comme ça. Après, tu peux l'héberger toi-même.
Là, tu passes sur du node. Je n'ai oublié d'en parler.
Mais justement, l'ISR, l'invalidation des pages avec la Pays,
ça pose des problèmes.
Parce qu'en fait, pour la petite histoire,
on est sur Scalingo, on peut faire plusieurs instances,
donc plusieurs Next.
Problematique, c'est que tu vas invalider une URL
sur un des conteneurs et ça ne va pas répercuter sur le conteneur.
Donc en fonction duquel conteneur t'es envoyé quand tu arrives sur le site,
tu auras la ancienne page ou la nouvelle page.
Et là, ça devient compliqué.
Ça veut dire qu'il faut commencer à gérer le cache des pages sur A10
ou des trucs comme ça. Et voilà.
Et là, tout se complique.
Voilà. Pour ça, un NXJS n'est pas super flexible
en dehors de Versel.
C'est aussi le défaut souvent qu'on reproche un NXJS
d'être trop couplé à Versel.
Et dernièrement, ils ont fait des annonces, justement,
qu'ils allaient améliorer ça et être un peu plus disponibles
pour le Edge et tout ça.
Là, c'est des annonces qu'il n'y a pas longtemps.
C'est plutôt bien. Après, il faut aussi être lucide
sur le fait qu'aujourd'hui, la grosse partie de l'équipe
qui développe Next,
tout le monde travaille chez Versel.
Oui, beaucoup.
Donc, bon, peut-être qu'ils ont...
Oui, alors à la fois, c'est normal,
mais c'est un choix qui est aussi dangereux.
Mais je pense que ce risque est calculé
dans la mesure où aujourd'hui,
l'implémentation de React et de Next
sur le marché de la production, elle est énorme.
Donc, en fait, je ne veux pas dire qu'ils sont en Monopoly
parce que ce n'est pas vrai,
mais ils ont des parts de marché
assez grandes, significatifs,
en tout cas pour pouvoir tordre un peu la main.
Peut-être qu'ils y sont allés un peu fort.
Et donc, maintenant, ils sont obligés
de ne pas de rétro-pédaler,
mais d'être un peu plus conciliants.
Et donc, c'est plutôt...
Oui, ils sont un peu obligés,
pas pour l'image, etc.
Après, c'est très dangereux.
On en parle souvent de la gouvernance des projets,
parce qu'en fait, finalement, c'est Versel
qui décide de ce qu'ils vont faire,
de dans quelle direction ils vont aller.
C'est très dangereux et on a un exemple très récent
avec WordPress,
où le boss d'automatique,
Moulin Mwag,
a pété un câble à un moment donné,
et c'est parti en vrille complet.
Et pourtant, c'est un projet open source,
mais il y a une gouvernance d'une société privée
sur le projet.
Et là, on a le même cas avec Versel.
Alors, pourquoi pas Guillermo demain,
il peut peter un câble et puis...
Il a pu envie.
Bien sûr.
Super.
Maintenant, la priorité, c'est LIA,
et on s'en fout de NaxiS,
et puis peut-être, on ne sait pas.
Donc, voilà.
C'est toujours un petit peu dangereux, le mélange,
comme la société privée et le projet open source.
Yes.
Top.
Merci Patrick,
pour ces explications
d'un épisode
un petit peu particulier,
parce que, voilà,
on reprend un peu l'histoire
de Next,
et je pense que ça nous amène
une meilleure compréhension
de l'outil qu'on utilise
quasiment au quotidien pour beaucoup.
Et donc, comprendre
tout son historique, en fait,
nous aide à encore mieux savourer
le plaisir qu'on a à l'utiliser
et toutes ces fonctionnalités
qui nous dévient, en tout cas,
nous solutionne la vie
et nous facilite la vie grandement.
Donc, ça, c'est top.
On fera un Next.
Un Next.JS, peut-être.
Alors, on fera, il était une fois un Next.JS,
ouais, carrément.
Et...
Choffin pour me donner l'historique.
Carrément.
Un grand merci à tout le monde
d'être restés jusqu'au bout de l'épisode.
Comme d'habitude, un petit pouce, un petit like,
un petit commentaire,
que vous soyez sur YouTube
ou sur votre application de podcast.
Discuter
de l'épisode avec vos collègues,
ça nous fait toujours plaisir.
Et pour ceux qui le peuvent et qui le veulent,
vous pouvez aussi nous soutenir
sur le GitHub
sponsor de l'émission.
Et on mettra toujours, évidemment,
tous les liens sont dans la description.
Un grand merci à tout le monde.
A bientôt. Ciao, ciao.