Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur un nouvel épisode de Double Slash, je suis Patrick et comme
d'habitude nous sommes avec Alex.
Salut Alex !
Salut tout le monde, salut Patrick !
Alors aujourd'hui épisode un peu particulier, j'ai envie de dire, tu sais Alex quand on
a lancé le podcast pendant le confinement en 2020.
J'aurais jamais cru aujourd'hui avoir cet invité clairement et c'est plutôt une bonne
surprise et aujourd'hui notre invité c'est Sébastien Chopin.
Donc salut Sébastien !
Hello tout le monde, c'est un plaisir de participer à ce podcast avec vous.
C'est un plaisir pour nous aussi.
Oui carrément, carrément et juste pour la petite histoire en fait le truc c'est que
moi à l'époque j'étais rubiste, je faisais que du rubien de rails et en fait je suis
je suis tombé sur une vidéo sur coup d'état non c'était pas sur 2Family où justement
tu présentais NUXT et avec ton frère sur un powerpoint tout blanc avec des gros slides
et tout machin et je vois cette vidéo parce que j'étais pas en live, je vois cette vidéo
et je ne comprend rien du tout à leur truc.
Je ne sais pas ce que c'est.
Je ne sais pas c'est quoi vu je sais que ça existe mais j'ai à moitié regardé et
je suis une vraie lange à la script et pourtant je me dis ce truc ça a l'air trop bien et
aujourd'hui donc je sais pas combien à quelle date ça amène cette vidéo enfin je pense
que tu dois te rappeler de cette vidéo à The Family non ?
Oui oui c'était je me rappellerais toute ma vie, c'était le meetup juste avant la
DogeyS où je devais faire un lightning talk et Eduardo le mainteneur de Vue Router avait
fait un meetup la veille à The Family et il y avait Evanue la première rangée où je devais
présenter le framework pour la première fois, premier talk avec Alex et il est atroce quand
j'aurais voie aujourd'hui, je ne comprend rien non plus t'inquiète.
Mais celle-là où c'est trop fort c'est que moi je pique rien et j'étais là en mode putain
ça l'air trop cool je veux faire ça quoi et tu vois et aujourd'hui je fais que du Vue,
je fais que du next, mais clairement je fais que ça et je suis ambassadeur dans l'âme
vraiment parce que je suis fan et du coup c'est un grand plaisir et franchement c'est super cool
que tu viennes sur Double Slash donc vraiment merci de t'avoir venu.
Franchement merci parce que je ne savais même pas que tu faisais du next,
tu me prends de cours là.
Cool et on attaque, on va dire pour ceux qui ne connaîtraient pas next est-ce que tu peux
le présenter vite fait et peut-être te présenter toi sur ton background,
tout l'historique entre toi et nukes.
Oui, pour ma part Sébastien je viens des montagnes donc lourdes tarves dans les pirénées
et j'ai commencé la programmation en PHP qui est un super langage avec mon frère,
il avait eu des idées, j'avais 14 ans j'avais fini le site du zéro pour le PHP,
il m'a dit viens on va faire un site de jeu pour gagner un peu d'argent et c'est comme ça que
je suis tombé dans la programmation et gros coups de cœur pour PHP après étude
Epitech, j'ai fait un nom d'Epitech et je rejoins une startup en tant que stagiaire pour
faire du Node.js et c'est là où ça a commencé l'amour du JavaScript alors j'avais déjà apprécié
avec Ajax et le fait de rendre des sites PHP un peu plus dynamique et j'ai commencé Node.js en 2011
en version 0.4, gros parier on devait faire du Ruby, perso j'avais réinvité à Ruby,
pour moi les JavaScript c'était simple, je me suis dit ok je ne suis pas aussi bon que je le pense
mais les JavaScript ça collait bien et une Node.js et je me rappelle j'étais avec deux autres Français
Nicolas Naulir je croyais Philippe Charrières, on disait trois blogueurs à parler de Node à l'époque,
gros fans et je faisais du backbone.js à l'époque pour la partie web app.
Et c'était l'époque où Node était en pleine effervescence où il y avait des librairies
qui popaient dans tous les sens, des méthodes, il n'y avait pas 5 wait à l'époque, c'était
l'anarchie, enfin c'est pas l'anarchie mais c'était l'effervescence, les effervescences
totale. Et c'est là où je tombais dans l'open source aussi, j'avais créé le Toulouse.js à l'époque,
le Meetup que j'organisais à Epitech, c'est très facile et la découverte des modules NPM,
explications de Node, Elasticsearch, MangoDB et en faisant un city commerce à l'époque,
on avait eu l'idée de faire tout le front en backbone.js en mode app et de mettre le rendu
côté serveur et c'est là où ça a commencé, on était quoi en 2012-2013 et on était parti sur
une solution, Phantom.js pré-rendering, un effet un framework qui s'appelait crawlable,
qu'on a supprimé depuis, impossible à utiliser et pré-rendering on péchait tout vrai système
d'authentification, enfin c'était overcomplex. Du coup j'avais lâché l'affaire, on était
parti sur un site Node qui tourne toujours depuis, mais c'est comme ça qu'on était arrivé à Nuxt.
Mon frère m'a dit, « ben backbone c'est fini, il va falloir passer sur Vue ou React,
moi m'en choisi de partir sur React, parce que backbone tout le monde disait React,
j'ai eu la doc de React, je voyais à peu près ce qu'on pouvait faire, c'était cool,
mais je trouvais que c'était un peu over engineered, il y avait Angular qui était super sexy à l'époque,
mais Alex m'a parlé de Vue et j'ai commencé à doc de Vue, je me la suis lu en une nuit,
je me rappelle j'étais en Irlot, j'ai nommé à Artgegen S, à me lire la doc de Vue sur mon
téléphone, j'ai fini à 3h du matin, j'ai trouvé ça juste fantastique, il y avait la bonne
développeur expérience, les belles performances, et du coup je suis parti dedans Vue, on s'est donné
le challenge de refaire ce site e-commerce qui est d'ailleurs Maléa Massage, c'est un site
de vente de table de massage en ligne, avec Vue et du rendu côté serveur, et on était parti dedans,
moi à l'époque je regardais beaucoup, j'étais pas mal sur Twitter, je regardais ce que faisait
hierment puisqu'il a fait Soket.io à l'époque, il avait Mangouze et j'ai écrivé des articles
dessus à l'époque, et un soir il a écrit sur Next, et moi j'avais déjà refacturé ce site,
e-commerce avec Vue, le rendu côté serveur, et on s'est dit je me suis donné le challenge de
refaire Next en uxt, parce que moi je faisais du Vue et pas du Rect, et une semaine après quelques
abondants, c'est sorti une nuit, j'ai trouvé la solution, et je crois deux semaines après,
d'autres GS, je rencontre Evanue et on en revient au meeting de famille.
Il y avait déjà le... ça c'est vraiment la jeunesse quoi.
Ouais, je pourrais pas faire ça aujourd'hui.
Il y avait déjà le rendu serveur sur Vue quand t'as commencé Next ?
Ouais, alors il y avait qu'un exemple, c'était, et c'est grâce à ça que j'ai pu le faire,
c'était l'exemple de Acornews, qui avait fait Evanue, donc il y avait une config webpack de prête,
il y avait quelque chose qui fonctionnait, et je me suis dit je vais me baser sur ça pour les
configs, et je commence à autogénérer la config du routeur pour les pages, du coup ça ressemblait
à du PHP, et petit à petit on a ajouté plein de features, et après c'est là où on s'amusait
avec une bataille contre Next, puisqu'on avait les routes dynamiques avant, eux ils ont sorti d'autres
trucs, etc. Mais une compétition positive, franchement on se pousse vers l'avant, parce qu'à la fin c'est
pour les étudeurs finaux et pour les développeurs qu'on fait ce projet.
Ouais, carrément. Et du coup est-ce que, parce que là tu nous parles de, il y a quand même une
perte d'année, est-ce qu'aujourd'hui cette gigueur, mais en fait je veux dire cette motivation,
ce challenge, le fait de se tirer l'avoure avec Next, est-ce que c'est encore le cas,
est-ce que ça reste bon enfant, ou c'est quoi, en fait qui inspire l'autre ?
Je dirais que les deux s'inspirent, enfin en tout cas de nous, on s'inspirait pour leur côté
simple, en termes de features, nous on est persuadés qu'on pousse l'engin beaucoup plus loin
que Next, qui sont un peu plus bridés, et c'est ce qu'on a poussé vraiment avec Nuxt3.
Il y a des features qu'ils ont, qui sont peut-être plus propres à React ou Webpack,
nous on essaie d'être le plus modulaire possible, ça nous fait avancer des fois un peu plus lentement,
surtout quand on veut gérer des déploiements et vraiment, on va dire le Linux, d'un point de vue
Web Framework, donc vraiment cette vision en termes qui peut être intégrée partout.
Après c'est du marketing, je dirais, mais je connais le moteur de Nuxt,
je connais le moteur de Next, on est pas mal, on est pas mal franchement.
T'as pas du toit rougir quoi, c'est ça ? Non, non, certainement pas.
Ok, est-ce que tu as des chiffres à peu près, aujourd'hui tu, alors il y a la version 3 qui est
un peu des chiffres clés sur une sorte de track record, et en fait à quel moment il y a eu
une sorte de basculement quoi, la version 1, la 2, à quel moment de la 2, en fait,
quelles sont, c'est quoi les gros moments de vie de Next ?
Alors les totes je ne me rappelle pas bien, je me rappelle des releases en effet,
la 2, je me rappelle que Jériz a vu l'endonne en live, j'ai fait le NPM publish en live,
je ne sais pas pourquoi je me donne ces challenges, et c'était presque un moment...
Faut être confiant, faut être confiant.
Graveux, pire moment et meilleur moment en finale, c'est la prise du risque.
On avait mis Webpack 4 à l'époque, donc c'était un petit break-in change,
il n'y a pas eu de gros break-in change entre NUX1 et NUX2, la première version était en novembre,
je crois 2016, et en fait on avait un écosystème de module, enfin on a toujours un écosystème
de module, et on a pu faire des releases de nouvelles features de NUX via les modules
sans devoir faire une release de NUX, ce qui nous a permis de grossir, donc si je devais
compter les étapes majeures, ça va être des sorties de modules, le module d'autantification,
même des fois des modules pour des CMS, le module content par exemple, qui a aussi une belle traction,
PWA c'est vraiment et même image aujourd'hui, c'est vraiment tout un écosystème qui pop des
releases, donc difficile à traquer. En termes de sur le projet, si on part sur NUX2,
pardon, pas parce que NUX3 c'est bien à peine de sortir, c'est combien le nombre de donnaux de
total, le nombre de stars. Alors, sur NUXT.js je reconnais 38 000 stars, je me demande des
stats comme ça, comme si je les connaissais par cœur. Si en plus, mais je veux pas dire
de bêtises maintenant. Donc sur les stars, on a 38 000 aujourd'hui, on aurait eu que d'avoir
3000 sur le NUX3 en quelques semaines, téléchargement, voilà on a 400 000 weekly, donc du 1 million 6,
c'est pas mal. Je crois que pour l'année tente on a dépassé Gatsby le mois dernier,
mais c'est tricky les téléchargements, franchement c'est spécial, moi là je regardais aujourd'hui
WAPALISER qui en plus on a un peu leur site, leur stats, NUX.js on est à 49 500 sites,
globalement 50 000 et NEXT ils sont à 90 000, donc 40 000 de plus, ce qui est pas mal sachant que
pour REACT, c'est une grosse communauté. Est-ce que tu as un exemple de gros site qui
utilise NUXT aujourd'hui ? Alors j'ai déjà entendu des grosses conneries dans d'autres podcasts,
alors je vais pas balancer les noms du style que vu tout ça c'est pas fait pour des grands projets
etc. On va pas revenir là dessus. Et aujourd'hui il y a des grands noms, des gros sites qui
tournent avec NUXT, je sais qu'il y a l'équipe.fr normalement. Ouais, j'avais bossé avec eux parce
qu'ils faisaient du Vue et du pré-rend de Ring et forcément il y avait le flash, il y a pas l'interaction.
Ça s'est super bien passé, ils ont fait l'immigration rapidement. Après ils ont
France Football, Journards du Golf je crois, qui sont aussi à côté. On a Back Market qui est une
star web française qui est un peu connue, qui est qui TisNUXT, on a la maison du monde aussi qui
nous suit depuis le début, c'est vraiment cool. Après on a Louis Vuitton qui est fait
en NUXT, je trouve les sites français, vu que nous on est auditeurs sans français, je vais essayer
de trouver des Canadiens peut-être ou les Québécois. On a FranPrix qui est sorti récemment,
Gucci, Levan, Skarmine. Après il y a tout sur NUXT.org, Chocaze et on a aussi le
petit Vue Telescope qui permet de lister publiquement tous les sites qu'on détecte avec Vue,
NUXT et les autres. Il y a le Poirc aussi c'est vrai.
Est-ce que tu penses que toute la communauté qui a derrière Vue aujourd'hui est-ce qu'on peut la
dissocier Vue, NUXT ou toute l'attraction qui a sur Vue, elle est bénéfique pour NUXT
inévitablement, mais est-ce que la passation entre Vue et NUXT se fait facilement pour les
utilisateurs et à quel moment tu dirais qu'il faut passer sur NUXT ?
C'est une très bonne question. Aujourd'hui, NUXT on connaît les téléchargements, on reprend
15% des téléchargements de Vue. Après, téléchargement est toujours difficile puisque Vue, je peux
l'utiliser aussi comme un sidienne, pour les développeurs Vue, il y a quand même une majorité,
enfin il y a une grande partie qui utilise Vue pour dynamiser des sites qui sont rendus côté
serveurs avec d'autres langages, un petit peu Django, Laravelle, la Ravelle a fait une énorme
option sur la comité Vue au départ. Ils ont déjà du rendu côté serveur,
mais ils n'ont pas besoin d'une single page app, même si le terme est un peu spécial.
NUXT, c'est vraiment si tu veux partir sur une toute nouvelle expérience utilisateur où tu vas
avoir le rendu côté serveur qui sera géré par NUXT et toute la navigation qui se fera côté
client. Ça permet aussi la séparation de concerns, il va y avoir l'équipe backend qui va
faire l'API, qui peut être utilisé pour du mobile et qui peut être utilisé pour l'application Web,
ce qui permet d'avoir juste une team front-end qui peut développer ultra rapidement. L'idée de
NUXT c'est de simplifier au maximum pour avoir le moins de configuration possible pour faire un site,
et on peut se localiser directement sur les features implémentées sur la partie produit,
qui est normalement la plus sympa à faire en tant que développeur.
C'est clairement, enfin moi ce qui m'a convaincu, pour le coup on a déjà fait des confs avec
Patrick où on prenait le micro et on expliquait pourquoi justement on était passé sur NUXT,
parce que justement on avait marre de faire de la configuration du Vue Router qui est sympa,
mais quand on a fait 2, 3, 4 et quand on commence à avoir 20, 30, 40 pages, ça devient très compliqué
et on passe notre temps à faire de la config et clairement c'est pas du tout marrant.
On parle pas de la config webpack, PCSS, etc. Exactement, on n'a même pas abordé encore le sujet
juste du moteur ou ton rendu, comment tu configues et tout ça. Là c'est vraiment hyper,
enfin moi je trouve l'expérience straightforward, BIM on se prend pas la tête, tu veux dynamiser
avec tes params et tout ça, t'as vu META qui est implémentée directement, tu peux variabiliser
tes haides, le contenu de ta balise HTML-Head dans ta page pour avoir ton SIO nickel.
Aujourd'hui en fait moi j'ai du mal à voir si on veut faire un projet un peu ambitieux avec tout
en vue. Clairement je vois difficilement l'intérêt de rester sur une Vue CLA et classique,
alors que NUXT faciliter la vie sur plein de choses.
C'est ça, on fait tous les trucs chiant à votre place.
Dernièrement ça rend finir en fait NUXT parce que dernièrement j'ai refait deux widgets en vue,
j'avais oublié comme c'était chiant à configurer, tu veux mettre le store,
ça faut tout faire alors que normalement dans NUXT tu n'as rien à faire, tu fais ton store,
ça marche tout seul. Je retourne là sur les projets maintenant Vue 3 avec VIT,
c'est super avancé de toute façon, nous on est là pour simplifier,
faire en sorte que ça marche bien, sans truc de configuration. J'ai regardé un projet VIT,
ça reste quand même le VIT.config, il commence à piquer. Et on est là justement pour simplifier.
Franchement c'est cool, on est là pour s'entraider,
je sais que beaucoup de la core team de Vue utilise NUXT dès qu'il faut faire des projets,
parce que même eux ils n'ont pas forcément envie de reconfigurer à l'éternum leurs projets.
Et tu vois moi je viens de la communauté Ruby & Rails,
aujourd'hui je ne fais plus du tout de Ruby, du coup je vais me faire lyncher par tous mes anciens
potes, parce que pour eux je suis passé du côté JS, c'est mal, exactement,
c'est le côté, mais qu'est-ce que tu fais, tu peux qu'importe, j'assume pleinement.
Mais par contre, n'est-ce que j'ai vraiment retrouvé,
et ce qui m'a fait aimer NUXT, c'est vraiment le convention over configuration.
Tu respectes la règle, tu respectes les nommants que la ture, et pof, ça marche.
Et du coup ça en termes de développeur expérience,
et je pense que, enfin tu m'arrêtes si je me trompe,
mais moi j'ai vraiment l'impression en fait que ça transpire chez vous,
justement où vous voulez en fait délivrer la meilleure expérience développeur,
l'expérience de développement, pour sortir une app,
et qu'on se concentre vraiment sur des choses qui ont de la valeur,
et non pas sur de la config.
C'est ça, franchement, pour moi, NUXT, dès que je l'utilise,
et que je vois quelque chose que je dois configurer,
ou qui pourrait automatiser, en fait, ça me semble indispensable,
parce que c'est des tâches chronophages, et l'auto importe,
c'est vraiment ce que j'équipe le plus, et dans NUXT 3, l'auto importe partout.
Et alors, plus, pousse avec toi sur le auto importe,
et le lazy, le lazy, mais ça c'est juste magique aussi.
Alors pour ceux qui ne connaissent pas la fonction ULazy,
tu m'arrêtes si je dis une énorme connerie, Sébastien,
lazy, ça nous permet d'importer le composant que quand on a mis la condition requis.
Et donc, ça vient augmenter la performance,
et on ne vient pas charger le DOM, et on ne vient pas charger notre app
avec des composants qui ne sont pas achetés.
Exactement, j'avais fait une démo à l'époque, je crois, en 2017,
d'un chat type messenger, et selon le message que tu recevais,
imagine, on reçoit une vidéo, on allait charger dynamiquement le chunk,
donc j'avais script du composant vu, pour la vidéo,
et après on ouvre une adresse maps, là on va aller charger un autre chunk.
En fait, on commence avec une app qui est la plus minimale possible,
et c'est aussi ce que j'utilisais avec NUXT comme headline,
c'est Sexy with Performances, parce qu'on est quand même fou de performance,
et on suit Vanu, vraiment pour avoir les app les plus optimisés,
ça pourrait être toujours plus optimisé, il y a un moment après il faut faire un choix,
mais surtout avoir un beau mix des deux, tu sais que quand tu utilises NUXT,
tu vas avoir une app qui est optimisée par défaut,
on va essayer de te guider au maximum pour respecter les best practices,
et en plus de ça, tu kiffes tout le long,
c'est rendre la vie des développeurs agréables pour l'univers JavaScript, en tout cas.
Là tu parles des... pardon, vas-y ?
Vas-y Patrick, vas-y.
Tu parles d'Evanu, qu'est-ce qu'il en pense, Evan, de NUXT ?
Clairement.
Il déteste, il m'a dit qu'il ne faut pas le voir.
C'est quoi cette saloperie ?
Non, franchement, on a une super relation, en plus on a fait beaucoup de conférences,
donc on a aussi créé ce lien d'amitié, on a été aller voir Match & Billet,
on a fait des carroquets, donc on s'apprécie déjà en tant que personne,
après il faut venir en conférence pour voir ça en vrai,
mais on s'apprécie en tant que personne,
et nous on a de l'admiration pour ce qu'il fait, pour ce qu'il pousse, dans le web,
et je pense qu'il kiffe bien aussi ce qu'on fait, on se fait des appels,
il nous aide à chaper NUXT3 en beta test suspense,
je pense que, et c'est ce que j'aimerais dans le long terme,
c'est qu'on puisse contribuer plus au corps de vue,
et surtout vue 3, ce qui sera beaucoup plus facile une fois que NUXT3 arrivera à une maturité,
mais on est là pour s'entraider et pour montrer que vue est NUXT3,
mais principalement vue derrière, et un beau compétiteur aux autres frameworks que j'ai inscrit.
Ah grave, ouais.
Non mais nous on en est convaincus, ça c'est clair.
Là tu parles de NUXT3, il y a la beta publique qui est sortie,
aujourd'hui on voit, je ne vais pas dire qu'il y a un schisme,
mais il y a deux manières de faire dans vue 3,
il y a vraiment l'option API, on va dire l'héritage de vue 2,
et cette nouvelle approche avec la composition API,
qui est en fait un parti pris, assez fort en fait,
parce que c'est une autre approche, c'est une autre manière de faire,
qui est pour le coup un petit peu plus implicite,
et donc on va réduire la syntaxe, on va réduire plein de mots,
ça s'est encore plus configuré direct,
si on respecte bien les conventions,
je pense voilà le script setup, tout ça, avec l'auto import, et tout ça,
super.
Par contre, est-ce que ça ne vient pas casser un petit peu le côté
hyper accessible que pouvait avoir vu dans la version 2,
avec son option API qu'on appelle maintenant sur vue 3 ?
C'est une excellente question, et la réponse est très difficile du moins pour Evan,
parce que quand on a parlé, lui, s'il pouvait,
il ne disait que la composition API, et moi aussi,
parce que quand on prend le concept, on voit tout ce que ça peut débloquer,
techniquement, après pour la proposité du code,
c'est peut-être moins visible,
moi honnêtement, je suis un grand fâtre de l'option API,
et petit à petit, dans Nuke 3,
je me rends compte qu'on peut écrire moins pour faire plus,
avec la composition API, et si on visite la simplicité,
toute une question de comment on va éduquer les utilisateurs,
et quand on voit par exemple vue use avec l'auto importe Nuke 3,
en fait, ça va nous enlever énormément des pines du pied,
c'est comme le lodage, on va dire, pour vue, on peut utiliser la souris,
ou tout des réactifs, qui rentrent très bien dans la vision de vue,
avec le modèle de data.
Pour l'instant, moi je mise sur la composition API pour la documentation,
et je sais qu'on peut gérer l'option API,
mais j'ai envie de voir jusqu'où on peut aller,
parce que l'option API nous rajoute des blockers,
là où la composition API, c'est limité, pour le moment.
Ouais, c'est une autre approche,
et pour le coup, moi j'étais plutôt réfractaire au départ,
je te cache pas.
Ah pareil, t'inquiète pas, je n'ai rien compris à REF.
OK, REF réactive, mais attends, tu sais quoi.
Et puis, en fait, je me suis mis,
et je pense que maintenant, ça vaut vraiment le fin.
Il faut faire l'effort d'eux, et en fait, on comprend vraiment la puissance.
Par contre, je reste quand même intimement convaincu que pour quelqu'un
qui est un petit peu plus junior dans une équipe ou qui monte sur un projet,
découvrir vue par la composition API, c'est peut-être un step...
Ah, c'est peut-être un petit peu violent au départ.
On perd justement, je ne sais pas pourquoi je n'ai pas le mot en français,
Separation of concern,
là où l'option API des coups de bière, on a data, on a méthode, on a computed.
C'est très facile à comprendre, en fait.
Quand je l'ai expliqué dans les formations Vue, ils comprennent vite.
Même si ils ont très peu de compétences en JavaScript, ça reste quand même un objet,
et tu mets des fonctions...
Là où c'est vrai que le script setup, on est quand même un peu...
On est sur les initiés, qui connaissent déjà bien le script.
Après, dans l'optique de Nuke 3, avec nos composables,
use state, use fetch, use a signata, on essaie au maximum de vous
d'éviter d'utiliser des refs.
Et au final, on va se retrouver avec...
On utilise des composables et on peut faire des computites ou des watch.
Mais en théorie, on n'est pas censé en faire tant que ça,
puisque l'avantage d'utiliser ces use, quelque chose,
c'est que eux-mêmes vont faire des watch et vont rétrigger la référence.
On va écrire moins de codes, mais il va falloir attendre que l'écosystème
aussi transitionne et la composition API.
Ça va prendre du temps.
On mettra l'option API sur la doc, pour le moment,
se localise sur le plus facile, avec Vue 3, sur la composition API.
Moi, je suis développeur React aussi.
Je compare ça un petit peu au hook qui s'en est arrivé il y a quelques années.
C'est clairement ça.
Ils ont lieu à indigner les trois et ils ont créé le hook.
Et c'est une évolution énorme au niveau de React.
Je pense que ça va être la même chose sur Vue,
mais c'est juste le temps que tout le monde le comprenne.
C'est ça. L'utilisation, c'est ouf.
On peut pousser très loin.
Un user-sync d'Itac, on va mettre dans un composant parent
qui lui définit ce qu'il va appeler.
Dans un composant enfant, il pourra récupérer cette donnée
sans devoir envoyer via des propres par exemple.
Alors, certes, ça peut créer des antipaternes.
C'est possible et ça nous offre la réactivité partout.
Je veux explorer ça comme on a pu explorer justement
avec NUCs, au départ et vu.
Et c'est là où c'est plus difficile pour nous.
Maintenant qu'on a une communauté,
je crois, à 170 000 personnes qui utilisent NUCs
d'après la télémétrie, de ceux qui ont accepté la télémétrie.
Complètement anonyme d'ailleurs en passant.
Important.
C'est bien de le préciser parce qu'il y a plein de gens qui disent
télémétrie je bloque, je bloque.
Mais c'est pour nous, c'est mieux comprendre en fait
des utilisateurs puisque il n'y a pas tout le monde qui va sur GitHub,
venir sur Discord.
Donc on avance un peu à la veuve.
Ça nous permet aussi de prioriser le travail sur des modules
qui sont vachement utilisés, qui ont besoin de support
parce qu'on n'est pas non plus de 2000 à travailler dessus.
Ça nous aide à mieux voir, ce qu'on ne peut pas voir aujourd'hui.
Mais en tout cas, quand on a une communauté conséquente comme ça,
c'est difficile à d'innover, de tester, de dire en fait non,
on retourne en arrière.
Oh, c'est un challenge.
Et après justement, est-ce que vous n'arrivez pas à un stade
où vous commencez à être un petit peu trop gros
et du coup, en fait, bouger des choses, ça devient compliqué
parce que vous êtes encore une petite équipe
et on va parler un petit peu plus tard de toute l'équipe Core
et de NUCs Lab et tout ça.
Mais vous êtes encore petit, on va dire agile
parce que c'est le mois à la mode, mais vous pouvez bouger.
Mais néanmoins, vous avez quand même assez de notoriété
et il y a des gens qui ont basé tout leur business sur votre techno.
Et donc, est-ce que vous n'êtes pas un point de bascule
où en fait, vous ne pouvez plus faire un peu comme vous voulez.
Il y a aussi toute cette legacy qu'il faut gérer.
Est-ce que c'est compliqué à gérer ça sur la roadmap
de Vue 3 ?
Ça a été compliqué.
Enfin, ça n'est pas tant que ça,
mais puisque on reste quand même dans l'open source,
dans le développement web,
je vois les gens qui m'immigrent de NUCs 2.13 à NUCs 2.14 et 2.15.
Ça prend du temps.
Il n'y a pas le feu, NUCs 2 fonctionne très bien.
Il y a des limitations que va fixer NUCs 3.
On a NUCs Bridge qui permet d'ajouter ses features
pour les utilisateurs de NUCs 2,
qui nous permettent de continuer le développement
du framework de NUCs 2 à travers NUCs 3.
Donc, Pouya, Daniel et Anthony ont fait un super travail
justement pour que tout s'imbrique de façon cohérente
pour quand même garder nos utilisateurs à NUCs 2,
parce que Vue 2, c'est quand même un super framework.
Et surtout, il y a énormément de plugins qui fonctionnent
sur Vue 2 et qui ne fonctionnent pas sur Vue 3.
Il y a à la fois ce hype avec Vue 3,
c'est d'innovation, c'est cool,
mais en même temps, il y a quand même des business
en effet qui tournent avec Vue 2, NUCs 2.
C'est important de pouvoir faire cette transition
de façon la plus mousse possible.
Je pense que, oui, on a eu 200 issues close depuis 3 semaines.
Ça avance.
Ça avance.
On espère que personne va faire de burn out,
mais on voit des nouveaux contributeurs
depuis que c'est open source, c'est cool.
Les gens contribuent.
Et puis, comme on a bien dit que c'est temps en bétail,
il fallait faire attention.
On a une super communauté.
Franchement, on avance étape par étape.
Ça fait 5 ans que NUCs existent.
Si tout le monde nique sur NUCs 3 au bout de 1 an,
à 9 an et demi, c'est très bien aussi.
Vas-y, Patrick.
Dans un ou deux épisodes du podcast,
j'ai dit une énorme connerie.
Comme quoi, NUCs Labs était nouveau.
Et non, NUCs Labs existait depuis un petit moment.
Oui, je pense que c'est très bien.
Voilà.
C'est normal parce que ça s'appelait Orient.
Si vous voulez, je peux vous expliquer un peu l'entreprise
qui est derrière NUCs.
La base, c'est mon frère Alex et moi-même.
On avait sorti NUCs, mais nous, à côté, on avait un TAF.
Je travaillais pour une agence à Paris.
Lui, il travaillait pour une startup à Bordeaux.
En fait, en faisant des conférences,
il y avait des gens qui commençaient à nous demander
pour faire des workshops.
On ne savait pas quand c'était embarqué.
C'était cool pour nous de faire des conférences.
On rencontrait plein de gens.
On rencontrait des entreprises qui ont été NUCs.
On a vu des offres d'emplois
d'entreprises qui cherchaient des développeurs NUCs.
Ça veut dire NUCs, c'est un mot qu'on a inventé.
C'est quand même un peu de quoi.
Si on prend un peu de hauteur.
Et du coup, on a créé cette entreprise
qu'on avait appelé Orient à la base
puisqu'on avait cette idée de microservice.
Je crois d'ailleurs qu'on a encore le site qui est en ligne
sur orion.sh
là où on avait NUCs, il y a 3 000 stars.
Et on avait expliqué qu'on voulait faire des microservices.
Donc, il y avait NUCs, le Freymore,
qui on avait appelé, je crois, Cosmos,
qui était une API pour le markdown,
qui est tout simplement NUCs content.
On a enfin développé une fois qu'on a pu embaucher des gens.
Mais en gros, on a créé cette entité en 2017.
Mars 2017, ça s'appelait Orient.
Et on faisait des formations, des workshops pendant les conférences
et du consulting, du consulting chez l'équipe,
back market, à corps hôtel, plein de bonheur.
Et sauf que ça en dépensait notre temps pour de l'argent.
Et le temps qu'on dépensait, on se disait,
mais ce n'est pas du temps qu'on peut faire pour améliorer le framework.
Et à un moment, on s'est dit,
on voit Katsby qui l'aie-fait des fonds,
on voit Versel qui l'aie-fait des fonds
et qui peuvent avancer plus vite que nous.
Même si on avait une super communauté,
des super contributeurs,
ça reste des gens qui prennent de leur temps perso pour avancer.
Donc, c'est un peu aléatoire, on ne sait pas trop.
Et on s'est dit, vas-y, on essaye de lever des fonds.
En fait, ça vait très vite,
c'est plutôt un fonds qui est venu vers nous.
Et on a fait des meetings,
ça a l'air de bien matcher.
Nous avons demandé un business plan
conçu avec Alex.
Et on est partis sur une levée de un peu moins de 2 millions
avec First Minute Capital qui sont des Anglais,
Kim Aventure, le fonds d'Oxavien Niel
qui investit deux fois par semaine dans des startups,
et 2 Angels, Eduardo Ramzano et Renaud Visage,
qui était un au-delà d'Even Bright.
Et nous en fais confiance,
et c'était quoi, fin 2019, début 2020,
et on est passé de deux personnes,
début 2020 à aujourd'hui 18 personnes.
18, ouais.
Ouais, 18 personnes, ça a été...
Ouais, ça change.
Beaucoup de travail, ouais.
Et en même temps, j'ai eu mon petit garçon
qui est né en mai 2020,
donc 5 mois après, paf,
manière de mettre un chalet.
Donc toi, il va en même temps,
en plein confinement.
Il va en même temps.
Et le confinement, on avait juste pris les bureaux à Bordeaux,
le landmère confinement.
Enprise.

Et aujourd'hui, en fait,
vous avez un framework qui Open Source,
tu l'as dit, et on accueille pas mal de personnes
dans ce podcast où on parle d'Open Source,
et on sait en fait que gagner du pognon
avec de l'Open Source, c'est compliqué, quoi.
Et aujourd'hui, en fait,
comment vous assurer, en fait,
juste la pérennité de NoxLab
qui va garantir la pérennité aussi
de tout le code qui est à côté,
même s'il y a une communauté qui pousse,
c'est quand même vous qui sommes
les plus gros mainteneurs de...
Oui, bien sûr, dans la plupart des projets Open Source,
c'est souvent quelques personnes,
c'est une poignée de personnes
qui font le framework.
Et du coup, comment vous arrivez
à tenir, en fait,
juste financièrement,
être financièrement viable ?
Alors, on a plusieurs sources
de rentrée d'argent.
On va avoir les partners qu'on a sur le site,
qu'on a développé que récemment
avec la sortie du nouveau site.
Et les partners se divisent
en plusieurs segments.
On va avoir les technologies partner.
Donc là, ça va être des startups
qui...
pour faire simple,
qui se font de l'argent grâce à Nuxt.
Donc, par exemple, les solutions de hosting.
On va avoir Netify, Versel,
Layer 0, Digital Ocean ou d'autres,
ceux qui peuvent héberger du Nuxt
et qui ont tout un intérêt
à avoir la meilleure intégration possible
avec nous et de la visibilité.
Parce qu'eux se font une page marketing
Nuxt sur Netify ou Versel
pour montrer à quel point c'est trop bien.
Mais c'est pas pareil que d'avoir
la page qui explique à quel point c'est trop bien
sur le framework.
C'est de la visibilité.
Ça, c'est du monthly payment
en mode sponsoring.
Pour les entreprises, on va avoir des CMS.
Qui est pareil, c'est de la visibilité.
Et on a des sponsors,
mais là, c'est un peu spécial,
parce que c'est beaucoup de gens qui s'en fanent.
En fait, on a pas mal de sponsors,
c'est cool.
Et on a Google Chrome, par exemple,
la team qui revient les standards du web.
C'est un petit navigateur, ce truc.
Ouais, c'est pas mal.
On travaille avec Adiosmany.
C'est la team qui travaille aussi avec Nuxt.
Donc les gens, vous voyez la NuxtConf
de Google, on travaille aussi avec eux.
On a des appels tous les mois.
Ils essaient de trouver des standards
de corriger les scores de Lighthouse.
Parce que oui, ils ne savent pas encore
quel est le meilleur score.
On y travaille, on essaie de voir
pour les fonds, les services,
c'est de la R&D en permanence.
On travaille ensemble et on a derrière
CréLorg-1.js,
qui est tous ces modules
qui ont un
purpose, un but
au-delà de Nuxt.
Donc on va avoir des loggers,
on va avoir des linters,
pleines modules pour avec Mascript,
parce que c'est aussi sujet ouleu
en ce moment avec Mascript.
On a Créceptor qui va faciliter
aussi pour tous les autres frameworks.
Et Pacnode,
c'est aussi quelque chose de spécial.
Donc ça c'est le partner innovation,
un cas spécial.
Et on va avoir les partners Agence.
Donc là ça va être un peu
un business model standard
qu'on pourrait avoir chez PrestaShop,
chez...
Je ne sais pas, je ne sais pas,
plein de frémantes en fait,
Magento Water.
Agence, ça va être plusieurs choses.
Agence type
développement,
ou consulting.
Donc là, nous d'abord on les voit, on les rencontre.
On va travailler
pour certifier leur développeur.
Et on va aussi travailler avec des agences
qui vont organiser des workshops Nuxt.
Parce qu'on ne peut pas faire des workshops partout dans le monde
pour assurer la croissance du framework
et que tout le monde comprenne bien
utiliser des best practices.
Donc ça c'est une première partie B2B
qu'on va voir.
On va avoir la partie
Thème Marketplace
ou Video Courses
qui va être une autre plateforme de
Sustainability.
Ça c'est pour la partie
Nuxt directement
pas Productify.
Tu ne payes pas en tant que user
pour utiliser Nuxt.
Ok.
Ok.
Ça fait pas mal de sources différentes.
Oui.
Ça c'est la première partie.
Et après il y a la plateforme Nuxt
qu'on est en train de développer
depuis un petit moment.
Et qu'en présentant je pense
2ème trimestre 2022
2022
La plateforme Nuxt, ça sera quoi ?
Là tu viens de lancer
un caillou dans la marre
en mode qu'est-ce que c'est quoi ?
J'ai jamais entendu parler.
Moi non plus.
Je pense que vous avez déjà
entendu parler un peu de Docus
déjà.
On a travaillé
un bon moment sur la nouvelle version
Nuxt Content
qui
je ne peux pas vous partager mon écran
malheureusement, je vous aurais fait des mots.
On a travaillé sur une syntaxe
MDC
puisque MDX c'est pour React
qui nous permet
d'avoir
un éditeur visuel
comme notion pour utiliser tes composants vus
et créer des sites
Ah c'est difficile
d'expliquer sans démon
en fait
En fait, tu mets tes componentes
dans ton... tu crée les pas
Oui mais c'est pas un drag and drop
c'est les visuels builder ça,
ça n'arrive pas. C'est vraiment comme
un notion sur la gauche, tu as le split
et à droite t'as ton site
qui est déployé automatiquement sur les Cloudfair
workers
donc ultra rapide
avec Hybrid Rendering
et un lien de live preview qui est absolument instantané
donc en fait la différence qu'on a
fait nous avec
Comparer WebDX qui lui appartient
au build et ce qu'on avait
séparé avec Nuxt Content c'est que le markdown
ça vient de la paix
il ne dépend pas du build de DoNuxt
donc une fois
déployé en production on est capable d'éditer
son site
mais pas juste du content texte
on est vraiment sur cet aspect structure
et on va avoir des pages en fait
en markdown tout en ayant
le même potentiel que l'utilisation
de pages en vue
sachant que dans Nuxt 3
le A5 data peut être dans les componentes
Ah ouais mais là ça vient
ouvrir une porte monstrueuse là
Ah bah oui
on aime bien le challenge
donc c'est...
Est-ce qu'on peut comparer ça
un peu à Gazby Cloud ou un truc comme ça
vous allez gérer le déploiement aussi
tout ça ou...
Alors en travail en fait pour être toujours pareil
on aime bien être agnostiques
on aime bien avoir des partners parce que franchement
c'est sympa d'avancer dans son coin
mais les intégrations c'est quand même cool
et puis on va forcer personne à utiliser notre plateforme
je veux dire
je pense que c'est une belle approche marketing
et commercial vers celle et Next
et en même temps si tu veux déployer ton Next
sur ton propre server node en ayant le edge
function or autre je pense que c'est un peu
plus galère
non on essaye d'être vraiment
avec ni trop justement ce builder
de serveurs qu'on a créé
qui peut être déployé qui fonctionne exactement
pareil peu importe le hosting
après si le hosting a des limitations c'est le problème
du hosting
donc là ce qu'on a fait c'est on déploie
sur Plotfair workers par défaut on a
quand même un hosting parce que c'est quand même sympa de créer
un site et d'avoir directement la capacité d'éditer
sans devoir t'inscrire sur une autre plateforme
peut-être que tu ne connais pas
ou tu as quand même la possibilité de mettre ton URL
de deployment et d'éditer quand même la page
ton site mais ça c'est une première étape
parmi par une vision
long terme où on ne veut pas
faire juste le content management
c'est il y a plein de choses qui peuvent être
intégrées dans Next
et il suffit de penser au Next module
et
donner une interface
en fait va nous permettre d'avancer encore plus vite
on a créé ce système de fichiers
avec d'auto importe
la prochaine étape c'est comment
moi je peux éviter de lancer BSCode
pour éditer mon site avancer, mettre à jour
on veut avancer vite
on veut que les gens puissent avancer vite avec Next
et idéalement faire des business avec
d'accord
et ouais donc ça c'est
un gros morceau
et clairement en fait
est-ce que c'est pour rendre l'utilisation
de Next
pour les noms
dev accessible au nom
dev ou il y aura toujours une partie
de NoCode
c'est ça alors le NoCode
en tant que dev
pur et dur
Webflow c'est cool quand on se perd
Wix pourquoi pas mais
il y a quand même cette frustration
en tant que dev de pas pouvoir aller rajouter
des fonctionnalités si facilement
nous de pas
un crin ripo donc dès que tu changes le contenu
si l'éditeur change le contenu
c'est dans le code GitHub
c'est sur une branche tu peux pougeter composants
et les édites en l'âge préviaux
ça prend du temps
ça prend clairement 5 ans
pour arriver à un outil de
je m'appelle avec mon frère on faisait des sites
avec le WixiWig à l'époque
il n'y avait pas de responsibles design c'est beaucoup plus facile
là
si je devais faire un WixiWig
propre
ça serait ce qu'on est en train de faire
c'est à dire on fait vraiment
la collaboration entre les non-developpeurs
et les développeurs
et je pense qu'il y a une vraie économie
qui peut se baser autour de ça
c'est à dire qu'on peut commencer on peut trouver des freelance nukes
des agences qui peuvent nous aider
à améliorer ce site
je pense que WordPress c'est un excellent exemple
et c'est pas pour rien qu'il y a 42% du web aujourd'hui
c'est que des non-developpeurs peuvent commencer avec WordPress
mais ils peuvent très bien trouver des développeurs WordPress
pour améliorer leur site
je pense que c'est là où ils ont compris
oui
et du coup c'est la tendance que vous
vous optez aujourd'hui
de faire quelque chose de
peut-être plus accessible
et après
derrière peut-être
on va dire plus accessible
pour tout le monde et après
donner la partie
un petit peu plus touchy, compliqué
aux devs spécifiques
c'est ça, exactement
c'est un
un spectre un peu plus large
mais en fait je n'ai pas forcément le temps
d'à chaque fois cloner en local
et éditer
j'ai envie d'aller plus vite
j'ai envie que des gens qui font du nukes
peuvent faire encore plus avec moins de temps
des fois ça passe par une interface
des fois ça passe avec des lignes de commande
toujours dans ce gain de
productivité
et le kiff en parallèle la développeur expérience
c'est
notre vision intuitive
web development
carrément, carrément
et du coup avec l'arrivée
de nitro
j'ai vu là
vous avez, alors
on n'a pas parlé de NGS
mais qui est un peu
en parallèle aussi de Nux Lab
parce qu'on va retrouver les mêmes
je vois des frameworks type H7
ou H3 je sais plus
H3 oui
H3 est ce que
en fait l'objectif aujourd'hui
c'est de pousser et de devenir
une sorte de
framework
full stack ou en fait
oui clairement
je suis full stack développeur à la base
j'ai fait du note pendant un moment
j'ai fait du front
j'adore le full stack
j'avais fait du mono.js
à l'époque j'avais créé mono.js.org
qui était un peu comme Nux
mais pour baser sur express donc il y avait
l'authentification, il y avait tout qui était fait la génération de route
mais je pense qu'avec Nux
on peut faire une autre approche qui peut être sympa
nitro ça nous a permis de faire quelque chose
que je voulais depuis un moment
c'était le hot module replacement pour les servers middleware
c'était de pouvoir
faire à le côté API
sans devoir redémarrer tout le server note qui relançait
le server webpack et là c'était
atroce en expérience développement
va aller mieux faire son API à côté et utiliser Nux
c'était un grand challenge qu'on a eu
depuis un moment
sauf qu'on a voulu le pousser directement
comme on a cet objectif de déployer Nux
sur le edge
avec les cloudfair workers
mais qui de toute façon va être adopté
par d'autres providers
je pense que AWS va faire du edge
de la même façon que cloudfair et d'autres
je pense que c'est le futur
ce détaché de node
pour être pure engine
JavaScript
et en tout cas vous
vous eubrez et vous pousser vers ça
ouais
tu n'es pas obligé de faire du full stack mais si tu veux avoir
des fonctions qui tournent côté serveurs
dans le edge
c'est possible. H3 c'est encore très minimal
on est vraiment au premise
de l'écosystème et c'est pour ça qu'on les met dans un chies
parce que n'importe qui peut contribuer
c'est pas que pour Nux
tu peux utiliser
H3 et déployer sur un cloudfair workers
sans utiliser Nux
ni trop on est en train de le travailler pour le mettre
dans l'organisation NGS
pour qu'il puisse bénéficier à tout l'écosystème
JavaScript
et Nux c'est vraiment la couche
qui va être l'orchestrator
de tout cet écosystème
vu routeurs, webpacks, vites
pour te donner
un espace de travail
où tu peux directement coder les features
avancer, déployer
en toute confiance
et bam quoi, on adore faire des sites, on fait plein de sites
trop bien
Est-ce que tu pourrais nous expliquer
parce que la grosse
brique
de Nux 3
c'est vraiment NITRO
est-ce que tu pourrais nous expliquer
à tout le monde
quelle est la particularité de NITRO
qu'est-ce qu'il apporte vraiment
à Nux
C'est une bonne question
ah ah ah
ouais, c'est pas moi qui les coder
Est-ce que tu as encore le temps
de coder avec 18 personnes
dans l'équipe etc
malheureusement pas autant que je voudrais
je code le soir
comme à Femme et Oli
entre deux
pour mettre un jour mes modules
et contribuer au maximum
mais ça me fait beaucoup plus plaisir de voir
la vision se réaliser
et de voir les gens travailler
collaborer entre eux
et réussir des miracles
parce que NITRO c'est
partie des miracles
ils ont mis
un bundle rollup
en fait on a un rollup qui tourne
et qui va aller prendre à la fois
le serveur
donc on a utilisé un rollup pour le haut modus de replacement
de la partie serveur
donc tout ce qui va être dans le dossier serveur
à payer middleware c'est bundler par rollup
on a
webpack
on se sent un sujet un peu
spécifique pour le bundle de la vue
ou VIT
qui lui aussi utilise rollup
pour la vue et après il va
voir ces deux bundles comme à mixer en 1
pour avoir
cet engine JavaScript qui va à la fois
être capable de rendre côté serveur
d'avoir une API côté serveur
et de rendre les bons fichiers JavaScript optimisés
et le but c'est que NUXT
grâce à NITRO
passe en dev dependency
donc NITRO c'est à la fois un serveur
de développement
mais aussi un
il va surtout bundle on va dire
il va surtout éjecter
pour créer du code
c'est magnifique il y a plus
de non modules en fait
il va générer
comme à faire un NUXTBID avec NITRO
donc NUXTBridge ou NUXTROI
il va générer un point output
et ce point output vous allez pouvoir le mettre
où vous voulez il n'y aura pas besoin de faire
de NPM install on
utilise NFC
je crois de verselle qui va aller
traquer les dépendances
et donc il va générer quand même un dossier de non modules
mais qu'avec les package.nison et les fichiers
qui sont utilisés donc c'est comme
un webpack pour les non modules utilisés
et derrière on a
l'output de toute une application
d'un serveur qui fait moins de
méga au départ
donc en fait si on veut résumer
c'est
de la poésie quoi
NUXTRO c'est de la poésie c'est ça
exactement c'est pas facile
surtout que maintenant on a ECMAScript
qui est arrivé avec les syntaxe OSM
donc dans l'organisation NGS on a beaucoup de
package qui permet de faire le lien entre
commandes.js donc module.export
et ESM
export défaut
manière que vous n'ayez pas à vous embêter avec ça
parce que ce genre d'air en plus ça ne sent vraiment pas facile
à débugger mais c'est les prémices
c'est comme à 5 weight il y a 3 ans
des gens
c'était que c'est nouveau
donc on y arrive on arrive après
avec la possibilité d'importer des composants
depuis une URL
franchement c'est excitant ce qui arrive
c'est
pas trop fun pour nous au quotidien pour le moment
mais une fois qu'on a quelque chose de stable
ça va arriver
c'est très puissant
et justement
c'est trop bien tout ça
et comment en fait aujourd'hui
quelqu'un qui nous écoute
qui est développeur javascript
il connaît un peu vu
il veut se mettre à next
comment on fait pour vraiment
emborder
sur un projet next
on va dire la doc parce que
les devs devraient lire la doc
au moins la partie installation
après
la suite
si vraiment
on veut monter un compétence
sur next il y a quoi ?
il y a une communauté
il y a des hashtags
sur twitter
de base la documentation
ce sera toujours le point clé
je ne suis pas ultra fier
du contenu de la documentation
de next
il y a des parties qui pourraient être facturées
pour être simplifiées
c'est le travail qu'on a fait
sur nuk3 pour être le plus simple possible
mais clairement
lire la doc c'est toujours été ça
même des personnes avec qui je travaillais
je me suis dis c'est dans la doc
prenez le temps de le lire
ça vous fera gagner énormément de temps
ensuite si vous êtes un peu curieux
vous allez avoir discord
où il va y avoir des gens qui vont s'entraider
ou qui vont poser des questions
et bien sûr
la partie
de youtube
le repo, le code
parce que le code n'est pas si compliqué que ça
ça reste du JavaScript
sauf la partie nitro
ça c'est la poésie
donc
ça c'est pour vraiment essayer
de comprendre les concepts
et derrière vous allez avoir la partie twitter
ou newsletter si vous voulez avoir
des news et découvrir un peu ce qui se passe
autour de la communauté
pour nuk3
je reviens sur nuk3
vous en êtes tout aujourd'hui
la bêta est sortie il y a un mois
un peu moins d'un mois
on a pu voir qu'il y a encore pas mal de choses
notamment j'ai vu que c'était un RFC
encore tout ce qui était statique
oui
décider comment ça va fonctionner
oui exactement
parce que
au final
un incremental static generation
tous les acronymes
que je viens de vendre
pourquoi pas
si vous voulez
on est vraiment sur
soit on génère au moment du build
dans ce cas c'est un fichier statique
soit c'est du ondemand rendering
et par-dessus ça on peut rajouter une stratégie
de caching
caching qui peut être
conditionnel
si c'est un utilisateur authentifié
je ne fais pas de caching
mais c'est pour ça qu'on prend le temps
sur cette partie hybride
c'est de se dire pas déjà de base
on a un truc ultra rapide qui fonctionne
au serverless
parce qu'on a 3 minutes secondes de cold start
on a fait du code splitting aussi
côté serveur
c'est à dire que dans nuk3 quand vous allez
démarrer en production ou même avec nuk3
avec nuk3
si vous allez taper
une API route
nous on va pas charger le chunk
côté serveur de la vue
donc ça va vraiment répondre instantanément
sur cloud fair workers on a 0 min
de cold start
c'est optimisé de base
à partir de là ça va être de se dire
quel cache control
leader je vais mettre qui va être supporté par tel provider
que ce soit du varnish
du versel
cloud fair et j'ai retous
des cache control
leader à quel moment
est-ce que si je le veux au départ
alors du build je vais prégénérer
ces pages tout simplement
c'est donner un peu cette approche
donc nous techniques de dire
comment ça doit fonctionner et après on va rajouter
ce couche simple à la nuk3
en mode je rajoute peut-être une clé juste cache
dans ma page et c'est bon
évidemment j'aimerais même le pousser au niveau du component
et c'est pas le plus dur
la question ça va être où une belle
expérience utilisateur
à mettre en place
il y aura quand même de l'incrémentale
dans le futur
oui
parce que si l'incrémentale c'est juste
je génère
on demande et je mets en cache
jusqu'au prochain build
on met en cache avec le build id
et puis lorsqu'on a refait notre build
on purge
ça va être très simple de mettre en place
on va sur versel et netlify
puisque j'ai déjà en fait ces cache
control et d'heure
on le mettra déjà dans la doc
parce que c'est possible aujourd'hui si tu utilises versel
d'avoir l'incrémentale static generation
faut juste mettre les bons et d'heure
ok
mais c'est le travail de cette semaine je crois
de Pouya et la semaine prochaine donc ça va arriver
en novembre
et on parle de vues 3
aujourd'hui la sortie est les pentes
coro officielles, il y a vues 3
il y a nux 3 qui est en beta
je pense qu'il y a
une étroite
vous êtes étroitement lié tous les deux
c'est-à-dire quand vues 3 sortira
de manière officielle est-ce que nux
sortira aussi de manière officielle
ou pas
vues 3 il est sorti
alors il est stable
mais quand tu dis de manière officielle
je pense que ce soit sur vuesjs.org
c'est ça
je crois que Evan il travaille sur la doc
principalement
on ne s'est pas
directement accordé les timelines
mais je pense que lui aussi il attend
que l'écosystème et la communauté
de des plugins vues
basculent un certain niveau
pour se dire ok, là c'est bon c'est la solution officielle
je pense que le fait que vues Tifaille
ne gère pas encore
les non plus en version stable vues 3
bootstrap vues
des gros
de l'écosystème
une fois qu'ils ont égré
là je pense qu'on migrera tous
je pense que ça arrivera
à arriver le premier semestre 2022
ok, super
parfait
Patrick
ouais j'avais une dernière question
en fait j'avais une question
qu'on n'a pas accordé
comment ça se passe, vous collaborer un petit peu
avec tout ce qui est hostigne, verselle,
netlify et tout ça
ou est-ce qu'ils vous compactent
oui carrément
déjà ils nous ont donné des plans gratuits
parce qu'on fait de l'open source
et après c'est toujours la petite bataille entre les deux
sur le site Nukegespore
qui est hosté sur verselle ou netlify
du coup on est hosté sur verselle ou netlify
bah moi j'adore leur service
ils ont utilisé depuis quand même un beau moment
ils font du super taf entre hosting
j'avais pas envie de gérer le hosting à la base
avec Nitro et Cloudfire Worker
c'est une autre histoire
mais gérer une infra par-dessus AWS
c'est pas mon coeur de métier
et j'avais pas envie de faire ça
donc ils font du super taf
ils s'évangélisent aussi bien Nuxt
et en plus ils sont partners
franchement c'est tout BNF
donc ouais on a des channels Slack
souvent avec nos partners
donc on discute
on essaie de soindre notre marketing
pour qu'on fasse une release
soit coordonnée
comme pour la release de Nuxt 3 par exemple
oui
ok
bah écoute
est-ce que tu voudrais nous partager
d'autres infos
avant de clôturer l'épisode ?
c'est possible qu'à moins la fin de l'année
on annonce une autre levée de fonds

top
il faut expésiver
top top donc ça veut dire
on grossit l'équipe
ça veut dire qu'on passe sur autre chose
et on voit encore les choses un peu plus grandes
c'est ça que ça veut dire
c'est nul
top top
trop bien
vous allez
continuer à utiliser Nuxt
je l'espère
ça va pérenniser l'outil
pour quelques années
ça c'est cool
super
et du coup
vous avez annoncé publiquement
cette Nuxt Platform
ou c'est pour l'instant
vous travaillez encore ?
on a bêta test
pour l'instant ça s'appelle docus
on a bêta test sur docus
l'idée justement
on a refait le site nuctjs.org
v3.nux.slabs.com
avec docus
et une sortie en bêta public
de docus
une date
en fait c'est spécial
il est encore basé sur Nuxt 2
sur Nuxt péril de jour
aujourd'hui
donc c'est vrai
c'est une bêta
privée
dans le sens où on mettra pas forcément
code open source
parce qu'on n'a pas envie de maintenir
deux frameworks
de version
donc il y aura la documentation
ce sera utilisable
ce sera facile
on aura quand même un issue tracking
pour gérer les issues
mais il sera open source
une fois qu'on le fera avec Nuxt 3
parce qu'on n'a pas non plus
des ressources illimitées
on a une petite équipe
et on essaie de focaliser le travail au maximum
pour avoir le plus de
retour sur l'investissement pour la communauté
pour ce qu'on développe
ok super
c'est super clair
c'est super clair
je pense qu'on va s'arrêter là
je ne sais pas si Patrick
tu as d'autres questions peut-être
je pense que
après on ne va pas rentrer dans les détails
il y a trop de Nuxt 3
il y a la doc, tout est là pour ça
mais c'est intéressant
de connaître un peu l'histoire de Nuxt
à commencer tout ça
c'est très intéressant tout ça
ça m'a fait plaisir de la partager
avec vous
ouais top
et écoute Sébastien un grand merci
merci à tout le monde d'être restés
jusqu'au bout de l'épisode
n'hésitez pas à partager l'épisode
et je pense que comme on le dit à chaque fois
le mieux c'est de tester
c'est de faire un petit
test pour tester la techno
et voir commencer
et lire la doc
et lire la doc
un grand merci Sébastien
merci à tout le monde
merci
on va pas trouver WSLash sur le plateforme de podcasts préférés
et sur le site internet du podcast
www.slash-podcast.fr
sur le site vous allez retrouver
tous les liens d'épisodes, des références
évoquées durant l'émission