Bonjour à toutes et à tous, bienvenue sur ce nouvel épisode de Double Slash, épisode
il me semble 90 donc bientôt on approche de laissant quand même.
Comme d'habitude, évidemment nous sommes avec Alex, salut Alex.
Salut Patrick, salut tout le monde.
Ouais donc je ne sais pas si on va...
Alors les sens, ça devrait être vers la fin de l'année je pense.
Ouais on devrait arriver au sang très très vite donc c'est cool.
En tout cas avant la fin de l'année, je pense que avant décembre c'est sûr on sera l'épisode 100.
Donc non c'est cool, c'est cool.
On commence par évidemment remercier les contributeurs.
Évidemment, comment on pourrait faire et en fait est-ce qu'on aurait pu,
est-ce qu'on pouvait imaginer en fait qu'on serait arrivé à cet épisode là
et potentiellement dans 10 épisodes on sera l'épisode 100.
Est-ce qu'on aurait pu le faire sans votre soutien de like, partager
et surtout en fait propager la bonne parole de Double Slash à vos collègues,
vos amis à travers les réseaux.
Ça nous aide énormément et pour ceux qui sont les plus fortunés
et qui peuvent nous soutenir sur GitHub sponsor,
un grand merci à vous, ça fait super plaisir de se partager et se donner.
Donc, pas besoin de se fortuner, juste un euro peut suffire.
Exactement, mais en tout cas tout le monde le fait pareil
et donc c'est super sympa pour ceux qui le font.
Un grand merci à vous.
Petit sommaire dans cet épisode de news du mois de juillet.
On va parler de Python, de tout l'écosystème Python qui vient avec du tooling.
Évidemment on va parler de performance et de comment on peut monitorer,
comment on peut retrouver toutes les bonnes pratiques.
On va parler aussi du tooling en local, comment on fait pour partager.
On va parler de migration, en tout cas de fusion entre MongoDB et Postgre.
On va parler évidemment d'astro parce qu'il faut parler d'astro comme toujours,
de l'aravelle avec SYNFO, de HTMX2.
Voilà un petit peu le sommaire et j'en ai oublié plein d'autres,
mais les grands thèmes sont là.
Ouais carrément, on a pas mal de news.
Voilà, on commence.
Et bah, on attaque.
Première, on va dire, package, en tout cas solution qui vient,
qui est développée par StackBit,
donc pour ceux qui ne connaissent pas StackBits de la plupart du temps,
sur les sites de Doc, quand vous pouvez tester en live, en un clic,
en fait, on va avoir un écosystème qui vient popper automatiquement
dans notre navigateur et donc on peut coder dans notre navigateur.
StackBits nous permet de faire ça, sauf que comment on fait
quand on vient écrire une librairie et qu'on veut la faire tester
sans pour autant, en fait, la publier sur NPM,
et bah eux, en fait, ils ont sorti un nouvel outil qui s'appelle
paquet, alors pkg.pr.new.
Donc c'est un peu compliqué à prononcer,
mais au final, ça passe plutôt bien
et ça va nous permettre de monter directement le package
et ça va le délivrer en fait via leur système de CDN.
Ouais, paquet.pr, je dirais, peut-être.
Ouais, et en fait, l'idée a priori, c'est en fait,
c'est de pas attendre, en fait, que par exemple, tu utilises un paquet.
Et puis, bah, il y a un petit bug, machin,
un mec qui n'est pas corrigé de suite ou qui est corrigé dans une version,
une pool request ou un truc comme ça.
En fait, tu peux installer cette pool request
sans forcément installer le package, la version de package
qui est sur NPM et donc ça te permet de pouvoir éventuellement
corriger ou tester ou des choses comme ça.
Donc c'est vachement pratique, en fait, c'est plutôt pas mal.
Ben ouais, et surtout, ça vient s'infranchir, en fait,
d'un package manager registrerie, donc qui est NPM,
qui est parfois, on se pose même la question,
mais est-ce qu'il va pas exploser ce truc parce que vu le nombre de package
qu'il y a et maintenant on est en train de se diriger plus
vers des liens CDN directement et toutes les mises à jour,
en fait, de l'écosystème JS nous permettent aujourd'hui
d'aller récupérer directement des packages depuis des URL.
Et donc, ce service-là, en fait, vient pousser et vient
utiliser pleinement cette solution-là pour nous proposer
d'installer des packages sans, en fait, passer par NPM.
Donc plutôt intéressant et toujours intéressant pour faire des tests,
pour voir en fait si la PR qui n'est pas encore mergée
va pouvoir solutionner notre problème et ben on peut,
nous on crée une branche, on installe le package,
il y a tout ce qu'il faut dedans et à chaque boom, ça peut tester.
Donc, c'est cool.
OK, en fait, c'est super pratique pour ne serait-ce que pour quand
tu écris un package ou des choses comme ça, que tu as envie de tester
en open source, enfin tu vois des trucs, tu veux le tester en prod,
tout ça et ben tu n'as pas envie forcément de publier pour tester.
Donc tu peux éventuellement, quand on voit, c'est vachement facile à écrire.
En fait, il y a l'exemple de l'écriture, en fait, tu mets là,
c'est juste un petit peu plus bas, je crois.
Tu mets, voilà, c'est ça, le Omnere,
ripo, package et comique, donc tu peux vraiment aller jusqu'au hash
du comique pour sélectionner vraiment ce que tu veux.
Donc c'est vraiment pas mal.
C'est surprenant.
Il faut une espèce de build à la volée,
quoi, au dernier moment.
Donc, super, super, super puissant.
La suite, en termes de puissance,
on se doit toujours d'utiliser des outils modernes et puissants.
Et on sait, parce qu'on n'arrête pas d'en parler sur double slash,
que le Rust est en train de tout masteriser en termes de tooling,
parce qu'on arrive à descendre bas en termes de langage machine.
Et on est super, super puissant.
Et donc, il y a une sorte de réécriture de tout le tooling qui est en train de se faire.
Et alors là, je ne sais pas si c'est une boîte
ou si c'est une organisation qui s'appelle Astral.
Et pour les gens qui font du Python,
en fait, ils sont en train de cette boîte,
on va dire cette organisation, et en train de réécrire tout le tooling de Python.
Et donc, moi, je suis rentré par, en fait, leur package manager qui s'appelle UV.
Et en fait, ça nous permet, en fait, d'être un substitut à pipe ou pipe.
Je ne sais pas comment les pitons, les personnes de la communauté disent.
Dites-le nous dans les commentaires, parce que,
moi, perso, je ne viens pas de cet univers-là.
J'ai dû installer des packages en piton.
Et donc, je suis tombé sur ce package manager et je l'ai testé.
C'est vrai que c'est très rapide.
Malheureusement, je n'ai pas d'éléments de comparaison.
Par contre, il y a tout un écosystème qui est en train de se développer,
justement, par cette boîte-là, qui réécrivent tout en Rust.
Et donc, ils ont pour projet le linter.
Et on va dire tout l'écosystème de tooling pour que ça soit beaucoup plus rapide
et beaucoup plus fonctionnel et performant.
Ouais, c'est cool.
Ouais, par a priori, c'est une compagnie, parce qu'il y a une anglais compagnie,
donc ils ont l'air de partir vraiment...
Voilà, ils changent...
Ils modernisent, j'ai envie de dire...
Tiens, d'ailleurs, il y a Guillermo qui est parmi les Vici, on dirait.
Guillermo qui est toujours là.
Les mecs qui est toujours là.
Donc, s'il a investi là-dedans, c'est que c'est pas mal.
Ouais, ils modernisent tous, en fait, de piton.
C'est une bonne nouvelle.
Piton, c'est un bon langage.
Puis, comme on disait juste avant l'épisode, on l'utilise beaucoup avec les LLM.
Et ouais, en fait, moi, clairement, je suis rentré dans l'univers piton,
grâce ou à cause, je sais pas.
Mais en tout cas, de toute l'utilisation de ces modèles-là,
il y a beaucoup, beaucoup de librairies qui sont faits en piton.
Et donc, j'ai dû gérer la gestion des environnements sous piton,
qui est quand même pas super facile, je trouve.
Ouais, c'est clair.
Donc, en tout cas, Astral vient optimiser la performance de le package manager.
Yes, cool.
Toujours en termes de performance,
un petit écosystème, en tout cas, une espèce de site Internet qui s'appelle E18E,
pour écosystème performance.
Et c'est une communauté a priori qui se monte, en fait,
dans le but de nettoyer un petit peu l'écosystème, d'après ce qu'ils disent.
Après, c'est difficile de comprendre vraiment comment ça a fonctionné, tout ça.
Pour l'instant, on peut juste rentrer dans la communauté.
Mais je sais pas.
Après, l'objectif est plutôt nable, en fait,
c'est d'optimiser les ressources, les rendre plus rapides, les rendre moins gourmandes
et plus facile à l'usage.
Et tout de suite, on voit parfaitement,
où on a Un.js qui est la grosse communauté qui a réécrit beaucoup de packages,
qui étaient écrits nativement en JS,
mais ils les ont réécrits de manière un petit peu plus moderne.
Et donc, ils ont fait un gros travail là-dessus.
Et cette organisation, E18E,
promise une certaine performance
et essayait d'alléger un peu tous ces packages
et toutes ces librairies qui sont des vaux parfois.
Sur le coup, je croyais que c'était Un.js qui avait lancé ça.
D'ailleurs, c'est peut-être le cas.
Ah ok, les mecs derrière, ça ressemble tellement à leur façon de penser,
de faire des packages propres, légers, tout ça,
que je me suis dit, mais c'est pas l'équipe d'Un.js qui a lancé ce truc.
Je sais pas du tout qui a derrière.
Mais en tout cas, j'ai trouvé que la démarche est plutôt intéressante
de faire le ménage.
On parlait tout à l'heure, il y a quelques minutes de NPM
et de tout le nombre astronomique de librairies
qui sont pas toujours à jour, qui sont pas maintenues,
qui sont plus ou moins performants.
Voilà, là, le but, c'est d'essayer de se concentrer
sur des choses qui amènent vraiment de la valeur
et qui sont performants, optimisés.
Et derrière, ils ont aussi une espèce de baisse-practice
où, justement, ils vont promouvoir toutes les bonnes pratiques.
Donc, pour le coup, c'est vraiment intéressant.
Oui, à suivre.
Exactement.
Et quand on parle de performance, évidemment, c'est bien,
mais faut-il encore les checker, c'est-à-dire les monitorer,
regarder si le site fonctionne correctement
et assez rapide et performant.
Et sécuriser aussi.
Et là, on a un petit site qui nous permet de faire
ce qu'il s'appelle WebCheck, qui s'annonce comme quoi
on va passer au Réunion X tout le site.
Et ça vient checker un nombre incalculable de fonctions.
Et ça, hyper rapidement.
Vas-y, on peut tester le site double-sache.
Allez, double.
C'est quoi ? C'est double-slash.dev ?
Oui, c'est ça normalement.
Je sais, je suis bon.
Déjà, c'est hyper rapide. C'était instantané, quasiment.
On a déjà des résultats.
On va vérifier le serveur.
Déjà, on est aux États-Unis déjà.
Bravo, merci Netify.
Après, je ne sais pas si t'appel d'abord la réplication.
Toujours est-il que, oui, on est aux États-Unis, on a le SSL,
on a les DNS Récords, on a les Header,
on a les Social Tags, Security.
Après, tu donnes des croix quand tu n'es pas bon.
Par exemple, un petit peu plus haut, tu as les Header protection au niveau du Header.
Tu achetes tes security un petit peu plus bas.
Tu dessins.
Là, on voit qu'au niveau des policises, tout ça, on n'est pas encore trop top.
Apprends sans fou parce que c'est du statique.
Oui, c'est exactement.
Il faut aussi mettre en parallèle, tout le site Internet, c'est du HTML, CSS.
Après, tu donnes des foyers or wall.
Il y a plein d'informations, et ils te donnent des conseils pour sécuriser ton site.
Si il y a des choses qui manquent, c'est vraiment pas mal.
Franchement, déjà, c'est ultra rapide.
J'ai surpris de la vitesse à laquelle ça répond et que ça te donne le résultat.
C'est limite.
J'ai l'impression qu'ils sont scannés tout le web avant.
C'est incroyable la vitesse.
Ou alors, ils utilisent vraiment le Edge Computing en parallèle élysant les requêtes.
Chaque module fait ça.
Tu vois le Webseat Carbon aussi, l'impact avec Webseat Carbon.com, le Carbon Food Print.
On voit qu'on est meilleur que 77 % des sites.
On pourrait faire mieux, je pense.
Est-ce que tu penses qu'on est green alors ou pas ?
On est green, on est normal.
Je vais troller parce que...
Arrête de troller, je...
Je suis fatigué du green marketing dans la tech.
Je dis pas que c'est pas important.
Je dis que des mecs se vendent des markets du green développement.
Alors qu'objectivement, les gars ils font du dev, ils utilisent les mêmes outils qu'avant.
Ils vont les mêmes pratiques.
C'est exactement pareil.
C'est juste un positionnement marketing.
Why not ?
Mais j'avoue, ça me fatigue.
On fera peut-être des baladiers.
On pourra faire un épisode dédié ou plutôt un live.
Là pour le coup, ça se rendra beaucoup moins de filtres.
Ok, et ce qui est super bien, c'est qu'on peut l'héberger chez nous.
C'est-à-dire, si on a peur que toutes ces infos puissent liquer, on peut héberger le code source.
On prend le code source, on l'héberge chez nous sur notre plateforme d'hébergement.
Et on lance nos tests.
On peut même les lancer à travers un call-up-ay.
Pas mal, non, mais pas mal.
Ça veut dire qu'on peut monitorer un intervalle régulier, peut-être un item pour voir.
Donc, super intéressant.
Tout le se super rapide, super intéressant comme information.
A utiliser quoi ?
Mais grave.
Allez, on reste dans le tooling.
Je pense que...
Ça va trop les encore.
Ah ouais, ça va trop les sévères.
On reste dans le tooling avec une nouvelle version de Insomnia.
Insomnia qui est l'équivalent de Postman.
C'est un logiciel pour tester ces requêtes sur n'importe quel protocole.
Beaucoup de protocoles, donc HTTP, graphQL, REST, WebSocket.
Ils ont plein de possibilités d'échanger.
Ce qui nous permet de tester les requêtes.
Sauf qu'en fin du mois de juin, le 27, il y a quelques jours, ils ont sorti une nouvelle version.
Et t'en penses quoi toi ?
De la nouvelle version de Insomnia, depuis qu'ils ont changé tout le système,
où il faut se connecter, machin, avec un compte, c'est...
Franchement, c'était un outil super simple qui était vraiment apprécié.
On avait tous migré sur Insomnia parce que Postman, c'était compliqué.
C'était devenu vraiment compliqué.
Alors que pareil, Postman, à la base, était simple et c'est devenu compliqué.
Insomnia était simple, il était devenu compliqué.
Il faut se connecter, machin, tout ça, ça se déconnecte, il faut se synchroniser.
Enfin, sérieusement quoi, on n'a pas besoin de ça.
Franchement, moi je suis super déçu de cette mise à jour.
Alors ils ouvrent plus de possibilités avec des variables d'environnement,
tu peux manager, tout.
Oui, sauf que pour moi, Insomnia, comme tu l'as dit, est en train de se postmanifier.
C'est en train de devenir en fait comme Postman.
Et avec... Oui, on va faire...
On va exécuter quelque chose en amont de la requête,
on va exécuter quelque chose après la requête.
Donc ce qui est bien, ce qui permet de traiter un petit peu l'information.
Sauf que ça amène une complexité parfois qui n'amène rien.
Et un truc tout con, avant, on voyait dans quel environnement on était.
Donc tu mettais ton environnement Dev, de prod, de stage.
Et là, vu que tu les manèges, tu as trois clics à faire pour changer de ça.
Ce qui fait que quand tu arrives sur Insomnia, tu ne sais pas si tu es en prod ou si tu es en Dev.
T'es obligé de faire un clic pour voir ce type d'information-là.
Et ça, moi, ça m'a rendu fou.
Mais vraiment, j'étais à... Pourquoi ils ont fait ça ?
Là, tu vois tout de suite dans quel environnement t'es, si tu es en Dev ou en prod.
Et là, quand tu peux mettre ton URL, tu peux mettre local host,
sauf que vu que j'ai managé en fait mes variables d'environnement,
mon URL en fait est toujours la même.
Et soit je suis en prod, soit je suis en Dev.
Donc ce qui fait que je ne peux pas voir mon URL, vu que c'est une variable.
Donc ma seule information, c'est dans quel environnement je suis.
Est-ce que je suis en stage, en Dev ou en prod ?
Et rien que ça, ça m'a soulé.
Mais j'ai été complètement fou.
Et donc, comme je n'aime pas péter des câbles pour rien,
le problème, c'est que j'ai eu encore beaucoup trop de projets qui sont sur Insomnia
où en fait j'ai toute ma collection de roquettes qui sont toutes bien structurées et tout.
Donc je ne peux pas migrer comme ça.
Mais je pense sérieusement migrer sur un truc beaucoup plus simple, plus light,
qui vient directement s'intégrer et qui est aussi versionnable dans mon repo GitHub.
J'ai nommé évidemment Bruno.
Exactement, avec la petite tête de chien.
C'est clair.
Il rajoute pas mal de trucs comme la version 9.3.
Donc tu vois, ils mettent un exemple comme quoi tu peux tester après la réponse.
C'est super, il n'y a pas de problème.
Mais peut-être qu'ils auraient dû garder la version qu'on avait avant, simple, tout ça,
et peut-être faire une version entreprise.
Je comprends qu'en entreprise, avec des équipes, tout ça, tu as plusieurs devs, tout ça, on partage des trucs.
Là, tu payes tout ça.
Là, nous on forcé la main à tout se passer sur cette version hyper complexe.
Il la complexifie de plus en plus.
Mais maintenant, quand tu la lances, c'est une usinagase.
C'est une usinagase.
Ah ouais, j'ai des collections, j'ai des environnements, j'ai des projets.
Et là, tu fais, ouais, mais là je suis retourné sur Postman, mon pote.
Non, moi, je mettais barret de Postman pour ça.
Bruno, ouais.
Checker Bruno, les gars.
Checker Bruno, c'est vraiment...
On peut parler dans d'autres épisodes, mais Bruno, c'est hyper simple.
Alors j'espère qu'il ne va pas faire pareil, que dans un an, il ne va pas complexifier.
Non, parce que pour le coup, c'est une petite équipe et je pense que ça va, il est encore de la marche.
Mais peut-être qu'il faudrait faire juste une version payante de Bruno,
pour qu'il reste sur un truc simple, quoi.
Yes.
Tu vois, je ne sais pas.
Allez, toujours sur les DevTools.
Il y a vu DevTools qui est en train de dévoluer.
Donc là, vous allez me dire, non, mais attends, Alex, il n'y a rien de nouveau là-dedans.
Pointe, pointe, pointe, deux, qu'est-ce que tu me racontes ?
C'est quoi ton truc ?
Et c'est qu'en fait, avant, on va dire, le DevTools de vue s'installait directement depuis le navigateur.
Et ils sont en train de le réécrire.
Pour le coup, ils utilisent en fait la même version que l'expérience que Nuxt pouvait faire.
Et en fait, Nuxt a créé un DevTools.
Alors si vous utilisez Nuxt pour votre projet, je vous invite fortement à utiliser le DevTools Nuxt,
qui est juste trop bien.
Et là, vu DevTools est en train de s'inspirer fortement.
Et donc, c'est exactement le même système.
C'est quelque chose qu'on installe directement dans le projet.
Et on a une espèce de petit curseur qu'on vient placer où on veut.
Et à l'intérieur de ce curseur, en fait, il y a le DevPanel avec toutes les infos,
de versions, de pages, d'assets, de builds, de composants.
Et évidemment, si on a utilisé un store type Pina ou des choses comme ça,
on va pouvoir les retrouver.
Et on va retrouver aussi tout l'écosystème de composants,
en fait, pour voir toutes les imbrications des composants.
Voilà, c'est assez pratique, assez fonctionnel.
Et on a un pointeur qui nous permet de visualiser directement le composant par lui-même.
C'est encore en bêta, je crois.
Ça a l'air de bien marcher, quand même, dans l'ensemble.
Oui, oui, oui.
Parce que, fluide depuis tout à l'heure.
C'est ouf.
Non, ça marche vraiment bien.
C'est vraiment sympa.
Et pour le coup, je perce que j'utilise Nuxt DevTools quasiment tous les jours.
Et ça fait partie des outils mais qui rendent la vie ultra, ultra, ultra facile.
Je vais troller un peu.
C'est presque aussi bien que DevTools réacte.
Tu sors tout de suite.
C'est juste une extension ou une truc qui bug tout le temps.
Encore énorme, c'est DevTools.
Comme tu me disais, habituellement, c'est une extension que tu mets dans Chrome,
machin imbidule, comme l'extension React DevTools.
Sauf que là, maintenant, c'est bien un package que tu intègres dans ton projet et plus dans le navigateur.
C'est un peu à l'image de ce qu'on a déjà dans Symfony,
il y a la ravelle de tout ça où tu vas rajouter un package qui va te faire sortir une DevTools.
C'est cool parce que, à mon avis, ça va mieux marcher.
Parce que souvent, dans les extensions, ça, des fois, ils se connectent pas à un autre.
En fait, tu vas toujours avoir un problème de connexion entre ton instance qui tourne sur ton navigateur
et ton code. Là, vu que tu es parti de ton code pour binder ton extension,
tu l'as directement.
Il accès à tout, en plus, parce qu'il est dans le projet.
Non, c'est cool. Par contre, je me demande un truc.
Le DevTools vu,
est-ce qu'à un moment donné, le DevTools nukst devrait pas être juste un plugin
du DevTools vu, en fait, pour avoir un seul DevTools.
Je ne sais pas. Après, il y a aussi des histoires de gouvernance.
Il ne faudrait pas qu'il y en ait un qui devienne tributaire de l'autre.
Donc je pense qu'ils vont garder les deux...
Là, ils se retrouvent avec deux DevTools à maintenir.
Après, ce n'est pas les mêmes équipes, mais certainement, il y en a de nukst qui travaillent sur le vu.
Après, je n'en sais rien. Je ne sais pas du tout.
Exactement. Et pour le coup, tu peux même installer l'extension...
Enfin, ce DevTools, tu peux l'installer sur une application à part,
qui est totalement dédiée et à part. On pouvait déjà faire ça.
Mais là, en fait, maintenant, c'est un plugin vite, directement, que tu installes.
Donc voilà.
On verra et en suivra de toute façon l'évolution de ce DevTools.
Merci.
On reste dans l'univers des DevTools, toujours,
parce que ça peut nous arriver, en fait,
de devoir partager notre URL de notre masque, qui est en local, avec le monde extérieur.
Donc, il y a moyen de faire ça via des trucs assez complexes avec ton routeur.
Il faut que tu ouvres les bons ports, tout.
Ça peut être super complexe.
Il y a une solution payante, qui est quasiment la plus connue, qui s'appelle NGrock.
La plus ancienne.
Oui, qui est la plus ancienne.
Même si maintenant, il y a Cloudflare Tunnel aussi, qui nous permet de faire ça.
L'idée, en fait, c'est d'ouvrir ton port 3000 de ton applicatif
et tu vas recevoir une URL que tu vas pouvoir partager avec tes clients,
ou via un autre service.
Et ça, c'est plutôt intéressant.
Ça va marcher en production directement
et tu vas avoir des noms de domaines plus ou moins enregistrés, plus ou moins fixes aussi,
selon ton modèle que tu vas pouvoir gérer.
Et surtout, moi, le gros avantage que je vois,
c'est que tu vas avoir une espèce d'API Gateway qui te permet de tout centraliser.
Sauf que ça, c'est la version payante.
Oui, il faut payer.
Exactement.
Et aujourd'hui, on a un autre système.
On a dit tout à l'heure qu'on avait Cloudflare, mais on a aussi...
Alors comment ça s'appelle ?
Au FUTI.
Alors celui-là, j'ai testé au FUTI, je ne sais pas si it's italien ou quoi, je ne sais pas.
Alors celui-là, j'ai testé hier soir.
Et toi, tu as... Alors on a un deuxième que toi, tu as testé aussi.

Voilà. Alors moi, je fais mon retour sur celui-là.
Yes.
Allons-y. Alors j'ai testé hier soir.
Déjà, DIN, ça ne fait pas de tunnel externe.
C'est con.
Ok.
Non, en fait, ça ne fait pas d'URL.
Alors peut-être qu'en réseau local, non, tu vois, c'est un wifi,
tu peux partager via le wifi tout ça, avec l'URL.
Sur ton réseau local.
Alors en fait, ça fait juste...
Aux lieux d'avoir localhost, tu mets un domaine n'importe lequel,
et ça te fait un pont, en fait, un proxy en quelque sorte.
Un proxy tout simplement même.
Et voilà, et ça te fait un certificat HGTPS,
enfin SSL, et puis voilà.
Et ça te met ça dans le host.
Alors c'est que sur Mac, pour l'instant, ça arrive bientôt sur Windows et Linux.
Mais voilà.
Alors il y a sort, je vais tester, c'est cool et tout.
Et ça ne marche pas.
Je dis, merde, ça ne marche pas, c'est con quand même.
En fait, je n'avais pas compris au début, parce que ça fonctionne avec Docker.
Et en fait, il faut lancer un conteneur,
pour que ça fasse des procs, et que ça fonctionne, etc.
Ok.
Mais bon.
Après, je pense que la communauté DevOps va nous dire,
non, mais les gars, vous êtes trop con, vous pouvez faire ça avec traffic,
ou caddy, ou des choses comme ça.
Ouais, sauf que, s'il faut gérer un fichier config,
avec je ne sais pas combien de lignes de code,
quand on vient d'une expérience fronte, qui est plutôt la nôtre,
voilà, on n'a pas toujours ces notions-là.
Et la learning curve, en fait, d'apprendre traffic pour juste faire un proxy local.
Bon, je ne sais pas si c'est très rentable.
Mais...
Ce truc-là, il est super simple à utiliser.
Parce qu'en fait, tu vois, sur la droite, il te fait le certificat,
tu rajoutes le truc dans la keychain, le truc Apple,
là où tu rajoutes les certificats, et après, tu updates le fichier host.
Mais tout ça, en quelques clics, tu vois,
tu n'as pas du tout à taper de la console,
donc ça marche pas mal.
Et pour le coup, moi, je suis passé sur un autre projet
qui s'appelle localcan, qui là, pour le coup,
et à mon sens, ça a encore un petit peu mieux designer,
un peu plus propre.
Et en fait, on va avoir différents projets.
Et en fait, on va binder le localhost 3002.
Et on va le binder sur le next.local.
Donc ça, il sera accessible sur notre machine,
mais aussi sur notre réseau,
sur tout notre réseau de local,
ce qui veut dire que si on fait du dev sur notre mobile
hashtag PWA et tout ça,
en fait, on va pouvoir utiliser ça.
Et on va même, en un clic,
pouvoir installer un nombre de domaines
sur le, soit un nombre de domaines
qui nous est fourni par localcan,
de manière aléatoire,
soit on peut même maintenant mettre directement
nos customs des DNS.
Et donc ça, c'est super cool.
Parce que, en fait, c'est super puissant.
Et alors, moi, je l'ai pas encore fait
pour mon projet actuel,
mais l'idée, ça serait de mettre un preview.leNomdeDomaine
de mon client.
En fait, preview, tirer API, preview....
On peut jongler comme ça.
Mais l'idée, en fait, c'est de lui donner accès
à un écosystème pour valider,
on va dire, en amont du staging.
Et surtout, en fait,
que toute ma nomenclature ici, en fait,
respecte la même convention en local,
en staging et en production.
Ce qui fait que ce qui va changer uniquement,
c'est l'extension à la fin,
donc le point local, le point FR,
qui sera, en fait, la version de production.
Et ce qui fait que je viens tout variable-liser, en fait, tout.
Et donc, ça fait tout de mes APIs.
Elle se renvoie toujours sur API,
mon nom de domaine point local.
Et ce qui fait que si, pour X-Raison,
mon serveur, je le fais tourner sur le 5002,
je le change uniquement ici,
mais je n'ai pas reconfiguré l'intégralité
de mes services, parce que pour le coup,
j'ai plusieurs applicatifs qui communiquent entre eux.
Donc, bindé les ports, c'est bien,
mais pour X-Raison, tu dois changer tes ports, t'es baisé.
Et donc, c'est super chiant. Quand tu veux ouvrir ça
à l'extérieur, bah, lui, son local host,
il ne connaît pas. Donc, comment tu fais pour bindé tout ça ?
J'ai trouvé cette solution-là.
C'est ultra-minimaliste, mais ça fait le job.
C'est clair, c'est facile,
c'est hyper compréhensible.
Là, on a l'installation du certificat.
Tu cliques, tu valides, c'est automatiquement,
ça marche, ça le fait automatiquement.
Et super bien.
Tu peux aussi inspecter tout le trafic qui passe.
Donc, tu as une sorte de middleware
où tu viens pouvoir inspecter tout le trafic qui passe.
Super bien. Je suis fan.
Je suis complètement fan.
Je vois ça. Je suis vraiment super emballé.
Ça m'a solutionné un pas mal de problèmes.
Et donc, sans doute, les DevOps vont me dire,
oui, il y a moyen de faire ça.
Dites-le nous. Donnez-moi le tuto
ou l'article qui m'explique comment faire ça
avec trafic ou caddy,
et de manière aussi simple que je peux le faire
avec localcan. Il n'y a pas de problème.
C'est clair.
Et nous, on leur donnera des tips pour faire du CSS.
En troll aujourd'hui.
En troll.
Donc, super outil.
Je suis vraiment fan.
Ça marche.
C'est vraiment dispo que sur Mac.
Désolé, les gars. Faut passer sur Mac.
Désolé.
Mais faut faire ça avec trafic.
Regarde, tu fais ton pitié de config.
Si il y a des outils, pareil.
C'est sûr.
Super.
On fait la...
Pongo.
La migration entre du mango
et du pôse gré. J'avoue.
Je n'ai pas tout compris. Est-ce que tu peux m'expliquer ?
Des fois, on tombe sur des outils, on se dit,
tiens, c'est marrant. Le mec qui a pensé à faire ça, c'est bizarre.
Mais bon, alors on en parle.
En fait, c'est une surcouche à pôse gré
pour faire du MongoDB,
mais avec une base de données pôse gré.
C'est juste une surcouche qui va traduire
le langage MongoDB en requête pôse gré.
Tout simplement.
C'est un tools qui permet d'écrire,
à priori, c'est fait en temps que je n'avais pas fait du Mongo,
mais c'est exactement la même écriture que du MongoDB.
Après, ça traduit tout.
Il y a la même souplesse, sauf que tu as du relationnel.
Ok.
Ce qui m'intéresserait de voir,
comment s'est structuré dans la DB ?
Ça reste du pôse gré.
Ce qui vient changer,
c'est juste la possibilité d'écrire
d'utiliser un peu ton ORM
comme MongoDB.
Après, je ne sais pas comment c'est structuré,
je n'ai pas vu la DB comment ça structure les trucs,
mais tu peux faire, tu vois, tu as un exemple,
Anitta Cruella et rajoute, qu'est-ce qu'il a rajouté ?
Tu as quand même la souplesse, a priori,
d'ajouter des valeurs dans les objets qui n'étaient pas existantes,
dans les collines, tout ça.
Ça rajoute de la souplesse du no SQL,
mais en gardant du SQL.
Personnellement, je n'en ai pas l'utilité
de ce truc, mais comme on disait juste avant,
éventuellement, des gens qui sont sur MongoDB
et qui veulent migrer sur du relationnel
sans tout changer l'écriture, ça peut être utile.
C'est ce genre d'outil pour ne pas tout réécrire.
Après, ce que je vois aussi,
c'est quand même très facile et
c'est super agréable de dire,
« Ok, je prends mon paquet de JSON,
et c'est mon objet.
Je passe en ce qui m'allaisse, je ne me fais pas chier
avec toutes ces infos. »

je ne vois pas tellement
le use case qui me dit
que je pourrais être intéressé par ça,
mais peut-être que si ils ont fait ça,
ils ont rencontré un problème,
et donc de ce problème-là, ils ont trouvé
une solution et ils ont fait pognon.
C'était juste de suivre au dessin.
Storage, voilà.
Je ne sais pas, c'était au-dessus ou avant ?
Storage, voilà.
JSON-B.
Après,
en post-grid, t'as déjà le format
JSON et JSON-B.
Tu peux déjà faire beaucoup de choses dedans.
Tu peux venir taper
la clé de l'objet.
Tu peux déjà faire beaucoup de choses.
Je pense que c'est vraiment pour les personnes
qui viennent de l'univers mongo,
qui veulent garder leur écriture et leur manière
de faire.
Et pour le coup, ils nous disent bien que Pongo n'est pas un ORM.
Donc pour le coup,
il faut bien garder ça en tête.
Ok, c'est...
Mais écoutez, c'est...
Dites le nous pour...
À quel moment on me dit ça, c'est ça qui me fallait.
Allez, on repasse
sur du design, sur des trucs super jolis,
de bons développeurs frontes
que nous sommes et que vous êtes peut-être
ou pas.
Librairie 2 composants qui évoluent, qui passent en version 4,
ce qui est assez majeur.
Une solution, ça s'appelle Prime View.
Donc c'est des composants de
vue, mais je crois qu'il y a un écosyst...
Il n'y a pas un écosystème
réacte aussi derrière Prime, non ?
Bonne question, je ne sais pas.
Je ne sais pas. Ok.
Toujours est-il que Prime View sort en version 4
avec une batterie de composants
bien sûr de plus en plus d'accessibilité,
je ne sais pas combien de blocs, tout est écrit en type script,
et c'est plutôt...
Super propre. C'est quand même super propre.
Tu peux changer la couleur des trucs en home,
c'est pas mal, j'aime bien. Ah oui, tu peux, en fait,
tu peux mettre des presets directs.
Ouais, ça change le composant d'exemple, tout ça.
C'est déjà le site, il est sympa.
Tu peux customiser et tu peux surtout mettre des thèmes.
Et ça, en fait, c'est super intéressant.
Je vois pour...
En fait, tu viens customiser ton thème pour ton client,
mais au final, tes composants sont quasiment toujours les mêmes.
Ce qui fait que moi, je vois ça,
où tu peux industrialiser ton process.
Par contre, tu ne pourras jamais industrialiser ton design
ou ta singularité, ta patte graphique.
Et donc, au lieu de vendre quelque chose
à chaque fois du custom à ton client,
tu lui vends du custom, on va dire.
Mais toi, en fait, tu fais des thèmes,
et en fait, un truc typique, c'est fond blanc,
couleur primaire bleue,
et les bords sont carrés,
et un autre client, ça va être fond jaune,
couleur principale, je sais pas, vert,
et bord arrondi, plus et plus, tout.
Donc, tu viens en fait variable-liser,
tu viens construire tes thèmes,
ce qui fait que t'as pas à recoder la roue à chaque fois.
Et donc, ça, c'est quand même super pratique.
Ce système de thème,
alors c'est déjà mis en place par d'autres librairies
qui utilisent Tailwind,
où tu peux en fait venir surcharger.
Next UI le fait déjà.
Par contre, la somme de composants
qui met à disposition est quand même assez
significative.
Le truc de data, il est pas mal.
Le tableau de data, data view,
ça, c'est puissant quand même, avec les tri et tout.
Et pour le coup,
c'est vachement intéressant de partir
sur des librairies comme ça,
parce que ça a tout de suite de la gueule.
Et il me semble qu'ils avaient déjà fait le shift
sur la version 3,
où on avait une possibilité d'utiliser Tailwind.
Et là, maintenant, c'est pareil sur la version 4.
Il y a possibilité de venir surcharger
tous ces composants et de venir les modifier
et d'utiliser le thème avec les propriétés de Tailwind.
Et je crois que c'est optionnel.
Tu peux faire sans, je crois.
Certainement, c'est bien fait.
De toute façon, pour tout ce qui est admin,
tu n'as pas besoin de t'embêter.
C'est ce genre d'outil qu'il faut utiliser.
On s'en fout de ce style.
C'est du tableau, des listes,
d'éditions formulaires.
Il faut pas s'embêter.
Clairement.
Pour le coup, c'est vraiment propre.
C'est vraiment bien fait.
C'est joli.
Et c'est free to use.
Il n'y a même pas de carte bleue.
C'est accessible.
C'est accessible.
Proper.
Maxi propre.
Astro.
C'est moi qui enchaîne.
On passe sur Astro.
On avait déjà parlé dans un autre épisode.
Il y a 3 parties de Futures d'Astro.
C'était la vision d'Astro dans le futur.
Qu'est-ce qui va être implémenté ?
Pour entamer des discussions avec la communauté.
On est sur le troisième article sur le futur d'Astro.
On avait parlé dans un épisode précédent
du data hub.
Data layer, je crois.
Le système, comme on avait dans Gatsby,
pour connecter avec différentes sources de données.
Et puis les afficher.
C'est le futur et ça va arriver.
La partie 3 parle du futur d'Astro
au niveau des serveurs...
Comment on dit ça ?
Serveurs Island.
On avait déjà les Island au niveau de la partie fronte.
On avait des choses qui étaient hydratées indépendamment
dans la page au moment qu'on choisissait
si c'était au chargement,
si c'était quand l'élément était visible,
ou si c'était quand on interagissait avec lui.
Il y avait différentes façons de faire.
On parle de serveurs Island.
L'idée, c'est d'avoir des éléments dynamiques
au niveau de ta page.
Toute ta page est en HTML, classique.
Astro, je rappelle, fait du statique et du HTML.
On aurait des petits blocs,
qui seraient des serveurs Island.
Renvoyer par le serveur, qui seraient dynamiques.
Il donne l'exemple, il y a une vidéo sur la page
d'une page où il y aurait un élément de connexion.
Les petits avatar s'affichent.
Cette partie avatar arrive un peu plus tard.
On est très proche de ce qui se fait sur Next,
avec les serveurs component, le streaming, etc.
On a des éléments chargés ensuite.
Ça améliore énormément la performance de chargement.
Le top, c'est qu'on a un mix entre pure HTML
et du serveur dynamique.
C'est juste un seul endroit de la page.
C'est prometteur, en tout cas.
Après, je suis complètement fan de Astro,
et surtout dans leur manière d'exécution.
Ils ont réussi à monter une communauté.
Je me rappelle encore, je vois de plus en plus d'articles.
Ils disent oui, le statique, machin, etc.
Ça me rappelle où on se prenait des avalanches de merde
pour être super polies quand on parlait de statiques
de Jamstack en 2016-2017,
où les mecs nous riaient au nez.
Ils disaient que c'est quoi votre truc, mais n'importe quoi.
Aujourd'hui, tout le monde redécouvre le truc.
Je pense qu'Astro a énormément, énormément
œuvré pour ça, pour rendre le statique sexy.
J'ai envie de dire même plein de bon sens.
On n'a pas besoin.
La majorité des sites internet personnels,
tes coachs, je ne sais pas quoi.
Bon, mauvais exemple.
C'est un super exemple.
T'as trois pages.
Objectivement, il n'y a rien de plus dessus.
Tu n'as pas besoin d'avoir un WordPress qui tourne H24
pour trois pages.
Tu fais ça avec Astro, c'est propre.
Ça tourne sur un serveur Netlify,
ou Versel, ou je ne sais pas quoi.
Ça ne va rien de coûter.
Et c'est propre.
Et le pire, c'est que si demain tu veux mettre un blog
ou un machin, tu es aujourd'hui avec tout l'écosystème
de multi-render, donc ça soit côté client, côté serveur,
mais tu ne vas pas sacrifier de la performance.
Et donc, c'est brillantissime ce qu'ils ont fait.
C'est vraiment top.
C'est clair qu'Astro, c'est vraiment un outil
qui est génial, qui est simple d'utilisation,
qui s'adapte aussi à ton niveau, parce que tu peux faire
du simple statu...
Tu peux rajouter du React si tu as besoin, du Vue, etc.
C'est hyper hyper...
Il s'adapte vraiment à ton niveau.
Et surtout, ils écoutent la communauté, tu vois.
Ils proposent des choses, la communauté réagit, tu vois.
C'est pas poussé en force comme...
Alors, je ne vais pas parler de Next.
Attention !
On est sur deux modèles différents, où Next,
il t'impose des trucs et tout, et puis c'est comme ça,
il n'y a pas autrement.
Et puis là, tu as un modèle où c'est OK,
on fait ça, qu'est-ce que vous en pensez ?
Et évidemment, les idées sont super logiques.
Voilà, c'est des outils qui nous facilitent la vie.
Ouais, moi, HyperTan d'Astro,
mon site perso est fait avec Astro.
Il est en statique, j'y touche,
qu'à j'y mange jamais, ça ne bouge pas.
Et tu sais que...
Alors là, je manque un peu de temps
de bande passante,
mais j'ai un client, en fait, qui est sur un site
que j'avais fait, qui était un ancêtre
avec Gritsome, je ne sais pas si tu te rappelles.
Oui, oui, je me souviens.
En fait, c'était l'équivalent d'Astro,
mais en mode vue,
donc c'était que pour des sites statiques,
il y avait plein de connecteurs pour connecter,
sauf que Gritsome n'existe plus,
le projet est mort, tout.
Et les migrations,
les données, tout, comment c'est un peu merdique.
Parce que les connecteurs,
pour coup, mon CMS a évolué,
et donc mon connecteur n'est plus compatible,
enfin c'est la merde.
Et donc, je me pose la question,
est-ce que je ferai pas un shift ?
Vas-y, je mets tout sur Astro,
il y a une maturité,
je me suis déjà fait baiser sur Gritsome.
Donc mon premier effet, c'est de dire,
je vais mettre ça sur Nux,
parce que je mets Trisnux,
je sais que c'est là pour longtemps,
mais je me dis, vas-y,
peut-être faire un Astro,
ça peut être cool, tu vois.
Et je pense que c'est typiquement
le type de projet,
mais bon, il faut faire la migration,
et j'ai pas le temps.
Je sais pas comment je vais faire,
je vais le faire du pli.
C'est ultra rapide, franchement,
la prise en main est super rapide,
après je connais pas la complexité de ton truc,
mais franchement Astro,
si tu ti mets en une journée,
je pense que tu peux migrer,
parce que Astro est tellement bien fait,
la prise en main est ultra rapide.
Alors, un peu plus rapide quand tu viens de réacte,
parce que la syntaxe des fichiers Astro
est plus proche du réacte que de vue,
mais franchement, c'est
tellement simple.
Mais la journée, je l'ai pas, Patrick.
Il annuie ?
Ah, tu le fais déjà, bien.
Donc,
ok.
Mais en tout cas, Astro,
qui nous finit,
qui finit de nous dévoiler
leur stratégie pour le futur.
Ah, c'est le Astro,
le futur est bon.
Allez, toujours dans le futur,
on en a déjà parlé,
et pour le coup,
je ne peux que favoriser ça
à travers mon...
Le mec est sponsor.
Et c'est vrai, même pas,
même pas en plus.
Mais pour le coup, je suis vraiment fan
d'un outil qui s'appelle Melly Search,
qui nous permet de faire de la recherche
à l'intérieur de notre site.
Sauf que c'est vrai que pour piloter
et pour
administrer en fait,
cette instance de Melly Search,
on va utiliser beaucoup, beaucoup de paramètres,
de... voilà,
comment on va optimiser notre moteur de recherche,
quelles sont les paramètres,
les filtres,
le triage,
l'optimisation, les synonymes
et toutes ces choses-là.
En fait, on n'a pas d'interface.
Donc tout se fait depuis Insomnia,
ou Bruno.
Bruno, bien.
Et pour le coup,
là, il y a un
Frenchie
qui a fait un outil
qui nous permet en fait d'administrer
directement son instance
de Melly Search.
Ouais.
Et pour le coup, c'est super
rapide.
On peut soit l'héberger nous-mêmes, soit directement
mettre... donc moi là, j'ai mis
mon adresse locale.
J'ai donné ma clé
pas admin, mais
qui me donne accès, enfin,
si j'ai même mis ma clé admin,
mais c'est ma clé locale.
Et en fait, on va voir tous les index,
les tokens.
Donc vous inquiétez pas,
les tokens que vous voyez ne sont pas les bons.
On est d'accord ? Vous ne voyez pas mes tokens.
On voit toutes les...
Ils sont en locale, donc on a une tradition.
Exactement. De toute façon, il n'y a rien qui peut liquer, c'est en locale.
Et il y a toutes les... cette notion
de tâches.
Et donc, parce que Melly Search
va exécuter toutes ces
l'indexation,
la mise à jour du moteur de recherche,
la mise à jour
des paramètres de recherche.
Tout va se faire de manière
à synchrone. Et donc,
au moment où on va lancer la requête,
le serveur va nous répondre
immédiatement avec
un identifiant de tâches.
Et en fait, cette tâche,
après, elle va avoir
différents statuts, elle va évoluer.
Par exemple, on voit, j'ai eu
deux tâches qui ont faillent,
et j'ai ajouté avec succès
18 000 documents.
En 5 secondes.
Et donc,
on a plein de...
et c'est vraiment
des gros documents.
Pour le coup. Et donc,
en fait, on a plein d'outils
qui nous... enfin, en tout cas,
7 outils.
Exactement. En fait,
7 outils nous permet
de visualiser tout ça.
Et là où c'est le plus intéressant,
c'est
dans la structuration
de l'index.
Là, en fait, on voit
la clé primaire
de l'index, donc, est l'index product.
Mais on va pouvoir
importer des documents, directement.
Mais surtout, en fait, on va afficher
tous les champs qui sont filtrables,
qui sont recherchables, qui sont
triables, qui sont
affichés.
Et pareil sur les dictionnaires
avec les synonymes.
Tout ça, en fait, c'est super
compliqué. Enfin, c'est pas compliqué.
On va le faire directement
depuis Insomnia ou depuis notre
utilisateur de requêtes, en clair, via notre API
REST. Et là, en fait, ça nous donne
une interface graphique pour administrer et gérer
ça. Donc, c'est plutôt
hyper confortable.
C'est hyper confortable.
C'est pas mal parce que tu vois,
effectivement, on n'a que l'interface
avec des requêtes HTTP, machin.
Et là, en fait, quand je vois
les synonymes, le dictionnaire, c'est pas mal
parce que moi, j'ai des clients qui bossent avec
ce qu'on s'appelle
le concurrent Algolia.
Et tu as des gens de la...
Non, mais tu as des personnes lambda de la boîte
qui vont rajouter éventuellement des synonymes
de temps en temps parce que la machine, le marketing
et tout ça. Et tu vois, ces gens-là, tu ne vas pas leur dire
attend, tu fais une requête HTTP avec machin,
bisous. Non, là tu leur...
Voilà, tu leur fournis une interface pour se connecter
et rajouter des synonymes tout ça.
Donc, rien qu'à ce niveau-là, déjà, c'est top.
Et vraiment, vraiment.
Et pour le coup, sur les synonymes,
c'est un vrai sujet.
Parce que, en fait,
d'où l'intérêt, en fait,
d'avoir un système
d'analytique, en fait,
de voir et d'enregistrer, en fait, toutes les
recherches pour voir, pour dire, ok,
qu'est-ce qui se passe, qu'est-ce qui est recherché.
Et, en fait, on se rend compte
que, ben,
si le produit s'appelle
Botillon, les gens, en fait, ils vont peut-être
taper chaussettes, mais ça,
on ne peut pas le savoir, en fait.
Donc, et ben, comment on fait ?
Et après, on crée un synonyme
chaussette, égal à le Botillon.
Et comme ça,
les Botillons
ressortent, même quand la personne a tapé chaussettes.
Mais, pour le moteur de recharge,
c'est vraiment, vraiment, vraiment important.
Ouais, c'est clair.
Par contre, t'as vu,
c'est fait en Next 3.
Oui, j'ai vu. J'ai vu composé Belle dans le code, là,
j'ai dit, ah, tiens, c'est du Next.
J'ai vu, j'ai vu. Donc, c'est
encore mieux, c'est encore mieux.
C'est vraiment qualitatif,
ce projet.
Non, non, c'est vraiment top.
Petite star obligatoire.
Donc, top, top.
Peut-être intéressant, aller voir aussi
sur
une des possibilités
avec le module
Next, de Mellisair, tu peux-être.
Que le développeur
rendu open source.
Mais pour le coup,
pour le coup, ça pourrait
avoir des trucs sympas.
Carrément, Next,
la suite.
Attention, alerte.
Enlèvement.
C'est un peu le cas, ça.
Polyfil.
Polyfil, polyfil. Alors, j'espère que la plupart
d'entre vous, enfin, j'espère que vous
n'utilisez plus polyfil, puisque ça a
pu vraiment lieu d'être. C'est un système
qu'on utilisait il y a un moment
où les brosers n'étaient pas
vraiment standards.
Enfin, c'était pas homogène.
En gros, on n'avait pas 90% du marché
qui était par Chrome.
Donc, on utilisait des polyfil
pour que les GES ne soient pas pris en charge.
Donc, on avait un nom de domaine
polyfil.io
qui était utilisé.
Et on
chargeait ça en CDN, etc.
Sauf que, alors, l'histoire,
la première chose, c'est si vous avez des sites
qui utilisent polyfil.io,
vous allez de suite enlever ça.
Pourquoi ? Parce qu'en fait, l'histoire,
c'est qu'il y a une compagnie chinoise qui a
acheté en février 2024
le nom de domaine polyfil.io,
évidemment.
Et ils se sont amusés à mettre
des petits malware et tout ça.
Et apparemment,
c'est assez difficile à détecter, parce que
c'est assez aléatoire au niveau des horaires,
machin, tout ça. Et quand tu vois,
enfin, il y a pas mal d'articles t'as tué.
Mais voilà, il y a potentiellement un risque
de malware pour vos visiteurs.
Et en plus, c'est super aléatoire.
Vous allez pas forcément le voir, mais à un moment donné,
quelqu'un va arriver, il va avoir un truc qui va s'ouvrir,
ça va être redirigé, etc. Donc c'est très, très dangereux.
Donc première chose,
vous enlevez le polyfil directement
si vous avez des sites qui fonctionnent avec.
Mais c'est brillantissime, ce truc.
Parce qu'en fait, le polyfil
le polyfil par lui-même
prend une version, la retransforme, tout.
Donc en fait,
c'est le moment idéal
pour injecter tout ce que tu veux
à l'intérieur. C'est
machiavélique, mais c'est brillantissime
en
d'exécution. Ah ouais, c'est très malin.
C'est très très malin.
Et tu vois, ils ont attaqué plus de 100 000 sites
déjà là, tu vois, donc
dans l'article. Donc pour le coup,
il faut vraiment faire attention
à ça.
Et il y a une solution
pour à ça. Ouais, en fait,
les mecs se sont réveillés assez rapidement,
mais ça fait tu vois, c'est depuis février, donc
ils s'en rendent compte que maintenant en juin, juin-juillet,
donc c'est un peu tard, donc plus de 100 000 sites
déjà qui ont été piratés.
Donc, immédiatement,
il y a des gens comme Cloudflare
qui ont fait un miroir, en fait,
de la librairie polyfil.
Et donc, un miroir qui va cliner,
qui va nettoyer tout ça, avec un fer-ur-vol et tout ça.
Donc dans l'urgence,
déjà on peut mettre l'URL de Cloudflare
et continuer à utiliser polyfil
si il y a besoin.
Dans tous les cas, généralement,
ça ne sert plus à rien d'utiliser polyfil.io aujourd'hui,
mais c'est trop compliqué pour vous de l'enlever.
Il y a un miroir
chez Cloudflare, il y a d'autres solutions,
tout ça. Mais voilà, il faut vraiment agir
très rapidement, parce que c'est très dangereux
pour vos visiteurs.
Et pour le coup, on mettra évidemment le lien
de l'article
dans la description.
Et après, je pense
surtout sur des
équipes qui ont des produits
un peu
je pense, au SS2Z
ou des choses comme ça, qui ont chippé
des produits, mais pour des clients
où le truc a pas été évolué,
a pas bougé depuis des années,
en fait.
Et pour le coup,
ils ont cette faille
d'ouvertes et potentiellement,
ils peuvent exposer leurs clients
sans même le savoir.
Voilà, ok, on a mis un polyfil,
c'est bon, ça marche, allez, terminé.
Et là,
Le truc de fou, ils ont fait un
domaine en Google
anaitique.
Il y a juste le L qui est changé en I,
donc c'est quasiment pareil.
Et en plus, comme c'est du JLS qui est
injecté, exécuté dans le navigateur,
ça donne beaucoup de pouvoir
à ce domaine.
Énorme.
C'est super malin.
Mais
ça va vraiment foutre le bordel.
Donc, faire
super attention
à ça.
Là, en terme de secure, c'est un vrai
problème.
Top.
À bien faire attention.
Yes.
Petit retour d'expérience.
Allez, on se doit toujours
de parler de symphonie, la ravelle.
On connaît les frères ennemis,
même si ils se battent
sous la même bannière
du PHP.
On ne peut pas nier qu'il y a quand même
une certaine rivalité symphonie, français,
la ravelle américain.
Euh...
Bon, c'est comme ça.
Euh...
Petit retour d'expérience d'un
développeur symphonie
qui découvre la ravelle et dit
les réricains, ils ont fait ça bien.
C'est ça qui dit.
Alors, c'est...
Ouais, ouais, ouais. Le contexte, c'est un
développeur PHP junior.
Je dirais quand même que c'est un junior
qui a en fait, qui s'est formé
sur symphonie et qui travaille principalement
sur symphonie au quotidien. Donc, est très, très habitué
qu'à ses habitudes, vraiment ancré au niveau
de symphonie et donc, qui s'est mis
sur la ravelle pour tester et voir un petit peu
de différence. Donc, c'est souvent intéressant, tu vois,
de voir les retours par rapport
à symphonie, à l'utilisation de symphonie.
Donc, voilà, c'est un article à lire.
Il y a, voilà, il dit qu'il y a des choses bien, des choses
moins bien, des choses qui sont utilisées
dans symphonie, qui ne sont pas utilisées dans la ravelle.
L'impression en général, c'est que la ravelle
est facile. La courbe d'apprentissage est
très rapide par rapport à symphonie.
Et, voilà, le frein mort qui est bien
fait, bien pensé, etc.
Après, voilà, il y a des choses qui
ne sont pas utilisées comme les
attributs PHP et tout ça.
Même s'il y en a dans LiveWire
tout ça, mais, voilà, il y a des choses qui sont
complètement différentes. Le système de base de données
et l'ORM est complètement différent aussi, pareil.
Il y a plein de choses. Donc, c'est intéressant
à lire parce que, voilà, si vous ne connaissez pas
symphonie ou que vous n'avez pas la ravelle,
ça vous permet de voir un petit peu les différences et de comprendre.
Mais dans l'ensemble, c'est un article intéressant,
petit retour sympa. Donc,
à lire, quoi.
Et, ok.
Nice.
Allez,
State of J.S.
On basque
le... C'est l'épisode du troll.
C'est exactement ça.
2023.
En fait, les gars, ils sortent un truc.
Mais,
au moment où ils le sortent,
en fait, c'est déjà obsolète, quoi.
En fait, ils ont mis 6 mois,
pour le publier, en fait.
Les mecs, ils ont mis 6 mois. Alors, on ne va pas leur jeter la pierre
parce que je pense que c'est des bénévoles
en plus, les mecs. Donc, on ne va pas leur dire,
ah, vous êtes des nazes. Les mecs, ils font sa gratos.
Donc, bon.
Merci de l'avoir fait. Par contre,
6 mois de retard, c'est un peu dommage
parce qu'à moitié de l'année,
les choses ont bien changé.
Donc, on ne va pas passer en revue tout ça,
parce qu'il y avait pas mal de vidéos YouTube
qui passent en revue le State of J.S.
Mais dans l'ensemble, en fait,
l'exemple, en fait,
de pourquoi 6 mois, c'est un peu tard,
c'est quand on va dans...
Peut-être, tu peux y aller dans...
Librairie. Librairie, des frameworks, tout ça.
Front-end. Ouais, Front-end framework.
En fait, si tu regardes
le classement, usage,
ou autre comme ça, je sais plus.
Ouais, voilà. Bon, là, on a des études.
En fait, le premier, c'est React, évidemment.
Utiliser massivement, voilà.
On va pas débattre là-dessus.
Mais on voit que Angular
est passé en 3e position
au profit de vue qui est passé en 2e position.
Voilà.
En fait, le truc, c'est que... voilà.
Mais comme ça date de l'année dernière,
eh bien Angular avait pas sorti sa nouvelle version
avec les nouveaux langages, machins,
la simplification, signal et compagnie.
Donc en fait, ça veut... voilà.
En fait, c'est pas vraiment
représentatif du contexte actuel,
puisque là, en 6 mois, déjà, il y a des grosses évolutions d'angular.
Donc tu vois...
Après, est-ce que la nouvelle version d'angular
va redonner un coût de boost
suffisant
pour impulser
une nouvelle dynamique ?
Moi, je pense que oui.
Parce que n'étant pas
développeur angular, enfin spécialiste angular,
je trouve que le framework est vachement plus sexy
là,
par la simplification de son utilisation, tout ça.
De toute façon, dans l'ensemble, les frameworks...
Alors,
alors je sais qu'il y a déjà qui sont en train de dire
« mais réacte, c'est pas un framework. »
Ok, en CES et en hybride.
Quoi que maintenant, avec tous les...
avec tous les hoops, tout ça qu'ils ont rajouté,
ça devient vraiment complexe.
Mais ouais, je pense qu'angular est vu,
vont se battre vraiment sérieusement,
et angular devient plus sexy qu'avant.
Et là, tu vois, c'est pareil. On a des changements.
Le deuxième, c'était Gatsby.
Je crois en rouge.
Gatsby, g...
Je sais pas comment Gatsby peut encore être là,
quoi, je veux dire.
Ah, parce qu'il a été beaucoup implémenté
sur des sites et les mecs, ils ont pas migré, quoi.
Ouais, ouais, mais...
Est-ce que les gens, ils savent quand même que le projet,
il est mort, il n'y a plus personne à la barre,
quoi, tout le monde s'est barré, tout le monde a vendu,
ils ont pris leurs pognons et ils se sont barrés, quoi.
Il y a plus...
Il y a plus personne qui bosse là-dessus, quoi.
Donc, c'est chaud, quoi.
Trit par usage et par...
ou par intérêt, tu vois, au niveau des vieux,
tu verras peut-être que ça va changer.
Ça marche, quoi.
Ah, tu vois, intérêt, tu vois.
Tu vois, Gatsby intérêt, il est...
il a plongé, quoi.
Il a plongé, c'est celui qui est en rouge, en fait, tu vois.
Ouais, bah...
Tu vois, il a plongé, donc c'est fini, quoi.
Ok, alors pour le coup,
il y a... il y a... il y a l'usage,
le... ok, je regarde.
Moi, un véritable intérêt.
La rétention
et le quoi, t'es plus emballé.
Bah ouais.
Ce qui montre le plus, c'est Astro, tu vois.
Astro, il est en train de retomber.
Astro et Svelkit.
Et Next, tu vois, descend un petit peu, tu vois.
Descend, descend quand même pas mal.
20% quasiment de best.
Est-ce que ça serait pas
l'effet versel ?
Je sais pas.
Bon, à toute façon, ils ont fait des choix
qui plaisent pas tout le monde, donc ils ont compliqué les choses.
De toute façon, en tant que dev, on est défaignant
et on aime bien les choses simples, donc plutôt
nous compliquent la vie.
À part si tu fais du java, mais...
Ouais, mais c'est là, en fait,
c'est là toute la complexité, en fait, c'est que
en tant que dev, tu veux de la nouveauté,
tu veux faire des nouveaux trucs,
mais si ça devient trop complexe,
à partir, bah en fait,
tu vas partir sur le nouveau
truc à la mode
et qui est moins puissant,

bah tu veux...
Il y a une sorte de cycle infernal
entre
la trait pour la nouveauté,
la simplification
et l'ajout de fonctionnalité,
qui ne sont pas toujours des mêmes paramètres
qui peuvent évoluer ensemble, tu vois.
Et il faut trouver
la bonne
soltilité de dose entre tout ça
pour que ça tienne dans le temps, quoi.
Bah moi, en tant que dev,
je veux que les choses qui
sont... Il y a beaucoup de choses
qui sont peu intéressantes et qui sont répétitives, donc ça,
je veux que ça soit simple et que ça soit quasiment
même généré automatiquement. Et après, si je veux
faire des choses complexes, je le fais, mais c'est moi qui
choisis de faire des choses complexes. Quand tu as des choses
qui sont complexes, mais pourtant qui apportent pas de valeur,
ça devient compliqué, tu vois. Quand tu dois
faire des classes dans tous les sens,
je m'assoigne des modules comme c'était Angular
avant, alors que tu veux juste afficher
un truc, tu vois, ça prend la tête, quoi.
Ça s'est pas demandé à faire
18 000 fichiers pour afficher
2 000. Ouais, on se rappelle
du formulaire
de contact avec React, où tu avais
une espèce de fusée qui sortait
de... En mode
il faut développer un truc de Mabool
pour faire un contact formes,
tu vois.
Donc, yes.
Voilà. Allez voir
le state of J.S.
2023.
On va
bientôt répondre en 2024.
Exactement.
Allez, nouvelle nouveauté
aussi dans
l'écosystème HTMX
qui
connaît un espèce
d'emballement.
Alors, est-ce que c'est une hype, je ne
sais pas. Est-ce que
c'est des choses qui
solutionnent vraiment des problèmes ?
C'est un point de vue.
En tout cas, il passe en version 2.
Est-ce qu'on peut rappeler peut-être
ce que fait
ce qui est HTMX ?
HTMX, c'est une livrairie JavaScript
que tu rajoutes sur ton site, qui te
permet d'exécuter via des attributs
que tu vas rajouter sur
l'état de HTML, en fait des requêtes
etc.
HTMX est principalement orienté
sur des requêtes à JAX. Donc, il va
chercher du contenu et tu vas remplacer du contenu.
Mais tout ça, en quelques attributs,
tu n'écris pas de JavaScript du tout.
Donc, ça simplifie
beaucoup les choses.
C'est la tendance actuelle
de faire des sites sans
écrire la moindre ligne de JavaScript, mais
juste en faisant des attributs. On a HTMX,
on a Alpin.js.
Alors, Alpin.js et HTMX, c'est pas du tout la
même chose, parce que, comme je te dis, HTMX est
plutôt orienté requête à JAX et tout ça.
Alors que Alpin.js permet de
faire beaucoup plus de choses. Et les deux
ensemble peuvent être pas mal.
Mais c'est cette tendance
de simplifier.
En fait, on est dans une tendance de simplification.
Ça fait quelques années qu'on a compliqué les choses.
On revient en arrière, on resimplifie les choses.
C'est toujours l'histoire
du balancier. Il faut aller
trouver l'extrême
pour aller trouver une sorte de juge de milieu.
De simplification ultime,
complexification pour arriver
à une espèce d'entre-deux
qui est vachement plus
plus intéressant.
Donc, il n'y a pas
de nouveauté de ouf.
La principale évolution,
c'est qu'ils ont viré IE.
Yeah, enfin.
Wow, ça c'est mieux ça.
Donc, ils ont viré IE.
Par contre, il faut savoir que
il y a un truc marrant, c'est que
ça reste en la test,
je crois, si tu peux revenir sur la page
de Bled.
Et reste en la test,
la test,
pour mettre la version 2.0,
il n'y a pas de version 2.0, pour l'instant,
si tu installes, si tu installes HTML,
ça aura la version 1, pas la version 2.0.
Il reste en
Next, jusqu'à
1 janvier 2025, je crois.
La prochaine, ça sera de 2.0.
Et donc, la version
majeure et définitive
sortira le 1 janvier
2025.
D'ailleurs, je dis que
une connerie, c'est pas la toast, c'est
Next.
Ouais, si tu veux
mettre la version 2, t'es obligé
de mettre la version Next.
Voilà.
Et pour le coup, t'as un petit
lien
qui te permet
d'installer directement en CDN.
Et
leur mantra, c'est
« Jamascript fatigue ».
Donc, au lieu
de faire ta requête
en
JS, tu la fais
via tes attributs et ça fait tout tout seul.
Excellent.
Ecoute, Patrick,
je crois qu'on a fait le tour
pour cet épisode estival
du mois de juillet.
On a brossé super large
et super
intéressant. C'est quoi la suite ?
Il y a un petit workshop
qui se prépare.
Ah ouais, alors
déjà, le Coolify a été
super apprécié, l'épisode Coolify.
Et en plus, on a beaucoup de gens qui nous ont marqué
en commentaire « Je veux un workshop ».
Donc là, on a la pression, Alex, tu as la pression, tu vas faire un workshop.
Il faudra donc
faire un workshop sur Coolify,
sur comment
installer, comment
programmer, paramétrer, installer tout ça.
Donc, pour le coup,
on va s'y pencher dessus, ouais.
Et puis, workshop,
prochainement, sur Livewire.
Livewire.
Donc, c'est quoi ? C'est du PHP,
c'est Laravell.
C'est Laravell avec du Alpine.js
en fait.
On a
enfin, en JavaScript,
tiffy, une application Laravell
sans écrire la moindre ligne de JavaScript
à l'HGDHTMix.
Excellent. Voilà. Cool.
Donc ça, c'est le prochain workshop
qui ne sera pas diffusé sur
les plateformes de podcast, évidemment.
Si vous nous écoutez
dans votre appli de podcast,
vous pouvez aussi nous suivre sur Youtube,
si vous voulez voir les workshops.
Parfait.
Merci Patrick. Merci à toi.
Merci à toi. Exactement.
Merci à tous ceux qui sont restés
jusqu'au bout de l'épisode. Pensez à partager
et mettre un petit like, ça fait toujours plaisir.
Et on vous dit à très bientôt.
Ciao, ciao.
Ciao.