Bonjour à tous et bienvenue sur ce nouvel épisode, un épisode où on va parler de Ruby
& Rails avec Guillaume.
Salut Guillaume.
Salut.
Bienvenue à toi sur Double Slash et comme d'habitude, on est avec Patrick.
Salut Patrick.
Salut à tous.
Je ne sais pas si tout le monde connaît Ruby & Rails, en fait qu'il y a un framework
qui est basé sur le langage de programmation Ruby.
Et juste avant de commencer l'épisode, on voudrait remercier Thibault qui est le premier
à nous soutenir via GitHub sponsor et donc un grand merci à lui.
Et vous aussi, vous pouvez soutenir le podcast Double Slash directement avec votre contribution
sur GitHub sponsor.
Merci de votre soutien et passez un bon épisode.
On va sans doute parler de tous les bootcamps.
Il y a surtout un gros bootcamp qui prône et qui enseigne Ruby & Rails.
Mais à la limite avant de partir directement dans le sujet, vu que Guillaume, ça fait
quand même pas qu'est de temps que tu es sur Ruby & Rails, est-ce que tu peux tout simplement
te présenter ? Comment t'es venu à Ruby ? Et qu'est-ce que tu fais maintenant ? Ton
background ?
Oui, carrément.
Et bien enchanté.
Moi, j'ai commencé le dev en 2012 à peu près.
Donc, j'ai commencé avec du PHP WordPress, un bon gros classique de cette époque-là.
Donc, j'ai commencé à mettre les mains dans Rails en 2015 parce que je commençais
à entendre parler de DHH, de basecamp, de tout ça.
Et ça m'a intéressé beaucoup.
DHH aussi qui était très bruyant à cette époque.
Et c'est en fait dans ma première boîte.
On faisait du Rails et je me suis dit, je vais à fond là-dedans.
Et depuis que j'ai fait du Rails, je n'ai plus jamais lâché Rails de toute ma vie.
Depuis que j'ai fait que ça concrètement, que du Rails, j'ai fait énormément de vue
Js aussi et j'ai continué à être super active dans la communauté PHP, notamment
la Ravel.
Mais voilà.
Donc, ça fait quasiment 10 ans que je passe un peu ma vie à coder.
Voilà.
Donc, j'ai un peu mal patié, on va pas se mentir.
Que des bons choix.
Que des bons choix.

Vu la Rails.
Oui, vu la grande main décollée à l'époque, on y reviendra peut-être grâce à la Ravel
parce qu'il a été mis par défaut dans vue.
Donc, si le gain a été énorme pour vue et voilà.
Donc, j'avais mis les mains dedans à la base grâce à ça.
Et après, je m'ai mis dans Rails.
J'ai fait pas mal de confs sur ça notamment.
Voilà.
Et là, actuellement, je suis lit, Dev, dans une boîte à Lyon qui s'appelle Perangusta.
Voilà.
Donc, on fait un SaaS concrètement pour les acheteurs et c'est tout en Rails.
Concrètement, avec Justimulus et DioToyer, mais pareil, on y reviendra probablement
après.
Et voilà.
Concrètement.
Excellent.
Et juste, on a parlé de DHH.
Qu'est-ce que c'est ?
Alors, en fait, c'est pas qu'est-ce que c'est, c'est qui et DHH.
DHH, en deux mots, c'est le créateur de Rails.
Pour remettre les choses dans le contexte, Rails est sorti en 2004.
À l'époque, le web, c'était très compliqué.
Pour faire un blog, il fallait mettre plusieurs semaines voire moi.
DHH a un peu révolutionné la façon de faire des frémiorks.
Et depuis, il est très bruyant dans la communauté et en fait, il a un peu l'idée, entre guillemets,
la façon de développer des frémiorks dans le futur.
Et il y a énormément de grosses boîtes qui sont basées sur son outil.
Donc Rails, par exemple, y a GitHub, y a Basecamp, y a Shopify, y avait Twitter à une époque,
c'est plus le cas.
Donc DHH, c'est un peu notre gourou à tous.
Il a énormément fait parler de lui dans énormément de domaines.
Mais par exemple, si vous utilisez la Ravel, c'est exactement le même paradigme que Rails.
Ça vient de la Taylor-otwell, ce n'en est jamais caché.
C'est quasiment un copier collé de Rails.
En tout cas, dans le paradigme, pareil, on y reviendra.
Mais DHH a été très bruyant et il est très clivant surtout.
C'est quelqu'un qui a un avis très tranché sur énormément de choses.
Et en général, quand il dit quelque chose sur Internet, ça n'est pas indifférent les gens.
Mais ça a permis de des choses très chouettes, ce qui l'a fait, notamment en réduire
considérablement la complexité de faire des applications web.
Et il a des avis très arrêtés, notamment sur le JavaScript, surtout un tas d'outils.
Et voilà un peu le personnage.
Après, très clivant.
Il est super clivant.
Et pour remettre aussi un peu dans le contexte, c'est un Danois qui vit aux États-Unis,
qui bossait pour une boîte qui s'appelle 37 Signals.
Ils avaient des besoins en interne et pour gérer tous leurs projets.
Et en fait, ils se sont dit, on va créer un framework par dessus.
Donc ils ont créé le framework, ils l'ont open sourcé et après, ça explosait.
Et ils ont à la base, ils sont aussi sur un outil qui s'appelle Basecamp,
qui est sur la gestion de projet.
Et en fait, ils ont utilisé Rails pour faire Basecamp.
Et après, ils ont externalisé Rails et on compte le succès que ça a eu.
Rails a été créé dans le seul but de faire Basecamp.
Et après, il a été open sourcé quelques années plus tard.
Mais c'est toujours à l'actualité.
Un Basecamp fonctionne totalement sur Rails.
Et en fait, tout ce qu'ils font chez Basecamp, fini par être open sourcé,
on parlera par exemple d'Ottawa, de Turbolings à l'époque,
de Rails UGS, de tout un tas d'outils qui ont un peu drive jusqu'à l'arrivée
des frameworks France, qui ont un peu drive l'écosystème web global,
bien au-delà de Rails.
Et voilà, beaucoup de choses sortent de Basecamp, en tout cas.
Et voilà, c'est assez intéressant.
Quarriément.
On a déjà parlé un petit peu de l'historique de Rubien Rails.
OK, on va aller peut-être un tout petit peu plus loin.
C'est un framework monolithique, basé sur un pattern MVC, modèle vu controller,
avec un gros paradigme qui est, est-ce qu'on pourrait dire que le gros
paradigme, c'est convention, rebeur, configuration.
Complètement.
Rails, c'est basé sur ça.
C'est d'ailleurs sa plus grande force et sa plus grande faiblesse à la fois.
C'est qu'on dit toujours que Rails est magique.
C'est ce qui permet à la fois d'aller vite et à la fois parfois de rendre
les choses un peu abstraites.
Mais oui, tout est par convention.
C'est très dur de sortir des sentiers battus.
D'ailleurs, le nom Rubien Rails vient de là, c'est que dans Ruby, on peut
faire à peu près ce qu'on veut.
Et le nom Rubien Rails vient de là, c'est pour mettre de l'ordre et de la
convention et s'y tenir.
Donc oui, complètement.
C'est le plus gros paradigme de Rails.
C'est ce qui fait grancer le plus dedans et qui, qui à l'inverse rend aussi.
Enfin, c'est ce qui les gens qui aimeraient les lèvres en partie pour ça, en
grosses parties pour ça.
Et ceux qui le détestent, c'est un peu pour les mêmes raisons.
Tu vois, par exemple, la Ravel a fait exactement ce show là de convention
ou vers configuration.
Il y a eu plein de débats et PHP a énormément évolué bien plus que
Ruby. Mais Symfony, par exemple, c'est le choix exactement inverse.
Et il y a beaucoup de débats dans la communauté, mais les deux, je pense,
se valent et il n'y a pas de...
Je ne pense pas qu'il y ait une meilleure façon de le faire que l'autre.
C'est surtout des, je ne sais pas, je pense du feeling ou des choix.
Mais les gens, par exemple, qui aiment Symfony en général, détestent Rails et
un peu l'inversement.
Mais je caricature.
Alors à noter, parce que tu parles de Symfony, en fait, moi, j'en ai fait
au tout début, version 1 et qui était complètement basé sur
Robin Race avec des choses magiques, etc.
Où je parlais, tu configurais tout en Yamel.
Et justement, au fil des versions Symfony, il y a complètement enlevé ça,
en fait, et devenu plus proche de Java, j'ai envie de dire, entre guillemets,
je vais me faire bâcher par les développeurs.
Mais c'est vrai, quand tu lis, autant au début Symfony, t'es vraiment très
proche de la philosophie de Robin Race, qu'aujourd'hui, c'est
complètement l'opposé.
Ouais, c'est ça.
C'est en Symfony, en caractérance, si tu veux faire quelque chose, il faut
écrire 18 fichiers différents pour tu sais exactement par quoi tu passes.
Pour ça que je parle déjà.
En fait, tu fais un fichier, tu as une page qui s'affiche, en fait.
Et ouais, la différence entre les deux est majeure.
Mais en fonction des cas, des situations, des équipes de la taille des équipes
et de la maturité des équipes du projet, les uns peuvent avoir, enfin, l'avantage,
ça peut être à l'avantage de l'un ou de l'autre, mais ça dépend les cas.
Ouais, après, est-ce qu'on peut dire que c'est vraiment un choix ?
C'est un paradigme, je dirais même, une façon de coder, une façon de voir le
code, une façon de vraiment de concevoir ton application.
C'est prisme de penser.
C'est vraiment.
Ouais, clairement.
Et d'ailleurs, ça se, ça va bien au-delà de Rails.
Par exemple, tous les outils qui gravitent autour de Rails ont complètement ce
paradigme en tête.
Je pense à TurboLinks, à Toyeur.
C'est, tu le mets, ça marche avec 95% des choses qui sont faites par défaut.
Si tu veux sentir des outils, tu es bâtue.
Techniquement, tu peux, mais en général, tu n'as vraiment pas envie de te dire ça.
Et du coup, c'est ça, c'est le paradigme.
Ça applique à la façon dont sont codés les applications, même dans ceux qui
utiliseraient, c'est bien au-delà du framework.
Et en tant que maintainer d'orels, du coup, parce que je me suis énormément
occupé de la partie stimulus et auto-wire et surtout webpacker à l'époque, ça
va jusque là-dedans à fond, en fait.
C'est-à-dire que par défaut, on veut accompagner le développeur pour qu'il
ait la meilleure DX possible.
Et voilà.
Et par exemple, si vous suivez de près l'écosystème la Ravel, Taylor-Rothwell
a complètement cette philosophie en tête.
C'est-à-dire que la Ravel vient avec tout un tas de choses, que ça plaise ou pas,
ça vient avec un tas de choses.
Et en 10 minutes, on peut avoir une application en prod qui fonctionne
avec son lot de problèmes dans l'autre sens, mais n'empêche que
voilà, ce n'est pas allié à Rails.
On a ça un peu partout.
Après, tu vois sur TurboLink et Auto-Wire, on va y revenir, juste pour introduire le truc,
c'est l'injection de tout le JavaScript moderne, des composants, tout ça,
sur un pattern MVC, comment on allie le meilleur des deux mondes.
Mais on va y revenir un petit peu plus loin.
Patrick, tu avais une question ?
Oui.
En tant que noob sur Ruby on Rails, tu dis que tout arrive et que c'est un peu magique,
tout ça a été vachement guidé, mais du coup, est-ce que c'est facile de devier,
d'arriver ? Est-ce qu'il y a une flexibilité au niveau du système pour réussir à faire
ce que tu veux ?
En fait, c'est compliqué.
Mais tu n'as pas besoin que ça, ou si tu as besoin que tu peux te reposer la question
de est-ce que j'ai vraiment besoin de faire ça, donc ça peut t'aider à te dire,
si tu sors trop des rails ou tu vas trop loin, est-ce que c'est vraiment ce que tu as envie
de faire ?
C'est d'ailleurs ce qui est reproché parfois à certains autres langages en disant,
comme tu es libre de faire tout, par exemple en go, c'est un des principales reproches
que certains font à go, c'est que tu peux tellement tout faire que parfois tu te
y retrouves, mais tu n'as pas forcément envie de faire ça, et du coup chacun code un peu
comme assasos on va dire.
En rail, tu peux faire ça, mais l'avantage c'est que déjà de ne pas le faire, c'est
que tout le monde a à peu près la même vision, c'est-à-dire que quand tu changes
d'un projet rail, quand tu changes de boîte, tu te y retrouves.
Donc oui, tu peux le faire, mais c'est pas que c'est complexe, c'est que tu sais jamais
trop si tu sens que tu es en train de construire un peu un château de cartes.
Par contre, en tant que créateur de gemmes, c'est un bonheur parce que tu vois, tu
peux qu'on va faire énormément ce qu'on appelle de monkey patching, qui est une insulte
en symphonie, les gens qui font des symphonies détestent ça, ils vont faire plutôt de l'injection
de dépendance, ce genre de choses.
En rail, je t'arrête juste Guillaume, parce que en fait, des gemmes dans le monde rubi,
pour ceux qui ne connaissent pas le monde de Rubien Rels, les gemmes c'est la librairie,
c'est l'équivalent de NPM sous Nod dans l'univers Rubien Rels.
Quand vous faites un compositeur install, quelque chose, en rubi, ça sera la même chose,
sauf que ça s'appelle une gemme.
On va énormément utiliser ce pattern-là, c'est un peu ce qu'on ferait par exemple
avec les façades en ravelle, c'est-à-dire qu'on va mettre à des positions des trucs,
et le developer va pouvoir s'en servir.
Donc là, les gemmes sont pensés pour pouvoir surcharger justement ou sortir des rails,
mais en tant que consommateur de gemmes ou consommateur du framework rails, c'est quelque
chose qu'on va avoir un peu tendance à vouloir éviter.
En gros, il te force, ça restait simple.
En fait, il te reste.
Et de toute façon, quand tu commences à développer en rails, en général, la philosophie, si
tu n'aimes pas, en général, tu quittes rails, mais si tu là t'aimes bien rester, tu peut-être
vouloir absolument être à peu près dans les clous, parce que c'est quand même confortable
d'être de suivre la convention, tu te retrouves de projet en projet, tout le monde a fonctionné
à peu près de la même manière, etc.
Et est-ce que tu crois aussi qu'il n'y a pas une sorte de convention sur l'équipe, c'est-à-dire
le fait d'enborder des nouveaux devs ou de faire grossir ton équipe, le fait d'avoir
des conventions hyper fortes, en fait, ça va un peu faciliter la convention, parce qu'on
sait que dans une équipe, on a tous des manières de coder différents.
Mais là, en fait, le fait d'avoir un frémoire qui nous impose, c'est cette manière de faire
en termes de velocité de nouvelles features, tu ne crois pas que pour l'équipe, c'est
aussi vachement facilitant.
Ah, carrément, tu ne vois pas, pour prendre un exemple en dehors d'orails, mais c'est
pareil, je ne sais pas si vous vous souvenez, enfin moi, je n'ai pas vécu ça, mais à
l'époque, DH avait fait une vidéo pour faire un blog en 25 minutes.
Cette vidéo a eu le même effet que la sortie de l'iPhone en 2007.
Les gens ont applaudi dans la salle en mode qu'on peut faire un blog en 15 minutes,
mais comment est-ce possible ? Parce qu'à l'époque, vraiment, pour faire un blog, il
fallait trois mois et demi, donc il y a 225 fichiers.
Donc oui, clairement, là aujourd'hui, ce que prône par exemple Rails ou ce que prône
la Ravel, parce que c'est quasiment les mêmes preuves, alors que à l'exception
du langage.
Oui, c'est ça.
C'est que en étant tout seul, tu peux monter un SAS, tu peux commencer à créer de la valeur
et avoir une application en prod à la fin de la journée.
Ok, il y aura tout.
Ok, tu n'auras pas tes règles métier, tout ça, mais tu auras quelque chose qui tourne
et qu'un humain tout seul peut à peu près comprendre comment ça marche, maintenir en
termes de DevOps, maintenir en termes de tout ça.
Donc oui, clairement, c'est compliqué de sortir des rails.
Par contre, c'est exactement ce qu'il se passe pour une application normale, on va
dire, et avec des besoins normaux, etc.
Donc oui, clairement, la rapidité de développement et la rapidité de déploiement de mise en
ligne, etc.
C'est un énorme atout.
On pouvait le voir déjà à l'époque où justement, quand Basecamp avait besoin de
mettre quelque chose à jour ou de déployer quelque chose, il pouvait le faire dans la
journée là où d'autres équipes ou sur d'autres frameworks à l'époque, fallait
déployer, c'était beaucoup plus compliqué, je ne sais pas si vous avez l'impression
que c'était à l'époque, mais c'était un peu la galère.
Donc oui, clairement, la rapidité.
Oui, mais clairement, la tête a parfaitement répondu et tout, c'est super clair.
Moi, j'ai été rubiste, je suis passé du côté JS et je suis passé du Darkside.
J'ai lâché au Rubien Rull, c'était sur la version 5.
Ils sont à quelle version maintenant ?
Alors là, on est en 7 actuellement.
C'est un peu comme la Ravel.
Aujourd'hui, on va dire que la Ravel, depuis la version 6 à peu près, on peut la considérer
comme mature et dire qu'entre la version 6 de la Ravel et la version 9 ou la version
5 de Rails à la version 7, il y a des trucs qui vont changer évidemment.
Ça ne peut pas révolutionner le concept.
On est sur des frameworks qui sont stables.
C'est des ajouts de features.
Ils vont mettre un focus sur la perte ou sur des choses comme ça.
C'est ça.
C'est-à-dire qu'il ne va pas y avoir de changements de paradigme.
Mais en général, on fait une majeure exactement comme dans la Ravel.
On fait des majeures pour avoir un peu un effet d'annonce, parce que c'est un breaking
change ou parce qu'il y a quelque chose de révolutionnaire.
Symphonie fait ça, par exemple.
Il n'y a pas de grosse version de Symphonie qui sort tous les quatre matins parce qu'il
n'y a pas besoin.
On a déjà les outils dont on a besoin.
Tous les outils sont à peu près éprouvés.
C'est ce qu'on appelle des boring technologies.
C'est que oui, ça marche.
Il n'y a pas grand-chose à dire dessus.
Ça fonctionne et ça fait le café.
Oui, bien sûr.
Donc l'upgrade de version en version, ça se passe sans problème aujourd'hui.
Oui, clairement.
A moins que vraiment, tu es justement surchargé un peu de manière un peu forte tout ton truc.
Normalement, les changements de version sont assez simples.
La plupart des frameworks monolithiques aujourd'hui, en vrai, changent de façon de passer d'une
version à une autre.
Il n'y a plus trop d'enjeux normalement.
Et tu vois, moi aujourd'hui, je fais quasiment que du vu et du next.
Je suis un gros, gros fan de next.
Quand tu viens de Rails, ça ne fait pas tout seul.
Une next est en train d'évoluer et c'est parfait.
La version 3 va sortir, c'est cool.
Mais en tout cas, moi, je retrouve cette convention over configuration où tu mets ton fichier
dans le bon dossier et il est interprété automatiquement dans une route.
Tu n'as pas à configurer ton routeur, tu n'as pas à configurer tout ça.
Le déploiement aujourd'hui se fait aussi super facilement sur n'importe quel provider
où ils viennent utiliser des fonctions serverless ou des choses comme ça.
Alors, on se rapproche un peu.
On en est encore loin.
On est bien d'accord.
Mais c'est des briques où on vient rajouter, je pense, un Prisma, par exemple.
Qui vient gérer ton data model.
Là, tu as un fichier Prisma qui va déterminer ton data model, qui va te créer tes migrations.
Tu vas pouvoir les appliquer.
En fait, on est en train de retrouver un peu cet esprit.
Je dis bien cet esprit un peu Ruby and Rails, mais on n'y est pas encore.
Tu parlais de boring technology.
On n'a pas été un peu hype-driven, on est complètement envouté avec du VODO sur
du JS, sur tous les frameworks qui nous ont vendus mon Témerveil.
Et au final, on se rend compte qu'un bon vieux paterne MVC, ça tu le match.
Je ne peux pas être plus d'accord.
J'ai fait pas mal de confs sur ça.
Là, tu vois, quand je vois par exemple sur Twitter, ou la plupart des blogs post qu'on
peut voir, ou la plupart des confs qu'on peut voir, en fait, c'est des frémoires qui,
historiquement, s'attend sont morts pour la plupart.
Mais en fait, il y a une hype autour de la résolution d'un problème qui a été résolu
il y a 15 ans dans l'écosystème PHP, ou Rails, ou Ruby, ou n'importe.
C'est-à-dire que là, par exemple, Nux, c'est très bien.
Il met justement, ça pourrait s'appeler vue on Rails, c'est quasiment le même principe.
Mais oui, complètement.
C'est-à-dire que là, on va se hype pour des choses nouvelles.
Mais en fait, la résolution du problème, ou ce qu'on essaye de faire derrière avec
ces outils-là, parce que ça reste des outils pour répondre à un besoin et pour créer un
business derrière ou ajouter de la valeur derrière.
Clairement, on se hype pour, je trouve, la plupart du temps pas grand chose.
C'est-à-dire que le routine automatique, ça existe dans la plupart des frémoires depuis
très longtemps maintenant.
Tout un tas de systèmes existent depuis très longtemps maintenant, mais on a une vague,
on en reviendra sûrement après, de développeurs qui ont voulu faire d'utiliser que des nouvelles
technologies par peur, peut-être qu'ils soient plus difficilement recutables, etc.
On pourra y revenir.
Mais clairement, on essaye de re-répondre au problématique, de un peu réinventer la roue,
en tout cas, je trouve sur certains points, sur cette nouvelle techno, parce que c'est
plus à la mode de faire du laravelle, c'est plus à la mode de faire surtout du rails.
Rails a pris un gros coup dans les dernières années.
Clairement, quand je vois, par exemple, ce qu'on peut faire avec NUXT ou ce genre de
technologie, moi, de mon point de vue de rails, on le fait de...
C'est un ou deux.
Ouais, end.
C'est quoi la suite ? Qu'est-ce que tu peux faire de plus ou de mieux ou de plus rapidement
ou comment tu peux créer plus de valeur ou arriver plus vite sur ton marché avec ta
technologie, comment tu travailles mieux avec tes collègues ou en open source avec cette
technologie ? Pour l'instant, je n'ai pas la réponse.
NUXT, c'est très bien.
Et d'ailleurs, NUXT a le même problème que rails pour sortir des sentiers battus sur
NUXT, c'est assez compliqué.
Du moins, on sent que ce n'est pas fait pour.
Mais ouais, du coup, la hype a vraiment drivé la notre écosystème, les cinq.
En fait, depuis React, concrètement depuis 2015 à peu près, 2015-2016.
Et ça, cinq, sept ans.
Et qu'est-ce que tu penses des métaphrées moires un peu type Redwood ?
En fait, tu vois où il y a plein de gens qui viennent de l'univers rails et ils basculent
et qui, en fait, Redwood, on avait invité Simon qui fait partie du Core Team.
Et en fait, c'était super intéressant.
Mais ils utilisent des techno et ils les agglomèrent entre elles pour faire ce métaphrées moires.
Donc, il y a du Prisma, il y a du Storybook, il y a du React.
Il y a vraiment plein, plein de choses.
Toi, ton point de vue de bon rubilliste sur Redwood ?
Je ne vais pas, c'est pas Redwood particulièrement, mais oui.
Clairement, en fait, j'ai l'impression qu'on avait un problème.
On y reviendra après, mais on avait un problème.
On a essayé de le déconstruire et là, on essaie de retrouver la solution pour revenir
à des frameworks mononautiques.
C'est-à-dire que l'écosystème JavaScript, à partir de React, à partir de Angular et
l'explosion de React après, a eu la problématique de, en fait, ce n'est pas des frameworks
où tu as des outils qui sont en place, c'est des librairies sur lesquels il faut aller
connecter des trucs.
Et en fait, les équipes se sont retrouvées avec des problématiques où il fallait trouver
un moyen d'avoir un routeur, d'avoir un truc pour accéder à des données, pour pouvoir
faire des fetches ou des appels réseaux ou mettre des choses en cache, ce genre de
choses.
Et ça, sur tout un tas de problématiques.
Et en fait, on se retrouve avec des Redwood ou des d'autres équivalents dans JS principalement,
où ils se disent, ok, on a cette problématique de « vous devez choisir plein de petites
librairies qui ne sont pas maintenues par les mêmes personnes ou qui ont du mal à communiquer
ensemble ».
Nous, on vient, on a fait un choix pour vous de toutes ces librairies-là.
On s'engage à les maintenir et du coup, on met tout dans un seul framework.
Du coup, on se retrouve un peu à vouloir créer un framework comme Rails, la Ravel et
tout ça, mais avec des outils qui sont un peu différents.
Et honnêtement, à part pour pouvoir vouloir faire à 200 % du JavaScript, j'ai l'impression
qu'on a recréé des frameworks de toute pièce.
Donc, je trouve que c'est un peu Frankenstein comme appart.
Mais pourquoi pas ?
La problématique que j'ai, c'est que tu vois par exemple dans l'écosystème de vue,
on va avoir tout un tas de librairies.
En général, on voit dans les packages.jv, il y a des dizaines et des dizaines de dépendance.
Ils n'ont pas tous le même DSL, ils n'ont pas tous la même approche ou presque.
Alors, d'en vue, ça va encore.
D'en réacte surtout, c'est flagrant.
Tout ce qui n'est pas maintenu par React et en général, c'est un peu chacun fait à sa sauce.
Donc, ça marche bien, mais n'empêche que quand tu arrives dans un projet ou dans une
nouvelle équipe, tu dois quasiment tout réapprendre.
Et pourquoi ? J'ai rien con.
Le moins de là, ça plaît à des gens.
Moi, j'ai un peu du mal avec ça, sachant que moi, je viens d'un écosystème qui est
très conventionné où on fait les choix pour toi et le but, ce n'est pas d'utiliser
ou de te… En fait, dans Rails, tu ne poses pas la question de comment je fais ça.
Tu poses la question de pourquoi je fais ça.
Et historiquement, quand j'ai fait du vue et du React, parce que j'ai beaucoup fait
le React aussi à ces débuts-là dans cette période, je me posais plus souvent la question
de comment je suis censé afficher ce bouton ici et comment il est censé se mettre en
cache ou comment il est censé faire l'appel réseau, etc.
C'était plein de questions techniques là où, dans Rails, j'avais pas besoin de me
me disais mais qu'est-ce que je veux mettre en place pour mon site, pour mon site, pour
mon business, etc.
Et ça, l'approche a beaucoup changé, je trouve, avec ce que je veux vraiment, comme
on va être au bout des compagnies.
Est-ce que tu penses que maintenant, en fait, on a une sorte de maturité qui arrive
dans cet écosystème où on revient peut-être un peu à la raison et on dit, ok, on ne va
pas recoder la roue parce que même si aujourd'hui, c'est peut-être moins vrai maintenant, mais
l'argent coule à flot dans la tech, donc on ne va pas faire de la tech pour de la tech.
Mais on revient un peu à la raison en mode, ok, on va se focus sur le business et au
final, un bon vieux monolithique, ça fait le taf.
Et est-ce que tu ne trouves pas qu'on arrive à une certaine maturité ?
Clairement, je trouve que depuis le Covid surtout, il y a eu un peu, en fait, entre 2015,
pour ceux qui l'ont vécu entre 2015 et 2020, tout vrai Twitter, tout vrai n'importe quel
blog post d'un dev, tu avais pourquoi React, c'est mieux.
Pourquoi 8, mieux, regardez comment.
Je ne sais pas si vous avez vu qui ça.
Bien sûr.
Je crois que t'allais dire qu'il y a un framework JS tous les jours.
Oui, en plus de la technologie.
Mais clairement, regardez ce que je peux faire quand mon état définit mon interface et
regardez ces magies qu'avant fallait faire ça, ça, ça et ça.
En fait, moi, je trouve que si on remet un peu de contexte historique avant de parler
d'aujourd'hui, c'est que je trouve que si on est passé sur du React, du Angular et
du VU, c'est que déjà, ce n'est que des grosses boîtes qui ont créé ça.
On ne le dit jamais, mais c'est Google, et c'est le pattern.
En fait, ils ont les problématiques que Google, que seulement Google a finalement,
qui a un milliard d'utilisateurs tous les jours sur son application.
On n'est pas beaucoup sur Terre à pouvoir dire ça.
Pareil pour React avec Facebook, ils avaient la problématique de, il fallait qu'ils gardent
la raison principale de React, c'est qu'ils devaient rester, les gens devaient scroller
à l'infini sur React.
Et du coup, il y avait tout ce système de les illuding, il y avait le chat en bas qui
a ces problématiques là.
En vrai, on n'est pas beaucoup et on n'est pas beaucoup à pouvoir se le permettre financièrement.
En fait, il y a eu un peu, je trouve, cette haine du JavaScript un peu chiant, du coup,
qui marchait bien, mais qui était un peu chiant.
Et quand on est arrivé à ça, les gens se sont jetés dessus.
Et du coup, on s'est retrouvés avec des devs qui soit faisaient que du front, soit que
du back.
On a perdu un peu de côté full stack qu'on pouvait avoir en 2015.
Et aujourd'hui, on se retrouve avec d'autres problématiques qui n'existaient pas avant,
donc à savoir comment faire communiquer les équipes frontes, les équipes back, comment
faire en sorte que justement, les données, comment on transfère les données entre eux.
Donc on a eu GraphQL, on a eu tout un tas d'inventions.
Mais clairement, c'est un vrai problème parce que quand tu viens spliter ton front de ton
back, tu mets un layer au milieu, tu mets une couche.
Et après, tout ton debug, il est vachement plus compliqué parce que c'est quoi ? C'est
en front.
Parce que après, tu as tellement de composants que tu vas mettre, moi j'appelle le back
du front, tu vois, tout ce système de store.
Vas-y, tu vas sortir la phase dans pas longtemps, je la sens.
C'est ça, c'est ça.
Je vais la sortir.
Mais donc tu as ton front, tu as ton back du front, après, tu as ton API, après tu as
ton back qui va traiter et ça mène vachement plus de complexité.
Et en fait, tu perds vraiment ce côté hyper rapide parce que tu es en est venu rajouter
de la complexité.
C'est ça.
Ce que je dis toujours aux développeurs qui sortent de bootcamp par exemple parce que
il y a eu vraiment cet effet de vague de nouveaux arrivants sur le marché du dev.
Ils ont vu des articles de rack de partout et quand tu ne sais pas, quand tu n'as pas
c'est historique, tu dis tout le monde fait du rack.
Il y a une offre d'emploi sur deux qui est un rack.
Il faut que je fasse du rack.
J'ai pas le choix.
Tu vois, si je veux être embauché quelque part, il faut que je fasse du rack.
Et le pire, c'est qu'ils veulent faire du rack, mais ils sont mauvais en JS.
Et tu vois, ce que je leur dis tout le temps, c'est que quand vous avez fini votre partie
front, vous en êtes qui a la moitié de votre application.
Il reste toute la connexion avec le rack, toutes les problématiques de transfert de
données, de identification, de sécurité, de déploiement.
Comment tu vois, j'ai travaillé en freelance, enfin j'ai fait un peu de freelance dans
une boîte.
Quand on développait, quand on déployait la partie back, il fallait gérer justement
le personnalité de certains trucs.
Il fallait être sûr qu'on catch les erreurs si la route côté back n'existait pas.
Dans un fréquentement de monotique, ces problématiques-là n'existent pas.
Tu déploies, ça marche.
Tu gênères de l'argent.
Et depuis le Covid, je trouve que les frameworks, en tout cas les frameworks historiques, monolithes,
ont un peu regagné en popularité.
Principalement grâce à la Ravel, on va pas se mentir qu'ils sont très actifs sur ça.
Je trouve en tout cas où ils disent, en fait les gars, est-ce qu'on peut revenir un peu
en arrière, pourquoi on avait besoin de réacte ?
Pour faire de l'interactivité, mais à quel niveau ?
En fait, à quel point on avait besoin de rendre nos app réactifs ?
Et il y a énormément de frameworks qui se sont développés sur ça, qui s'intègrent
parfaitement dans des applications monolithiques classiques.
Et on les reviendra, mais je pense à LiveWire, Inertia, HotWire évidemment avec Turbolings.
Donc tous ces frameworks-là, ils ont pour le discours qu'ils nous vendent, c'est
de se dire, ok, vos interactions vont être minimales.
Vous n'avez pas besoin d'un énormément d'interactions pour commencer à générer de l'argent et à vivre de votre business.
Mais nous, on vous fait le café, on vous fait quasiment tout le travail sans que vous ayez une ligne de JavaScript à écrire.
Et ça, je trouve que c'est absolument révolutionnaire.
Pour le coup, c'est la première fois que j'ai un peu un effet wow depuis 10 ans concrètement.
Parce que quand tu arrives, tu es un développeur tout seul ou tu es 3 dans ton équipe, ta boîte,
tu sais qu'elle a un an de cash flow pour survivre.
Et bien, ton but, c'est d'arriver le plus vite sur le marché et de commencer à porter de la valeur à tes 7 à 7.
Là où on réacte, tu vas devoir avoir deux personnes minimum qui travaillent d'un côté et puis de l'autre.
Il faut avoir peut-être un DevOps pour déployer tout ça et que ça ne tombe pas en marche.
Et ainsi de suite, ainsi de suite.
Donc clairement, clairement, je suis d'accord avec toi.
Oui, mais carrément, après, on arrive à une certaine maturité, c'est évident.
Est-ce qu'à la limite, on peut parler un petit peu plus de hot wire, de stimulus, tout ça ?
Parce que c'est utilisé en ruie, c'est utilisé, tu l'as dit, la ravelle, c'est info.
Et est-ce qu'on peut vraiment plonger dans la mécanique de hot wire ?
Et pourquoi en fait, toi, actuellement, t'as l'effet wow ?
C'est quoi hot wire ?
C'est quoi hot wire ?
Alors, je pense qu'avant de parler d'hot wire, je vais faire mon petit historien,
mais je pense que c'est hyper important pour que les gens comprennent pourquoi on en est là aujourd'hui.
Mais j'en ai pour une minute.
Hot wire, déjà, c'est à dire HTML over the wire.
Et c'est le fier héritier descendant d'une technologie qui s'appelle TurboLinks.
TurboLinks, ce qui nous vendait, c'était de se dire, OK, vous voulez l'application qui soit reactive,
donc vous ne voulez pas de rechargement de page.
Et vous voulez que quand vous soumettez un formulaire, par exemple, dans un formulaire de commentaire,
vous ne voulez pas recharger la page et se devoir scroller pour pouvoir voir le commentaire.
TurboLinks, ce qui nous vendait, c'était de se dire, en écrivant votre HTML boring,
votre boring HTML de manière complètement classique,
on va rajouter quelques artifices en JS dont eux s'occupent pour pouvoir ne pas avoir à recharger les pages.
Par exemple, tous les liens d'une page étaient catchés,
c'est-à-dire que quand tu cliquais sur un lien, une encre classique, tout ce qui a de plus chiant,
le contenu était chargé en Ajax et on remplacait la page en Ajax.
Donc tout ça, on n'avait absolument rien à écrire et ça a donné des applications
qui étaient ultra réactives avec pas une seule ligne de JS à maintenir.
Il y avait ça pour les formulaires, etc.
Sauf que ça a ses limites, on l'a vu, les applications deviennent de plus en plus complexes,
on a envie de faire de plus en plus de trucs un peu stylés.
Et au toit hier, c'est le descendant de ça et le but, c'est d'aller encore plus loin là-dedans,
donc avec la notion de frame, mais peu importe le concept,
on peut voir ça comme des composants, même si ce n'est pas comparable,
mais on peut imaginer ça en composants, on va essayer de découper notre page
et chaque frame, chaque composant va avoir son contexte indépendant
et elle va pouvoir interagir avec le backend de manière complètement transparente.
En tant que développeur à full stack,
vous n'avez pas à écrire de JS,
vous avez juste à agencer des bouts de la page pour qu'elle soit réactive et que vous n'avez rien à faire.
Donc au toit hier, le concept, c'est de se dire,
vous n'avez pas envie d'écrire du JavaScript,
vous n'avez pas envie de construire une API, de la documenter, de la maintenir,
de savoir quelle donnée tu envoies à ton front,
comment gérer l'authentification que tu es front, comment déployer deux apps en même temps.
Le but, c'est que tu fasses du bac et seulement du bac pour faire simple.
Les intégrateurs font l'emboulon d'intégrateur,
mais l'objectif, c'est de dire, ok, je déploie mon application,
il y a de l'interactivité suffisamment pour que ça soit smooth,
mais en même temps, tu ne vas pas recréer Facebook après-demain.
En gros, l'objectif, c'est de se dire que 99% des projets que tu utilises
au quotidien sur Internet, ça suffira largement à ce que tu as besoin de faire.
Mais le hotwire, il fait quoi exactement ? Parce que tu as par exemple un formulaire,
tu l'envoies à ton formulaire, il fait quoi ? Il va chercher le résultat,
il découpe le morceau de résultat, il l'insère à la place.
Qu'est-ce qu'il y a ?
Oui, en gros, par exemple, imagine que ça a une balise forme classique avec une action,
il y a un endpoint.
En gros, ce que ça va faire, c'est que sur tous les formuleurs de la page
et tous les lins de la page, il va catcher l'événement de soumission du formulaire.
Donc un peu comme on le ferait en réacte.
En réacte, quand tu soumis un formulaire, c'est toi qui gère le payload,
c'est toi qui fait tout à la main pour faire simple.
Et en fait, il va catcher ça, il va aller exécuter la requête,
il va prendre la réponse et en fonction de la réponse,
il va tout seul réagencer la page en fonction de ce que tu lui demandes de faire
pour afficher un résultat dynamique.
Ça marche très bien, quasiment tous les cas.
J'avais fait des vidéos sur ça si on les mettra peut-être dans les notes,
en gros, c'était refaire le bouton « j'aime » de LinkedIn.
Tu vois, tu es sur une page, tu scrolles.
Quand tu cliques sur « like » il y a une petite animation
et ça met à jour le compteur de « like ».
Donc c'est tout bête.
En Java Street, il faudrait faire une machine à ETA
probablement avec un FET, une API, ce genre de choses.
Là, tu vas lui dire, ok, je pointe vers une route reste classique.
Ça va mettre à jour le nombre de « like ».
Et le retour, en fait, c'est le bac qui va générer la réponse en HTML de retour.
On va la prendre et on va la remplacer.
On va remplacer le formulaire par sa réponse.
C'est tout.
Et ça, ce n'est pas à toi qui a besoin de le faire.
C'est à toi ailleurs qui fait tout pour toi.
Tu as juste à lui dire, c'est ce retour-là de la réponse
qui remplacera le formulaire.
Je ne sais pas si je suis clair, mais en gros, l'objectif, c'est de te dire,
c'est toi, tu définis qu'est-ce qui remplace quoi et lui, il s'occupe de tout.

Ce qui nous vende, la façon dont c'est pensé, c'est ça.
Tu enlèves la partie JSON, tu enlèves la partie API, tu enlèves la partie machine
ITA, tu enlèves la partie build, toute la partie tout le chaine que tu as en node
avec NPM, ce genre de choses.
Tu n'as besoin de rien, à part agencer du HTML correctement pour faire simple.
Et donc, par contre, tu ne peux pas utiliser vue ou réacte,
on fait vraiment abstraction de tout framework.js.
Alors, tu peux 100% utiliser vue si tu as besoin de dans cette notion de frame.
Si tu veux un bout de vue.js pour X raison, tu peux complètement le faire.
En général, le but, c'est par exemple, il y a plein de libres et vues qui sont très
bien pour faire des pickers, pour faire des color pickers, ce genre de choses.
Si tu veux que ce dat picker soit en vue.js, tu peux complètement le faire.
Il sera juste chargé au chargement de la page et tu auras vue.js seulement sur cette partie-là.
Donc, ce sera un composant en vue classique, par exemple, je parle de picker.
Et puis, non, ça va marcher exactement la même manière que ça marcherait
au début du chargement de la page.
Donc, toute ton application, ça renvoie vraiment tout,
ça renvoie des pages HTML comme à l'ancienne, on va dire.
C'est juste que certains bouts de la page sont dynamiques et pas d'autres.
Ça, c'est lié à Ruby ou rien à voir?
Tu prends le Twitter et tu l'installes n'importe où?
C'est un peu le problème que Rails a eu historiquement, c'est que tu as toujours
eu des outils qui étaient vraiment trop bien pensés.
Par exemple, Rails, UGS, TurboLinks, ce que je vais me présenter,
on pouvait croire par leur nom que c'était vraiment exclusif à Rails.
En fait, ils n'ont jamais été.
Tu peux très bien faire du TurboLinks en Larabelle.
Pour ceux qui connaissent GraphicArt, par exemple, ça a toujours été historiquement
une application en symphonie, pas pendant un certain temps,
mais depuis qu'il est en symphonie, il a mis au Twitter sur son application.
En fait, ça marche très bien avec symphonie.
C'est vraiment purement JS, il n'y a aucun lien avec le bac.
Du coup, on peut s'en servir absolument partout.
Et pour l'anecdote un peu rigolote, symphonie, pour ceux qui font du symphonie,
donc top atrique par exemple, tu dois avoir entendu parler de symphonie UX,
qui est justement la partie JS de symphonie,
qui est vraiment complètement basée sur TwiR.
Donc, en fait, les gens qui font aujourd'hui du symphonie en mode monolithique classique,
donc sans appeler tout ça, profitent déjà aujourd'hui de ce que
on a fait dans Rails.
Et ça, c'est trop cool.
Ça, c'est trop cool et on peut s'en servir comme ça.
Donc, on voit, non, ce n'est vraiment pas lié au bac,
c'est vraiment une technologie purement fronte pour simplifier la vie des développeurs back end,
mais on peut s'en servir littéralement n'importe quel framework.
Super.
Voilà.
Mais d'ailleurs, pour l'exemple, c'est un des plus gros projets que j'ai fait en PHP.
C'est la Ravel blog sur GitHub.
C'est l'un des plus gros projets la Ravel de GitHub, si vous voulez aller voir.
C'est rigolo parce que pour l'exemple,
comme j'aimais bien HotWire et que je voulais faire une confe
sur comment utiliser HotWire en dehors de Rails,
en fait, j'ai réfecto avant, c'était du vu.
Et j'ai fait une PR qui ne sert qu'à ça,
à enlever vu pour mettre HotWire à place
et montrer qu'on peut réduire potentiellement la complexité
parce que j'ai plus une seule ligne de JS en fait dans cette application.
Par contre, j'ai gardé exactement la même expérience utilisateur.
Il n'y a aucun rechargement de page.
Les commentaires se mettent dynamiquement.
Le nombre de likes, ce genre de choses se mettent à jour dynamiquement.
Et c'est complètement deux technologies qui sont séparées.
Donc ça, c'est trop cool.
Et aujourd'hui, est-ce que tu vois une différence entre...
Là, on a parlé d'HotWire, stimulus, LiveWire, Inertia, Unicorn.
Tout ça, c'est les mêmes patterns, c'est les mêmes fonctionnements
où ils vont avoir des façons de faire un peu différentes.
Mais sur le pattern, c'est le même ou pas ?
C'est ça.
En gros, l'idée derrière, c'est la même.
Par exemple, tu comparais Inertia avec HotWire.
Le principe, c'est juste que Inertia est très pensée pour faire du VGS,
mais en vrai, on s'en fiche.
Le pattern, c'est éviter au maximum les rechargements de page,
faire des interactions qui sont communes,
celles qu'on voit dans la plupart des sites qu'on utilise.
Et l'objectif, c'est de réduire la complexité de communication entre le front et le back.
C'est-à-dire que quand tu fais de l'Inertia, par exemple,
toute la communication en API, tu n'as pas à le faire.
C'est Inertia qui fait tout pour toi avec les conventions d'Inertia.
Donc, c'est pareil, convention over configuration.
Mais l'idée derrière, l'approche, c'est exactement celle-ci.
Pour aller même plus loin, je ne sais pas si vous avez vu,
là depuis React, tu avais fait un truc,
je ne sais plus comment ça s'appelle pour le coup,
mais c'était React Components qui chargeait des components côté source server.
Donc en gros, l'idée, c'était de pouvoir générer des choses côté serveurs
pour les renvoyer au front.
Pareil, c'est très Frankenstein family,
mais en fait, il y avait vraiment ce côté,
cette volonté de remettre un peu plus de choses vers le back.
Et voilà, toute la logique reste côté back,
et ces outils-là servent à simplifier seulement la communication entre le front et le back,
et faire des interactions de base concrètement.
React Components arrive sur la version 18,
en fait, c'est les sortes d'objets de components qui sont sous forme d'objets,
et après, c'est recomposé dans la...
Ben, c'est assez magique, mais encore pas mal de travail là-dessus.
Mais ça arrive bientôt.
Non, c'est ça.
Et en gros, l'approche, c'est de se dire,
« OK, on a certaines problématiques qui sont liées au front,
et c'est surtout la communication entre le front et le back pour faire simple.
Et là, React Components, c'est une approche
qui pourra résoudre potentiellement ce problème.
Mais on s'est retrouvé dans des problématiques,
par exemple les machine-itals.
C'est un des plus gros problèmes qui avaient eu sur React historiquement,
vu avec VX qui marchait très bien,
mais des machine-itals sur React, y en a autant qui a du moins sur...
C'est un coup.
Des machine-itals, on se retrouve dans des paradigmes qui sont fous,
parce que vous l'avez sûrement vécu dans votre équipe,
mais il y avait ce côté où la base de données,
côté back, c'est elle qui fait foi, c'est l'état des données.
On les envoie en API ou en Gison à notre front,
et du coup on se retrouve avec une machine-itale de l'autre côté
qui va servir à générer l'interface de manière dynamique et tout ça.
Et chaque API, l'API va permettre de régénérer l'interface web,
mais le but final, c'est que les deux déjà soient synchronisés entre elles.
Et en plus, on avait ce paradigm,
mais en fait, ce que tu veux faire, c'est juste mettre à jour dynamiquement
une partie de ton interface.
C'est pas de...
Tu n'as pas besoin de faire des calculs compliqués côté front,
parce que de toute façon, tu devras aller valier le côté back.
Du coup, le paradigm, c'est de se dire tout ça, on l'enlève,
on garde toutes les machines à état, toute la state machine,
tout ce genre de choses, tout reste côté back,
et on rende leur tout côté back, et on envoie le résultat côté front,
et le navigateur retrouve un peu ce pour quoi il est fait,
juste afficher de l'HTML concrètement.
Ce qui est super intéressant, c'est qu'on voit en fait
sur l'évolution, que la complexité était sur le back,
après, elle s'est déplacée sur le front.
Ça a amené d'autres problèmes, elle revient sur le back.
Et en fait, tu vois, c'est vraiment deux paradigmes,
où maintenant, les équipes back vont dire,
« Ouais, on va tout faire de chez nous, parce qu'on a du hotwire et machin,
et tu as les mecs du front qui vont dire, « Ouais, nous avec du next machin,
on va faire quasiment la même chose, parce qu'on va faire que du JS,
et en fait, on va tout faire aussi. »
Mais en fait, c'est vraiment deux approches.
Les deux approches veulent résoudre le même problème.
Et c'est là où c'est super intéressant.
Et après, nous, je pense, en tant que développeur, il faut se positionner.
C'est « OK, qu'est-ce qu'on choisit ? »
Et « On va faire du front magique » ou « On est front »
et « On va faire du back magique » tu vois.
Et en fait, c'est super intéressant.
Par contre, je pense vraiment que ce niveau de maturité,
en fait, de positionnement, en fait, en tant que dev,
tu peux la voir que quand t'as exploré les deux.
Tu vois, en clair, il faut jouer avec les deux pour choisir
et vraiment arriver une sorte de maturité en termes de skills.
Carrément. Et tu vois, je ne sais pas si vous vous faites du recrutement.
En ce moment, je l'en fais énormément.
Et tu vois, on a le problème de, c'est ce que je disais un peu en début.
Là, c'est qu'en fait, aujourd'hui, avec la hype,
avec les blog posts, avec les conférences, tout ça,
il y a des développeurs qui n'avaient expérimenté qu'un des deux côtés.
Et ils se disaient « OK, le monolithique, on s'ennuie un peu.
» C'est-à-dire que toutes les réponses, on les a déjà.
C'est pas très sexy, en fait.
Ça marche et du coup, on se fait un peu chier.
Du coup, il y avait ce côté de « Est-ce que je vais pouvoir rester,
je veux pouvoir, est-ce que je suis encore dans le game dans cinq ans
si je continue de faire du rails et du symphonie ? »
Et oui, intéressant.
Du coup, avec des gens qui étaient en mode,
mais vraiment, j'en ai vu autour de moi, à Lyon, principalement,
qui étaient paniqués en disant « Mais si je continue de faire du symphonie,
dans trois ans, je n'en ai plus non, pas en fait. »
Et pourquoi ? Parce qu'ils se retrouvaient,
j'exagère, mais vous voyez ce que je veux dire,
ils se retrouvaient avec des armées de candidats qui arrivaient en disant « Moi,
j'ai appris le réacte, je vois une off sur deux qui ont réacte,
je veux faire du réacte. »
Et en fait, les entreprises étaient face à un choix en disant.
J'en ai vu beaucoup comme ça qui disait « Nous, on a une techno,
la techno, elle marche, elle nous rapporte de l'argent,
elle fait tourner notre business, mais on a besoin de recruter
parce qu'on a besoin de grandir. »
Et on se retrouve dans la problématique de « En fait, on a besoin de recruter,
mais on n'a que des gens qui veulent faire du pour caricaturer,
qui veulent faire du réacte. »
En fait, on est dans le choix de soit on recrute pas
et on essaye de galérer, à trouver des gens qui font encore notre techno,
soit tant pis, on mise tout sur réacte.
Et pourquoi je parle de ça ?
Parce que par exemple, Dr.Lib, je ne sais pas si vous avez écouté
ce qu'il y avait à la conférence entre le CitiO de Dr.Lib et HH.
Il disait « En fait, on a des réactes, non pas parce qu'on en avait besoin.
Dans Dr.Lib, c'est l'application la plus normale techniquement du monde.
Ils ne font rien de bien fou. »
De magique, c'est ça.
En fait, Dr.Lib, c'est une carrécature pour ça.
J'adore tout ce qu'ils font là-bas parce qu'ils disent justement
qu'on est l'application, une des applications les plus vues de France,
comme le bon coin, ce genre de choses.
Et en fait, nos besoins techniquement sont minuscules.
En fait, c'est que des problèmes de scalabilité qu'ils ont quasiment.
Mais la problématique côté expiensusciteurs est quasiment inexistante.
Et du coup, par contre, ils avaient besoin de recruter énormément de gens
pour justement parer à tout ça.
Et la plupart des gens qui pouvaient recruter, c'était des gens qui faisaient du réact.
Donc, qu'est-ce qu'on fait ?
Un moment, il va falloir sauter le pas et on fait du réact tant pis.
Ça, c'est très fort.
Ça, c'est très fort.
C'est qu'en fait, les boîtes ont été obligées de se mettre à réact
parce que par le déficit de candidats.
On a formé trop de frontes et pas assez de back-end gros fois.
C'est un peu mon poste-lui-là.
Je ne dis pas que j'ai raison.
Je dis juste que je le vis, en tout cas, clairement comme ça,
dans le sens où avant, étoilément, on avait un peu l'inverse.
C'est les boîtes qui drivaient un peu le besoin qu'elles avaient.
Et aujourd'hui, avec le Covid, le remote, le télétravail, tout ça,
on avait un peu ce paradigme de « on a besoin de gens et les gens peuvent être exigeants ».
Du coup, on a beaucoup de candidats qui disent,
« OK, moi là, je suis d'accord avec ce que vous faites,
mais dans un an, je veux être formé à ça, je veux être formé à ça,
je veux être formé à ça, je veux être sûr d'être à jour ».
Il y avait un peu cet effet de « hype, driven, development ».
Disant « vu pourquoi les gens font autant de vues,
pourquoi les gens font ontandréac, pourquoi les gens font ça, ça et ça ».
Et quand tu n'as pas connu historiquement ce qu'on pouvait faire avec Rails,
ou la Ravel ou n'importe quoi,
tu n'as pas vraiment envie d'aller sur ces techniques-là,
tu te dis « est-ce que je vais encore être à la page, tout ça ».
Et tu ne crois pas qu'il y ait aussi aujourd'hui les gros frameworks
et les grosses boîtes, on va te dire à Rose, à coup de développeurs advocate,
est-ce que Facebook indirectement a poussé son framework
à créer énormément de tutoriels,
et en fait, ils viennent de manière indirecte,
injectée dans un écosystème de formation et de techno,
pour devenir le leader et pour limite imposer,
mais en soft power, imposer leur techno.
Après, de là dire que c'est un plan, je ne pense pas,
mais c'est forcé de constater qu'il y a quand même beaucoup de monde
qui pousse le truc.
En vrai, je ne peux pas dire que c'est vrai,
parce que quand tu regardes Rails, en niveau advocate,
on est un peu mal placé pour ce plan de ça,
parce que DHH, niveau advocate dans tous les sens,
on a assez spammé internet pour dire que Rails, c'était trop bien.
Du coup, est-ce que c'est du soft power ?
Peut-être, mais je ne sais pas si vous avez vu,
il y a les créateurs de React,
donc il y a bien longtemps, en 2013, ils avaient fait une interview
justement qui disait pourquoi ils ont besoin de React,
et en fait, les gars étaient développeurs de chez Facebook,
ils devaient répondre à un besoin,
et pour le coup, React dans le contexte de Facebook est super pertinent.
En fait, pareil pour GraphQL,
les besoins de Facebook sans GraphQL,
je ne sais même pas comment ils faisaient avant,
parce que l'interface de Facebook,
parce que le besoin de Titanesque qu'a Facebook,
nécessite potentiellement cette complexité-là.
Donc du coup, je ne sais pas,
il s'est peut-être, je pense, dégâts qui voulaient juste
mettre à disposition une techno qui, eux, répond à leurs problèmes.
Comme DHH à l'époque,
quand il a fait Basecamp avec Rails et qu'il doit open source,
je ne sais pas s'il y avait un aspect macabélique derrière ou...
ou qui voulait faire du soft power pour mettre tout le monde sur le vie.
Mais en tout cas, oui, il y a vraiment cet effet de...
En fait, c'est un peu ce côté de...
Tu cours parce que tu vois les gens courir autour de toi,
mais tu ne sais plus vraiment pourquoi on court.
Il y a une erreur, il faut absolument faire du React parce que...
Est-ce que...
Tu vois ce que je dis aux étudiants quand je donne des cours,
il y a ce côté de...
Vous faites du React, très bien.
Est-ce que vous savez pourquoi on a eu besoin de créer React ?
Et là, présente-moi le business que tu veux faire à la fin de...

Il n'y a personne qui va me faire...
Gros blanc.
Gros blanc.
Ils ne peuvent pas deviner.
Et en fait, quand on leur dit,
bah ok, c'est quoi, est-ce que tu peux me pitcher un peu le business que tu as envie de faire ?
Quel SaaS ou app tu veux faire ?
Bah en fait, c'est des...
Une page statique en index.html,
succirait en fait.
Ou un WordPress succirait.
Donc, mais c'est juste que c'est pas sexy, un WordPress.
Mais ça fait le café dans 80% des cas en fait.
Bien sûr que...
Donc voilà.
Il y a un peu ce côté de, on sait plus trop pourquoi on fait ça.
Et je ne dis pas que c'est nul.
Moi, j'adore vue.
Tu vois, j'en ai fait pendant quasiment 4 ans, un peu plus.
J'ai contribué à vue.
Vraiment, j'ai adoré cette techno.
C'est juste que pour remplir mes besoins,
pour remplir ce que...
Pour générer de la valeur dans ma boîte ou dans mes projets open source, tout ça,
Ben, au toit hier, fait le café dans 99% des cas, tu vois.
Ouais, ouais.
Bon, de toute façon, c'est l'éternel problème.
C'est ce que tu disais aussi au niveau du recrutement.
Les gars, ils se sont mis à réacte parce qu'ils ne trouvent que les gens qui font du réacte.
En fait, on a toujours tendance à choisir la techno avant les besoins.
Et alors qu'il faudrait déjà regarder le besoin.
Et après, on choisit la techno qui correspond.
Et c'est... on a toujours ce problème.
Ouais, c'est ça.
Ouais, 100%.
Et en plus, avec le Covid, ça s'est accentué.
Tu vois, les gens pouvaient changer de boîte en claquant des doigts,
et en doublant leur salaire.
Il y avait ce côté de, ou même certains freelance,
ils disent, en ce moment, j'ai envie de prendre go.
On va faire du go.
Et c'est très pertinent dans plein de cas.
Mais on a eu cette vague un peu de...
Et ce n'est pas du tout une crise qui est loin de là.
Mais en tant qu'entreprise, on est face à cette problématique
de les gens peuvent choisir la techno qui veulent faire,
et ce sur quoi ils veulent s'orienter.
Et même en un terme, tu vois, à ce côté, pourquoi on ne mettraient pas du vue?
Parce que j'ai envie de faire du vue, mais très bien.
Mais pour le business, qu'est-ce que ça apporte à la fin de la journée?
Yes.
Yes.
Mais sur ces belles paroles, très claires,
sur des débats un peu clivants, mais super intéressant.
Non, mais c'est vraiment super intéressant de...
Moi, ce que je vois, tu vois, on a vraiment fait un pas de côté,
et on regarde un peu vraiment l'écosystème,
qu'est-ce qu'il y a bien, qu'est-ce qu'il y a pas bien.
L'évolution, bien malin, celui qui sait comment ça va évoluer demain, tu vois.
Mais en fait, bien se tenir au courant de ce qui se fait,
et ce qui s'est déjà fait.
En fait, je pense que ça peut vachement nous apporter d'informations
et avoir une vue un petit peu plus pertinente sur la techno qu'on utilise.
Yes.
Merci Guillaume.
Merci pour ton retour.
Retrouvez-nous, mesdames et messieurs.
Sur la forme de podcast préférée, et sur le site NINETIPODCAST.com,
www.frash.fr, sur le site, vous allez retrouver tous les diens d'épisode,
des références, et vous recriez durant les vies.
À la prochaine.
Ciao ciao.
Merci.
Salut.
Ciao, merci.