Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, épisode numéro 3 de janvier.
Je pense que c'est la première fois qu'on fait trois épisodes dans un mois.
Donc voilà, c'est exceptionnel.
Salut Alex, comment ça va ?
Mais écoute, super content, je vais bien, toujours à la montagne, c'est cool.
Et ouais, c'est pas mal de faire aussi plein de petits épisodes.
Et il y a le prochain épisode qui sera sur les CMS Headless, sur comment bien choisir
son CMS Headless, quelles sont les critères qu'il faudra prendre en compte.
Mais ça, c'est pour le prochain épisode.
Et aujourd'hui, on revient sur un épisode de news du mois de janvier avec comme d'hab
toute l'actualité du web.
Ouais, tu t'avances un peu parce qu'on l'a pas encore enregistré.
C'est pas faux.
Du coup, tu mets la pression.
Je mets tout le temps la presse.
Et sujet super vaste, en fait, je me suis rendu compte en posant quelques questions sur Twitter,
c'est pour ceux qui ont vu passer les tweets, que c'est très très vaste le CMS Headless,
il y a beaucoup de solutions, etc.
Donc on va essayer de faire quelque chose de bien.
Ça, c'est clair.
Prochaine épisode, prochain épisode.
Ouais, à suivre.
Allez, on attaque tout de suite avec une petite version de CSS, avec des snippets.
Alors c'est Adam Argil qui nous dit que c'est des snippets qui sont indispensables
en 2024.
Clairement, qu'est-ce que tu as vu toi ?
C'est le CSS qui est, enfin, tout développeur front-end doit connaître et maîtriser ces
cinq éléments, en fait.
C'est des choses qui sont implémentées aujourd'hui dans la majorité de navigateurs.
Donc là, on voit que le support est intégral dans tous les navigateurs, Firefox, Chrome,
Safari.
Donc c'est des choses qu'on doit maîtriser pour 2024.
Donc c'est des choses dont on parle depuis un petit moment dans tous les épisodes, on
parle à chaque fois.
Donc là, ça y est, on y est.
Le point A est supporté par tout le monde.
Donc ça c'est parfait.
Donc ce fameux sélecteur qui permet de définir en fait en fonction des enfants de l'élément.
Voilà.
On peut cibler vraiment précisément en fonction des enfants.
Donc ça c'est parfait.
Par exemple, là, l'exemple, c'est un bouton.
S'il a un icône à l'intérieur, on lui met une marche supplémentaire, on met un gap.
Voilà.
Donc ça, on peut le régler.
Ça, c'est la première chose.
Ensuite, il y avait le subgrade qu'on en parle aussi depuis un petit moment.
Tout ce qui est subgrade dans les items pour régler chaque item avec des grids intérieurs
en fait.
Donc c'est les enfants qu'on peut vraiment régler comme on veut.
Donc ça c'est pas mal.
Ça c'est pareil.
C'est pris en charge par tous les névégateurs.
Donc c'est parfait.
Alors mon truc, c'est...
Le CSS Nesté.
Alors ça, bon, chacun son avis.
Mais c'est pareil, pris en charge par tous les névégateurs.
Donc on peut enfin faire du CSS nesting directement en natif.
Les titres avec le balance qui est maintenant pris par tout le monde et le Prety qui était
un peu moins...
Ce qui n'est pas encore totalement supporté mais qui a une autre façon d'aligner les titres.
Donc le balance on peut l'utiliser.
Et le Prety il arrive petit à petit.
Ce n'est pas encore Safari et Firefox sont encore en retard un petit peu là-dessus.
Mais ça arrive.
Donc intéressant.
Et le dernier, c'est le container query.
Donc voilà.
Nous on peut cibler en fonction de la taille des containers, tout ça.
Excellent.
Personnellement, je te rejoins largement sur le CSS Nesté.
T'as intérêt à être bien, bien solide, d'avoir un truc bien propre et de bien différencier
tes fichiers parce que ça peut vite être l'enfer.
Si c'est mal organisé, c'est très très très vite l'enfer.
C'est bien vite illisible en fait.
Enfin moi, quand j'en fais, c'est la règle, c'est maximum une profondeur en fait.
Comme ça, ça reste lisible.
Mais tu perds un peu de l'intérêt de Nesté si tu n'as qu'une seule profondeur.
Quand tu réouvres les fichiers trois ou quatre mois après et que tu n'arrives plus à lire
ton fichier, ça devient compliqué.
Tu m'étonnes.

Allez, on passe à Denis qui va sortir ou qui est sorti parce qu'il est sorti aujourd'hui.
On enregistre.
Quand les gens vont écouter l'épisode, c'est-à-dire le 24 janvier,
Denis sera annoncé en version 6.
Donc version 6 avec plein de nouveautés, peut-être qu'on pourra revenir de manière un petit peu plus spécifique dessus.
Sauf que maintenant, c'est officiel.
Et surtout, en fait, il y avait un des plus gros contributeurs qui est Romain Lance qui est sur Swiss,
il me semble, qui fait partie du corps de développement de Denis.
Il avait écrit quelque chose cet été sur la roadmap et à quoi il fallait s'attendre sur la version 6.
Oui.
Alors moi, à Denis, honnêtement, je n'ai jamais utilisé.
Mais je sais que c'est un très bon framework qui est équivalent à ce qu'on trouve sur PHP avec la Ravel.
C'est vraiment l'équivalent de la Ravel sur du JavaScript.
Donc on a vraiment pareil l'ORM, etc.
Pas mal de choses comme ça qui sont vraiment équivalentes.
Donc apparemment, les gros changements, c'est déjà le passage au module, en fait, complètement.
USM.
Voilà.
Donc ça, c'est pas mal.
Il passe sur VIT aussi, je sais.
J'ai lu...
Il y a beaucoup de nouveautés, en fait.
Je peux revenir peut-être sur l'onglet d'avant où il y a un peu la liste et des nouveautés.
Donc on a quoi ?
USM, VIT intégration.
Il y a un nouveau système de scaffold qui permet de générer des compagnons avec des lignes de commandes qui étaient déjà existantes.
Mais je pense qu'ils vont l'améliorer.
Enfin voilà, ils vont améliorer les documentations.
Enfin voilà, plein de nouveautés au niveau de la sécurité.
Beaucoup de nouveautés.
Donc ça c'est le résumé, c'est la liste résumé de l'article qui est prévu pour demain, pour le 24.
Donc on mettra directement le lien vers l'article compé, complet.
Quand l'épisode sortira, il y aura déjà la liste complète.
Parfait.
Et c'est le...
Adenis, c'est un...
C'est un pattern MVC ?
Ou pas ?
C'est modèle vue contrôleur ou pas ?
Honnêtement, je sais pas.
Je pense que oui, mais je te dis, comme je le dis, je n'ai jamais utilisé ton cœur.
Ok.
J'ai pas encore eu l'occasion de l'utiliser, de mettre les mandans vraiment.
J'ai vu un peu la doc, tout ça, mais ça a l'air vraiment pas mal.
En tout cas, oui Romalance, comme tu dis, c'est un grand fan du framework,
qui fait beaucoup de promotions, qui est dans la core team.
Qui a beaucoup évoqué pour ça.
Oui, qui a beaucoup évoqué.
D'ailleurs, il y avait une série de vidéos, ce qu'on suive Benjamin Code,
en décembre, il a fait une série de vidéos sur une web app,
enfin une start-up un peu bidon.
Et Romain est intervenu pour la partie backend, donc c'est intéressant.
Ok, il avait expliqué comment il avait fait ça.
En fait, comment il développe le système avec Adonis, tout ça.
Excellent, excellent.
Ça marche.
On passe à Next, qui passe en version 14.1.
Ok.
Alors, pas des énormes nouveautés.
Toujours de l'amélioration de TurboPack,
le système qui, quand on utilise le 2 slash slash Turbo en mode Dev,
qui est ultra rapide pour le reloading, en fait.
Et tout ce qui est auto-module reload dans le browser.
Donc ça, ça fait un petit moment, depuis la version 13,
qui travaille dessus, il est toujours en amélioration constante.
Après, il y a quelques nouveautés, et surtout une grosse nouveauté,
enfin une grosse nouveauté, pour ceux qui utilisent Next.js en self-hosted.
Ils ont amélioré la version self-hosting,
puisque ça c'est quand même un reproche qu'on peut faire à Next.js,
par rapport à beaucoup d'autres systèmes,
où Next.js est très optimisé pour Vercel,
du coup c'est un peu le reproche d'être un petit peu trop couplé avec Vercel.
En même temps, quand t'as toute l'équipe qui bosse chez Vercel,
c'est évident qu'ils font le framework pour que ça soit hébergé chez eux.
On en avait déjà parlé sur la souveraineté et tout ça.
Ouais, on a déjà parlé, sauf que,
de temps en temps, tu as envie de gérer toi-même ton hébergement pour Next.js.
Et jusqu'à aujourd'hui, il faut savoir,
c'est un problème que j'ai déjà rencontré en niveau de développement,
c'est quand on a un système d'hébergement avec plusieurs conteneurs,
donc on a une application qui tourne sur le contenu,
jusqu'à aujourd'hui, on avait un problème de cache qui n'était pas partagé entre les conteneurs,
du coup tu invalidais le cache sur un conteneur,
mais l'autre n'invalidait pas,
du coup suivant sur lequel tu arrivais,
t'avais pas la même version de page.
Ça c'est un problème, donc c'est un petit peu problématique,
surtout au niveau de l'ISR, de l'incrémentale, statique, régénération,
du coup t'avais des pages qui n'était pas du tout à jour.
Et ça du coup ils ont travaillé dessus,
et c'est une grosse nouveauté, c'est qu'on peut faire un système cache customisé,
avec un fichier, c'est ce qu'ils expliquent le custom cache handler,
qui va pouvoir gérer le cache et le stocker,
donc on peut le stocker sur un Redis par exemple.
Et du coup on a le cache qui est partagé entre les conteneurs,
sur un Redis, et donc du coup ça invalide le même cache en même temps etc.
Donc ça c'est pas mal, je vais bientôt implémenter sur un point client,
donc je vais voir si ça marche bien.
Tu feras des retours évidemment.
C'est clair parce que jusqu'à aujourd'hui on ne pouvait pas avoir de plusieurs conteneurs,
donc c'était un peu problématique, donc là j'espère que ça va bien marcher.
On revient sur du CSS pour parler un petit peu de design de la scroll bar.
Maintenant c'est totalement possible sur la version 121 de Chrome,
où en fait on va avoir plus de latitude pour gérer des propriétés de largeur
et de couleur de la scroll bar.
Jusqu'à aujourd'hui ça marchait déjà parce qu'on utilisait le prefix WebKit scroll bar.
Ça marchait à peu près parce que évidemment sur Mac on n'a pas le problème
parce que nos scroll bars sont jolis.
Par contre sur PC c'est moche.
Donc souvent on nous demande d'avoir à peu près les mêmes scroll bars.
Si on a un conteneur qui est scrollable, de suite ça devient super moche.
Si on a la barre de scroll sur le côté, on essaie de la styliser.
Donc là depuis sur Chrome 121 c'est officiellement pris en charge
de pouvoir customiser la largeur, la couleur, tout ça, de la scroll bar.
Donc ça c'est cool.
Ça serait un petit peu plus homogène au niveau du design.
Et c'est important.
Allez on passe à autre chose et là il y a des gens qui ne sont pas contents du tout.
On parlait de React et de... non on parlait de Versel avec...
Ouais, les RZ3 ils sont recons et sont au milieu du truc.
Et là il y a React.
Il y a des gens qui ne sont pas du tout contents de React.
Il y a deux blog posts de Cassidy, son nom de famille j'ai oublié.
Williams.
Cassidy Williams et il y a une autre personne qui est Maténauf Rana
qui les deux posts se répondent un peu et viennent abonder un peu dans le même sens.
Et qu'est-ce qu'ils disent en fait ?
Qu'est-ce qu'ils disent ?
Pourquoi sur l'image là on voit un cœur avec un cœur brisé ?
C'est quoi le drama qu'il y a derrière ?
Le drama en fait c'est qu'on en parle depuis un petit moment,
depuis sur le podcast en fait.
Et comme quoi on est dans le juste et dans le vrai
puisqu'on se rend compte qu'il y a pas mal de gens qui partagent le même sentiment que nous.
Et donc ils commencent à écrire des posts là, donc c'est en janvier 2024.
Ils ont écrit des posts.
Cassidy Williams qui est assez connu et puis Matého, lui il a créé un CMS.
Je ne sais plus comment il s'appelle.
Qui fonctionne avec React tout ça.
Donc tous les deux en fait ils sont assez inquiets en fait.
En général en fait la communauté est assez inquiète par rapport à React
et dans quelle direction ça se dirige en fait le projet.
En fait ils se plaignent principalement de la complexité croissante de React
alors qu'à la base c'était plutôt simple et depuis l'arrivée des serveurs component,
là les actions aussi, les serveurs actions.
En fait les choses compliques et ça devient plus compliqué à comprendre pour les nouveaux développeurs qui arrivent dessus.
Donc ça c'est une première constatation.
Le manque de communication aussi avec la communauté par rapport aux gens qui soutiennent le framework.
Ça fait un moment qu'il n'y a pas de nouvelle version.
On est toujours sur la 18 depuis un petit moment.
Depuis juin je crois qu'il n'y a pas eu de nouvelle version en fait.
Ça commence à faire un petit moment.
Il y a une chose qui peut passer aussi c'est le fait de pousser un framework dans la documentation.
Au lieu d'utiliser React tout seul.
Ça on avait déjà parlé aussi.
Qui poussait d'utiliser un framework.
Il y a plein de choses.
Il y a aussi le fait qu'il y a une partie de l'équipe de React qui a migré chez Vercel.
Pour bosser sur Next.
Donc en fait il s'inquiète vraiment de l'avenir de React.
Qu'est-ce que ça va devenir ?
Parce que c'est des gens qui travaillent dessus.
Comme moi par exemple depuis 2016-2015.
J'ai commencé à travailler avec React.
Donc ça fait un petit moment.
On a beaucoup investi dans le framework.
On a beaucoup développé avec.
Et puis là le framework on sait pas trop où il va.
On a l'impression que chez Facebook.
Est-ce qu'à un moment donné Facebook n'a pas arrêté de supporter.
Ou moins d'investir dessus.
Et on a l'impression aussi que Vercel investit plus dessus.
Parce qu'ils ont Next.
Donc voilà c'est vraiment des lettres de personnes qui s'inquiètent.
Qui se posent des questions sur l'avenir de React.
Et il y a une phrase qui me fait réagir sur Mateo.
Il parle de.
I feel in love with React in 2016.
Quand React a annoncé Angular 2.
Il est passé sur React le jour où Angular 2 est sorti.
Et du coup il a complètement changé.
Et quand on avait déjà dit en fait.
Les serveurs component tout ça c'est un petit peu compliqué.
Et on a un peu l'impression qu'on est sur.
Un peu le virage d'angular 2 en fait.
Avec React et Next.
Donc.
Et ça c'est mon avis.
Ouais ok.
Est-ce que tu crois que toi vraiment que.
La hype.
Est-ce que c'est une hype sur React ?
Non c'est pas une hype.
Parce qu'il y a quand même beaucoup de compagnies qui l'utilisent.
De boîtes.
Tout.
C'est quand même.
Ils ont une taux de pénétration de marché qui est quand même hallucinant.
Donc est-ce que tu crois vraiment qu'il y aura.
Un retour en arrière.
Ou une évolution.
Tu vois.
Ou est-ce qu'il y a possibilité qu'il y a une communauté.
Qui reprenne un peu le truc.
Ou en fait c'est tellement piloté par des grosses boîtes.
Que au final.
C'est fini en fait.
Tu vois c'est eux qui vont décider.
Et React en fait suivra la grosse tendance.
Tu vois.

C'est déjà le cas.
C'est déjà le cas.
C'est principalement une grosse société qui décide.
En fait c'est Facebook.
Enfin Meta.
Entre guillemets.
Et qui a sorti les serveurs component.
Parce que eux ils ont des besoins internes.
De performance etc.
Mais ce qu'on n'a pas du tout.
On n'a pas 1 million de visiteurs à la seconde.
Enfin je sais pas comment ils ont.
Mais on n'a pas du tout les mêmes problématiques sur nos applications.
Donc c'est quand même eux qui décident.
C'est aussi Versel aujourd'hui qui décide pas mal de choses.
Donc si c'est quand même inquiétant.
Après je suis d'accord avec eux.
Quand on dit React à la base c'est simple.
En fait c'est juste.
En fait c'était même pas considéré comme un framework.
C'était plutôt une librairie de vue en fait.
Pour le front.
Tellement c'était simple.
Et c'est vrai que.
T'as ça on le voit avec Next.
Là laisser avoir component.
La migration est très compliquée.
Il y a beaucoup de personnes qui se plainent.
Qui arrivent pas en fait.
Ils trouvent ça trop complexe.
Ils comprennent pas comment ça fonctionne.
Donc ouais c'est un.
Je sais pas.
En tout cas le fait que.
Moi j'ai l'impression que c'est.
Facebook va peut-être de moins en moins investir dessus.
Et que ça sera plus Versel.
Puisque de toute façon.
Pour Versel c'est vraiment le coeur de leur framework maison.
Donc ils ont tout intérêt à.
Supporter React.
Sauf que voilà.
C'est eux qui vont décider.
Ouais mais peut-être tu vois que.
Au final on avait.
Une sorte de.
Automatisme.
De dire ok je vais faire un site internet.
Ou un truc.
Assez simple.
Bah je vais mettre React dessus.
Parce que c'est cool.
Parce que c'est simple.
Au final peut-être.
Aujourd'hui ça sera plus du tout.

On va dire le réflexe automatique.
Ok je vais faire un site simple.
Je vais mettre une.
Un tout petit peu de.
De.
J.S.
Et d'animation dessus.
Bah au fait je vais.
Mon choix va pas se porter sur React.
Quoi je vais peut-être utiliser.
Une autre petite librairie.
Je pense à Alpine.
Ou à des trucs.
Vraiment hyper léger.
Qui vont largement me suffire.
Et peut-être que.
Sur des grosses applications.
Un petit peu plus complexes.

Avec plus de features.
Plus de complexité à gérer.
Et bah.
Là peut-être que le choix de.
React sera plus justifié.
Parce que.
Je pourrais faire plus de choses.
Par contre j'ai une barrière à l'entrée.
Qui sera peut-être un petit peu plus élevée.
Et il faudra aussi prendre en compte ça.

Bah pour le choix du framework quoi.
Alors que.
Moi j'ai eu le sentiment.
Que.
Il y avait trop de.
Ce.
Ce réflexe en fait c'était.
Bah on fait ça avec React.
On fait ça avec React.
On fait ça avec React.
Automatique.
En fait ça devenait.
Ils avaient réussi.
A faire.
A rendre en fait.
L'utilisation de React.
Comme un.
Un défaut quoi.
Par défaut on va faire ça avec React.
Si on fait.
Si on fait du front.
On fait ça avec React.
Et je pense qu'aujourd'hui.
Il y a de plus en plus de.
De.
De librairies qui sont mis sur ce créneau là.
De gérer cette réactivité en front.
Et.
Et en plus.
Avec le choix de React.
De complexifier tout ça.
Je pense que.
Ouais.
Ils se sont.
Ils se sont coupés en fait.
D'une grosse partie des.
Des développeurs.
Et à côté.
À côté de ça.
Je pense aussi que l'offre.
Et la concurrence.
Contre React.
C'est développé.
Parce que React est devenu.
Une.
Une machine de guerre.
Et un truc super compliqué à mettre en place.
Et donc.
D'autres librairies ont pris le pas.
Pour simplifier les choses quoi.
Ouais.
Ouais.
Il y a.
Il y a plusieurs.
Il y a plusieurs trucs en fait.
Si tu veux.
React à la base.
C'était simple.
Et en fait la différence avec d'autres frameworks.
C'est que tu.
Compose toi même en fait.
Ce que tu veux utiliser.
Autour de React.
Tu.
Compose ton écosystème.
Quel que quel système de.
De.

De stock je vais utiliser.
Etc.
Etc.
Etc.
Etc.


Etc.
C'est toi.
Vraiment t'étais libre totalement de.
Les autres frameworks c'est un peu plus cadré.
Tu prends du.
Vu t'as déjà des trucs officiels tout ça même.
Voilà.
Mais.
C'est.
Enfin j'ai l'impression que c'est plus trop le cas.
Que ça devient plus complexe.
Et.
Et à contrario c'est marrant.
Parce qu'on.
Angular Angular là c'est la dernière version.
C'est beaucoup beaucoup simplifié.
Alors je regarde plus de vidéos sur Angular.
Parce qu'il communique plus en ce moment il communique beaucoup plus.
Et je me rends compte que ça s'est beaucoup simplifié.
Et je me demande si à un moment donné les gens ne vont pas repasser sur Angular, tu
vois ?
Ou évidemment, Matéo, c'est Matéo dans son article, il dit aussi, voilà, aujourd'hui
il y a beaucoup plus, comme tu dis, de plus de concurrence, il y a Quik, il y a, enfin
il y a plein quoi aujourd'hui qui sont super simplisés, hyper performants, autant performants
que réacte tout ça.
Donc, enfin le choix est voilà.
Ça va devenir de plus en plus, mais malheureusement le choix va devenir de plus en plus difficile
et je pense qu'il faudra vraiment prendre en compte de plus en plus de paramètres pour
faire son choix quoi.
Entre l'équipe, la viabilité du projet, est-ce que je fais un one shot ? Moi en tant
que dev, je fais un one shot et je dégage.
Ou je vais faire un produit que je vais rester sur les 5-6 prochaines années, je vais poncer
mon produit et je vais le faire évoluer, tout.
Enfin voilà, il y a plein de paramètres à prendre en compte.
Après il y a un truc, tu vois, il y a une grosse erreur aussi, enfin et ça, ça les
gens courage ou ceux qui nous écoutent en tant qu'auditeurs, c'est que dans les formations
récentes, les devs ils apprennent quasiment que du réacte en fait, du next, du réacte,
ils sortent de là et ça ne fait que du réacte en fait, quasiment c'est tout juste ça fait
du java script, donc ça assez, moi j'ai envie de leur dire, essayer de vous diversifier
dans d'autres systèmes, d'autres frameworks, tout ça, apprendre des d'autres trucs parce
que si vous avez fait que du réacte, ça risque d'être problématique dans quelques temps
quoi, à mon avis.
Mais surtout, surtout on ne pourrait que revenir sur les fondamentaux, les fondamentaux, les fondamentaux,
c'est tu veux faire du front, tu veux faire du front, tu fais du HTML, du CSS et après,
après tu fais du JS.
C'est clair.
Mais si tu veux faire du front, c'est du HTML, du CSS et maintenant en plus tu en
peux faire de plus en plus de trucs super stylés que avec du HTML et du CSS quoi.
Donc c'est commencé par la base et après on met du JS et une fois que tu gères du
JS avec les fondamentaux du JS, là tu passes sur une librairie, réacte, vue, angular, alpine
ou ce que tu veux mais souvent on voit trop de juniors négliger les fondamentaux et survoler
trop rapidement le JS et tout de suite partir sur des librairies.
On en a déjà parlé pas mal.
Oui, après ce n'est pas leur faute.
Non, non, non, bien sûr.
Ils font des formations en six mois, ils apprennent en six mois et un an, ils apprennent
de l'EV.
Enfin, quand je vois les années que ça nous a pris, toi et moi, pour arriver à un bon
niveau, c'est tellement long, il y a tellement de choses à apprendre que à un moment donné
c'est vrai que les formations sont obligées de faire des choix donc ils virulent sur
ce qui est le plus utilisé, le plus demandé.
Et puis exactement, après c'est toujours l'éternel question, est-ce que c'est l'œuf
ou la poule, tu vois, c'est le marché veut du réacte donc on forme au réacte, les
mecs sont fermés au réacte donc le marché s'adapte au mec qui se fait, tu vois, c'est
le cercle, c'est le cercle.
C'est comme ça.
Allez, on vient mettre un tout petit peu plus de design, de couleur, de trucs jolis
avec une énième, énième librairie d'icône qu'on peut trouver.
Par contre, l'avantage de celle-ci, c'est qu'elle a été déclinée quand même sur
directement dans les, donc en GS, pur, en réacte, en vue, en Svelte, en solide, en
angulaire, en réacte natif, en flotteur et en fait on va pouvoir interagir directement
avec l'épaisseur des icônes, on va leur donner une graisse plus ou moins forte et
on va pouvoir gérer la taille aussi directement depuis la librairie.
Donc, elle a quand même un intérêt certain.
Ça claque pas mal et tu as vu quand tu vas sur une icône, tu verras, tu peux la récupérer
dans différents formats.
Je pense qu'il faut que tu fasses une recherche pour en haut, pour être un peu, voilà n'importe,
et puis, prendre une au hasard, tu verras, quand tu cliques derrière, tu peux t'écharger
en diffant format, je crois.
Il y a ça et je pense qu'il y a GSX, Vuse, Velt, Angulare, tu vois, il y a pas mal de,
c'est bien foutu, c'est un petit effet.
Donc, après tu peux récupérer directement le composant directement dans ton framework
sur lequel tu as choisi.
Tu peux tomiser, tu peux récupérer en plus dans le format que tu arranges.
Non, elle est pas mal, elle est pas mal.
Intéressant, intéressant.
Yes.
Top Patrick, parfait.
Ouais.
On en reste là pour cet épisode.
On remercie tous les personnes qui nous sponsorisent.
On a encore récupéré des nouveaux sponsors sur ce mois de janvier.
Et donc, un grand merci à eux.
Vous aussi, vous pouvez contribuer en fait à nous soutenir dans notre démarche de
Double Slash, à savoir que vous pouvez nous sponsoriser, mais vous pouvez aussi partager
les épisodes, un petit pouce, un petit like, un petit commentaire.
Ça nous aide à gagner en visibilité, parler de Double Slash à vos collègues, à vos
potes, à vos compagnons de formation, à vos formateurs.
On en fend.
Ça marche.
Un grand merci à tous d'être restés jusqu'au bout de l'épisode et on vous dit à bientôt.
Ciao ciao.
Ciao.
A plus.
Retrouvez Double Slash sur vos plateformes 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 de l'épisode, les références, évoquer
durant l'émission.