Episode 12 - Les signaux en JavaScript | MiXiT On Air

Description

La réactivité et les signaux : démystifions la magie du frontend.

Dans cet épisode, nous discutons avec Estéban Soubiran sur la réactivité et les signaux en JavaScript. Entre Vue, Solid et Angular qui adoptent cette approche, nous explorez une nouvelle philosophie de développement frontend. Comment Alien Signals influence la standardisation TC39 pour une web plus performant et une expérience développeur transformée.

Invité.es :
- Estéban Soubiran

Interviewers :
- Hubert Sablonnière
- Cédric Exbrayat

Liens de l'épisode :
- https://mixitconf.org/2025/la-reactivite-et-les-signaux-demystifions-la-magie-du-frontend

Enregistré le mercredi 30 avril 2025 lors de MiXiT 2025

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue sur Mixit On Air, où la tech rime avec l'éthique. Je suis Hubert.
Speaker #1
Et moi je suis Cédric.
Speaker #0
Et à chaque épisode, nous plongeons dans les coulisses de la conférence Mixit pour vous faire découvrir les innovateurs et innovatrices qui façonnent notre avenir numérique. Aujourd'hui, on a le plaisir d'accueillir Esteban Soubiran, développeur web full stack chez MyAspace. Et avec lui, nous allons explorer la réactivité et les signaux dans le monde du JavaScript.
Speaker #2
Saut la terre ! Saut la terre ! Je vais vous prendre une crêpe au sucre.
Speaker #1
Salut Esteban et bienvenue sur Mixitoner, merci d'être avec nous. T'es venu nous parler des signaux et d'une librairie qui s'appelle Alien Signals. Est-ce que tu peux nous dire un peu comment tu t'es retrouvé à t'intéresser à ce sujet ?
Speaker #2
Ouais, déjà bonjour tout le monde, salut les gars. Excellente question, comment on commence à s'intéresser à une librairie comme Alien Signals ? Peut-être que déjà on peut expliquer ce qu'est Alien Signals. C'est une librairie qui implémente des signaux pour faire de la réactivité, notamment côté front-end, qui est très bas niveau, et suffisamment bas niveau pour que derrière l'algorithme puisse être utilisé dans différents langages. Donc ça c'est hyper intéressant, mais nous aujourd'hui c'est plutôt côté front-end qu'on va l'utiliser. discuter j'imagine et comment on commence à s'intéresser à ça je pense que c'est beaucoup de curiosité c'est se poser la question de qu'est-ce qui se passe dans le framework qu'on utilise au quotidien, et essayer de se questionner sur pourquoi, à un moment donné, quand on fait un truc dans notre interface, le code derrière qu'on a écrit réagit de telle manière. Et c'est de là, de fil en aiguille, qu'on commence à lire un peu de code source du framework qu'on utilise, et puis on suit les gens sur différents réseaux, et puis ils retweetent des trucs, ou ils partagent des trucs. Et puis on finit par tomber sur un gars qui a fait une librairie, qui s'appelle Aline Signals, et puis tu lis le code d'Aline Signals, et tu te retrouves à comprendre comment fonctionnent les signaux. Après des semaines,
Speaker #0
et des semaines à avoir lu le code source qui étonnamment tient dans deux fichiers quelques centaines de lignes et toi c'est quoi ton framework un peu utilisé un peu en ce moment qui t'a amené à atteindre ça ouais pendant très longtemps j'ai fait pendant deux ans j'ai fait l'angular de manière professionnelle parce que pas le choix mais
Speaker #2
à côté ça fait depuis 2018 que je fais du avec toute la partie de vue 2 où tu crées ton objet data et où là il y avait une magie exceptionnelle là j'ai jamais creusé le sujet un petit peu sur la notion de proxy mais sans plus basé sur des proxys je crois Vue 2 était pas encore sur les proxys,
Speaker #1
c'est arrivé quand j'y crois puisque les proxys existaient, ça aurait été avec MyScript 2015 donc c'était pas encore mais ça utilisait une technique un peu différente avec DefineProperty mais ça faisait un peu le même principe
Speaker #2
et ensuite derrière Vue 3 avec sa composition API que là j'utilise depuis que c'est sorti donc 2019 je crois un truc comme ça et là c'est dans mon temps libre à côté des trucs pro et là depuis décembre de manière pro c'est du Vue.js que j'utilise
Speaker #0
Alors depuis quelques années on entend beaucoup parler des signaux, peut-être un deux ans, un peu plus, ça dépend de votre assiduité dans votre veille. En quoi c'est différent d'autres approches de réactivité qu'on a connues avant ? On a évoqué ce qui avait été fait dans Vue 2, Vue 3. C'est quoi, pour les personnes qui nous écoutent, les signaux ça apporte quoi ? En quoi c'est différent ?
Speaker #2
Je pense qu'il y a deux choses qui sont importantes dans les signaux. La première c'est déjà d'un point de vue expérience utilisateur. L'un des trucs qui fait les succès des signaux et de manière générale de cette approche réactive, parce que quand on parle de signaux, l'implémentation de Vue.js aujourd'hui et de ce qu'ils appellent la Composition API, avec les refs, les computables, les watchs, c'est aussi des signaux. On peut le comparer à des signaux, c'est des mots différents, mais c'est des signaux. C'est toute l'approche que ça amène sur la facilité d'utilisation. que ça apporte et donc en terme d'expérience développeur c'est vraiment un gros gain là où VJS apporte un truc en plus c'est que sa Composition API est agnostique du langage ce qui n'est pas le cas dans d'autres frameworks par exemple chez Angular c'est pas le cas, il faut absolument que tu aies Angular autour donc ça c'est un autre truc, c'est que derrière tu as de par cette réactivité là qui ont été capables de... ils ont été capables de l'extraire du framework j'ai beaucoup parlé du JS mais parce qu'ils ont été assez pionniers là dedans ils ont poussé pas mal de choses et le fait d'être capable d'extraire cette réactivité ça a permis des nouveaux frameworks comme Alpine qui est entièrement basé donc Alpine qui permet un peu similaire à Unpoly ou à HTMX qui vous permet de mettre un peu de balises dans votre HTML pour faire des trucs réactifs dans votre HTML un seul fichier javascript et donc là Alpine aujourd'hui est entièrement basé sur la composition API de vue. Et donc il y a ces deux points là et après d'un point de vue plus développeur mais développeur de librairie, ce qu'apportent les signaux c'est ce côté hyper performant, beaucoup plus performant que les approches qu'on avait avant et surtout ça ouvre de nouvelles portes. Parce qu'en fait depuis le début sur le framework front-end, c'est toute cette notion de comment on fait une interface qui est réactive. et après le système de réactivité lui a beaucoup évolué ces dernières années mais l'objectif principal ça a toujours été de comment quand je clique sur un bouton il se passe un truc ailleurs sur ma page et toujours l'objectif c'était de faire le truc le plus performant possible et le plus robuste le plus performant possible et il y a eu plusieurs évolutions et là avec les dernières avancées du Javascript et beaucoup de bonnes idées parce que aujourd'hui l'implémentation de Synos c'est surtout des bonnes idées des choses intelligentes et beaucoup de tests qui ont été faits on en arrive à un truc qui est hyper performant, qui est beaucoup plus performant qu'avant et en plus plus agréable pour les développeurs donc c'est win-win pour tout le monde.
Speaker #0
Là tu disais que la partie composition API de vue elle est agnostique à vue. Genre moi je fais des web components un peu bas niveau sans l'intégrer dedans pour y rajouter de la réactivité.
Speaker #2
C'est addviews slash composition et tu l'installes et tu l'utilises. Et tu as tous les trucs de base donc les refs, les watchs, les computed.
Speaker #1
C'est un peu la même mécanique pour le coup, tu disais en Angular c'est pas vraiment agnostique, mais en fait chez Google ils ont deux frameworks principaux, ils en ont un qui est public qui s'appelle Angular et ils en ont un autre interne qui s'appelle Wizz, qui permet de construire YouTube, Google Search, etc. Et en fait les signaux justement ils sont agnostiques, c'est-à-dire ils sont extraits de tout ça, et ils sont partagés en interne chez Google entre les deux frameworks, donc tu as toute une partie en fait... pareil qui serait réutilisable de façon agnostique ils ne le poussent pas vraiment, c'est pas vraiment l'idée et même pareil pour Vue Reactivity je pense qu'il y a assez peu de gens qui l'extraient pour vraiment l'utiliser mais le concept est un peu le même dans les différents frameworks, c'est que ces briques de base elles sont au final pas tant liées aux frameworks que ça ce qui fait qu'il y a justement cette standardisation qui arrive, tu peux peut-être nous en dire quelques mots puisqu'il y a un effort qui est fait un peu là-dessus Oui,
Speaker #2
effectivement il y a un proposal du TC39 donc quel comité J'ai plus le terme exact mais...
Speaker #0
Technical Committee ?
Speaker #2
Oui ça doit être ça. Qui est le comité qui vise à établir les standards du JavaScript. Et donc il y a un TC39 sur la réactivité et sur la mise en place de la création de signaux directement au sein des Runtimes. Donc la création d'une spécification pour les signaux pour que les Runtimes l'implémentent. Donc Runtime côté... enfin dans V8, donc côté serveur, côté client, un peu partout. Pour l'instant, c'est dans un stade de création. Il y a des premières briques de specs, il y a une première implémentation qui a été faite par le TC39 qui est la moins performante de toutes les implémentations du Cineo. Mais parce que ça a été fait dans l'objectif simplement de montrer que la spécification est réalisable, que ce n'est pas un truc juste théorique. Mais aujourd'hui, il y a la possibilité d'utiliser l'implémentation, enfin plutôt la spécification du TC39 à partir d'une librairie comme Aline Signal. puisqu'elle est tellement bas niveau que c'est possible de la recréer, de recréer la spécification du TC39.
Speaker #1
Ce qui est peut-être intéressant de préciser, c'est que l'aspect qu'elle a été portée au TC39 par les équipes qui font les frameworks. C'est-à-dire que c'est principalement les équipes de Solide, Ryan Carnato, qui est quelqu'un qui a beaucoup popularisé le concept de signal ces derniers temps. Il faut dire que les signaux, ça remonte assez loin dans l'historique du JavaScript. Le concept existait déjà dans des librairies comme Knockout, qui existait il y a très longtemps, qui s'était un peu fait éclater par la popularité de React, qui est arrivé avec un système différent, et le JS DOM, etc. Et il y a des librairies comme Solid, qui ont été faites par Ryan, qui disaient, non, mais les signaux, c'est une bonne idée, et puis on ne serait pas obligé de faire du JS DOM pour le rendu derrière. Du virtual DOM. Du virtual DOM, oui, pardon. Oui, pardon, excuse-moi. J'ai dit n'importe quoi. Virtual DOM. Et qu'on pourrait faire un truc beaucoup plus fin pour la mise à jour du DOM derrière. Et il a réussi à faire beaucoup de vulgarisation là-dessus et à convaincre des gens des frameworks. Donc Evan, par exemple, de Vue.js, qui a finalement adopté ça en Vue 3 comme concept. Rich Harris,
Speaker #0
l'auteur de Svelte. Il a brandé ça un peu différemment pour Svelte, je crois, avec des ruins. C'est globalement des constructions. C'est vraiment le même. c'est la même idée sauf que lui il pousse en plus son pré-processeur beaucoup plus fort il y a quelques problèmes c'est pas le sujet d'aujourd'hui mais ce sera un sujet hyper intéressant avant qu'on creuse Alien Signal avec lequel t'as pas mal joué du coup si moi je vais voir un peu l'aspect du TC39 enfin le brouillon je vais voir quoi, c'est des nouveaux types c'est des nouvelles api ça va on va pouvoir en faire des poli fils et c'est leur chemin new signal ou un peu comme les promesses finalement on peut les poli filet à toute l'époque où il n'était pas encore sous supporté
Speaker #2
dit nativement quoi ouais du coup il ya effectivement ils ont qu'ils ont tout implémenté Et c'est effectivement rigolo que tu soulignes que ce soit le similar au promess parce que même eux quand ils l'expliquent et quand ils le descrivent, ils parlent aussi des promess parce qu'ils sont dans cette même idée là. Et donc tu as tout un polyfile, justement c'est l'implémentation qui sont faites, donc elle est accessible via un polyfile que tu peux utiliser. Et donc aujourd'hui ce serait des nouveaux types qui seraient disponibles dans ton navigateur ou dans n'importe quel runtime et tu aurais un nouvel objet signal. qui auraient différentes propriétés, et notamment une propriété de state, donc l'équivalent du signal, d'un lien de signal, d'une ref, d'en vue, et tout ça, une computed, là pareil on ne change pas les noms, et la possibilité de faire des effects et tout ça. Et donc c'est implémenté, et ce serait effectivement un nouvel objet, un nouveau namespace dans le runtime.
Speaker #0
Alors toi du coup, tu en as fait un sujet que tu as présenté à Mixit 2025, tu t'es intéressé à lien de signal, donc si j'ai bien compris c'est... Au départ, on créait un système de signal, ça a inspiré la spec, et maintenant c'est une impléme de la spec ? C'est un peu ça ou pas du tout ?
Speaker #2
Alien Signal ?
Speaker #0
Ouais.
Speaker #2
Alien Signal n'implémente pas la spec. Alien Signal est en dessous de la spec. Ils sont plus bas niveau encore.
Speaker #0
D'accord.
Speaker #2
Ce qui fait qu'à partir d'Alien Signal, tu peux implémenter la spec. Et c'est d'ailleurs un projet qui a été fait, si on va sur le repo GitHub d'Alien Signals, on va trouver un lien vers un autre repo qui doit s'appeler TC39 Alien Signals, ou quelque chose comme ça, qui est l'implémentation de la spécification du TC39 avec Alien Signals. Et Alien Signals aujourd'hui est tellement bas niveau qu'ils ont réimplémenté, enfin aujourd'hui ils vont aussi nourrir Vue, mais en fait ils ont réimplémenté plein de types de signaux à droite à gauche pour montrer qu'en fait ils sont vraiment très bas niveau et qu'ils sont capables de tout faire à partir de cette implémentation là. Donc ils ont une implémentation qui est très flexible, l'auteur l'a d'ailleurs réécrite plusieurs fois pour la rendre agnostique, et même l'interface d'Alien Signals est une implémentation des trucs internes que tu vas réutiliser pour d'autres implémentations. Et donc toi l'API d'Alien Signals en fait c'est une surcouche d'aliens signal.
Speaker #1
C'est vraiment une recherche sur l'algorithmie en dessous. Tu faisais une métaphore qui est intéressante sur Excel, comment ça fonctionne, où du coup les signaux seraient un peu les cases dans tableur Excel, puis un computit ça serait une formule Excel. Et l'idée c'est, c'est quoi le meilleur algorithme que tu peux faire pour que cette formule se recalcule efficacement, sans bug, si tu changes deux cellules en même temps, qu'est-ce qui se passe derrière, est-ce que ça se recalcule deux fois, etc. C'est ça.
Speaker #2
C'est le plus bas niveau. Et peut-être qu'il y avait une autre ou un autre début à ta question et que j'ai répondu qu'à la moitié de la question.
Speaker #0
Non, non, c'est ça. J'essaye de me projeter. Moi, je fais le noob des signaux. Du coup, là, j'ai une case Excel. Je mets égal A1 plus B1. Bon, là, si je devais le coder en GNS, facile. Mais j'imagine que si A1 et B1 sont eux-mêmes des formules qui dépendent d'autres formules, là, ça devient n'importe quoi.
Speaker #2
En fait, dans tes signaux, tu as deux grandes familles. C'est ceux des dépendances et des subscribers. Et donc, tu vas avoir une dépendance qui est... qui va être dépendance de quelque chose d'autre forcément, et donc qui est dépendance de l'autre partie, qui est dépendance d'un subscriber. Et donc tu vas avoir cette notion où le subscriber va venir s'abonner à ta dépendance, et va réagir en fonction de ce qui se passe. Et après là-dedans tu as plein de modèles de réactivité, et donc si on reprend l'analogie avec Excel, c'est dans ta cellule A1 tu as une valeur, dans ta cellule B1 tu as une autre valeur, et dans ta cellule C1 tu as ta formule, et bien ta cellule B1 et ta cellule B1... 1 et bien donc tu es là où il ya deux valeurs c'était dépendance parce qu'elles sont dépendance de ta cellule c'est un dans lequel tu as ta formule et ta formule elle est abonnée comme comme quand tu t'as tu t'abonnes à une chaîne youtube ou ou la chaîne de mixin honneur de mixin honneur elle est abonnée à ça et elle va être capable d'observer les ce qui se passe dans ces deux autres cellules et de réagir en fonction de ce qui passe et cette notion d'observabilité C'est vraiment la notion d'observabilité qu'on connaît, que ce soit au travers des observables ou au travers de l'observabilité d'une application, c'est vraiment cette idée de je regarde ce qui passe pour réagir.
Speaker #0
Et du coup, les frameworks modernes, là, si on fait un peu le bilan, calmement, on se remémore à chaque instant, les différents frameworks du marché, qui a mis un concept proche des signaux, qu'ils appellent comme ça ou différemment, et qui... va avoir tendance à profiter de la spec bientôt ?
Speaker #2
Je pense que la question se pose plutôt dans l'autre sens. c'est qui n'a pas de signaux aujourd'hui c'est React et si tu prends il y a une très bonne je partage à la fin de mon talk une très bonne vidéo qui est basée sur un article du créateur de Quick qui explique justement qu'il prend tous les frameworks et qu'il les met sur une sur une ligne, non pas temporelle mais une ligne de à quel point les frameworks sont signalisés à quel point ils implémentent les signaux et en fait tu as donc React le plus à gauche qui est celui dans lequel il n'y a absolument pas de signaux d'ailleurs un mode de réactivité qui est extrêmement différent de tous les autres qui est le moins performant mais le plus versatile c'est hyper intéressant mais c'est un Ensuite tu as Angular Vue qui implémente des signaux mais dans lequel c'est en cours. Et en fait, au sein de la réactivité des signaux, après tu as des concepts de à quel point les signaux vont targueter gros ou pas dans ton application. En fait, c'est quel est le scope de re-render de ton application ? Est-ce que tu es au niveau applicatif global comme React ? Est-ce que tu es au niveau composant comme Angular ou Vue ? Ou est-ce que tu es encore plus bas au niveau carrément éléments du DOM, comme justement les prochains, où tu vas avoir Svelte ensuite avec ses fameuses ruins ? et son pré-processeur et puis après tu vas avoir Quick et ensuite Solid qui est vraiment le plus axé signaux et celui qui a énormément poussé la chose et qui l'implémente de manière très profonde donc ça nous fait un grand spectre et donc aujourd'hui tous les frameworks tendent à utiliser les signaux, même Angular depuis aujourd'hui la version 14 vont dans cette direction là
Speaker #0
Et t'arrives à expliquer Même toi Cédric si t'as une idée mais pourquoi React il y en a toujours pas est-ce que c'est parce qu'ils traînent leur modèle qui est difficile à modeler, à faire évoluer vers ça est-ce qu'ils en ont juste pas envie ou les perfs qu'ils ont leur conviennent
Speaker #2
Je pense que c'est surtout pas leur philosophie déjà je pense que techniquement ce serait hyper compliqué de mettre en place des signaux dans React mais ensuite c'est pas leur philosophie, eux ils sont Euh... Aujourd'hui, React se définit plutôt comme une librairie, plus qu'un framework. Même si en vrai, le débat, on s'en fiche un petit peu, mais le débat, il est quand même intéressant sur l'API qui est donnée suite au développeur. Et donc, l'API d'optimisation des performances dans React, en fait, elle est donnée au développeur, et c'est à toi, en tant que développeur dans React, d'optimiser ton application. Ça, c'est très pratique. Parce que ça permet aujourd'hui à d'autres sur-frameworks de React d'exister. Tout ce qui est du React natif, ce genre de choses, ça existe parce que derrière, les implémentations font que ils ont accès à plein d'APIs pour faire ça. Ce qui serait beaucoup plus compliqué dans d'autres frameworks. Mais non, c'est pas leur philosophie, c'est pas leur objectif. Et quand on voit ce qui se passe avec les RSC, donc les React et tout, en fait, on comprend bien que c'est pas ce vers quoi ils tendent. Et puis, ça poserait tellement de problèmes. Et puis, implémenter ça derrière, ce serait une cascade énorme dans tout ce qu'ils sont déjà en train de faire. que c'est pas leur objectif, aujourd'hui React fonctionne très bien, il n'y a pas de gros problème de performance si on fait un petit peu attention.
Speaker #1
Ce que je trouve intéressant aussi c'est que c'est aussi un nouveau paradigme, le fait d'avoir ces formules Excel dans la façon dont on développe et que ça impacte pas mal la façon dont nous, développeurs on va faire nos applications web et ça fait que les frameworks aussi, ils ont leurs API qui évoluent c'est probablement plus notable dans Angular qui est en train de faire cette migration petit à petit Merci. Et où en fait, on avait besoin de mécanique pour pouvoir dire, quand les entrées d'un composant changent, il faut que je fasse quelque chose. Si maintenant, du coup, les entrées d'un composant, c'est un signal, du coup, tu vas faire une formule Excel, un computid, pour dire que si quelque chose change, tu vas devoir recalculer ce truc-là. Et donc, ça simplifie d'une certaine façon aussi le métier des gens qui font des composants, comme vous et moi dans nos applications de gestion de la vie de tous les jours. où on va avoir accès à ces nouveaux paradigmes qui sont des sources de... optimisation pour les frameworks, mais qui sont aussi des sources de nouveaux patterns, de nouvelles pratiques pour nous en tant que développeurs.
Speaker #2
Et ce truc-là, il est hyper intéressant, et c'est peut-être aussi l'une des explications pour lesquelles React ne veut pas migrer, parmi beaucoup de choses, et tout ce qu'on a déjà dit, mais si on prend le cas d'Angular et Vue, je trouve que c'est hyper intéressant, parce qu'ils ont deux approches très différentes, pas sur l'implémentation des signaux, mais sur la manière dont ils l'ont fait. Vue.js est passé de Vue 2 à Vue 3, et ils ont fait, paf, Vue 3, des signaux. Vous ne savez pas ce que c'est les signaux, vous ne savez pas les utiliser, et bien tant pis pour vous, maintenant c'est là, il n'y a plus que ça. Et ça a été un coup dur énorme dans la communauté, ça a un peu coupé la communauté parce qu'il a fallu tout réapprendre. Il a fallu vraiment tout réapprendre, tout refaire, et aujourd'hui on a des librairies qui se sont développées assez vite pour nous aider, mais ça a été très complexe au début et on a vraiment presque réapprené un nouveau framework. Là où chez Angular, l'approche elle est différente, on vous met des signaux, petit à petit, on va arriver avec la version 20, si je ne dis pas de bêtises, d'Angular. Ça évolue depuis la version 14, à chaque fois ils relisent ça en bêta, et puis ensuite en développeur, et puis ensuite c'est finalement utilisable. Et puis depuis la version 14, donc s'il y a 6 mois entre chaque version, ça fait 6 versions, donc ça fait 3 ans qu'ils font évoluer ça, et donc petit à petit ils ouvrent les choses et ils font en sorte que les gens puissent migrer de manière assez naturelle vers cette philosophie-là, et ça montre bien à quel point C'est un nouveau paradigme, mais c'est compliqué à prendre en main et c'est une petite révolution dans la manière dont on crée des applications parce qu'il faut presque tout réapprendre.
Speaker #0
Et ça au final, toi Cédric, tu contribues à Angular et Vue. Ça reflète un peu aussi l'image que j'en ai, j'en ai fait mais j'en fais plus trop, qu'Angular il y a un côté très enterprise et on me vend que tout ne va pas changer du jour au lendemain. parier, comme on dit souvent, tout bête en JavaScript, là-dessus pour toutes mes applis de gestion, mon centre de service, machin. Alors que Vue aura peut-être eu, sans forcément dire on change toutes les trois secondes, une approche un peu plus...
Speaker #1
Comment tu la décrirais ? Je suis d'accord avec ce que tu disais, Stéban, c'est que la version 3 par exemple de Vue, ça a été un peu difficile pour la communauté. T'as encore beaucoup de gens qui sont en train de migrer. GitLab qui est l'une des applis assez connues, massive en vue. ils sont toujours en train de migrer, même si ça fait 5 ans que Vue 3 est sorti.
Speaker #2
Et que la version 2 n'est plus...
Speaker #1
Et que la version 2 n'est plus portée. Donc cette mécanique de sortir un nouveau paradigme a marché dans un certain sens, parce que beaucoup de gens font du Vue 3, mais il y a aussi beaucoup de gens qui sont encore sur du Vue 2. Et ce que tu dis Hubert, c'est vrai sur Angular. Je pense que la grande force d'Angular, et c'est ce qui fait que beaucoup de gens le choisissent, c'est aussi cette stabilité qu'il y a dans le temps. et comme tu disais Stéban, ça sort avec des développeurs preview et t'es pas obligé de l'utiliser et le jour où tu dois l'utiliser, il y a des migrations automatiques qui vont le faire pour toi.
Speaker #0
Avec des codes main donés Ouais,
Speaker #1
ça s'appelle pas comme ça c'est un truc un peu spécifique à Angular, ils appellent des schématiques de migration mais le principe est le même et en fait tu le lances sur ta base de code ça analyse statiquement ce que tu fais et ça réécrit et en fait, il faut savoir que chez Google l'équipe qui fait Angular est chargée de maintenir les repos internes de chez Google et ils ont Merci. entre 4 et 5 mille applications angulaires à maintenir. Donc évidemment quand ils font des migrations au breaking, ils peuvent pas se permettre de faire les changements à la main même si chez Google tu as des mécaniques qui vont permettre d'écrire des migrations mais donc du coup ils ont essayé d'open sourcer une partie de cette mécanique de migration automatique pour que la communauté puisse en profiter et donc dès qu'il y a des changements breaking notamment sur les signaux ils vont lancer les migrations en interne chez Google, migrer leurs 5000 applications et quand ça marche c'est open sourcer et les devs comme vous et moi on le lance sur notre la V20 sort, tu fais un update et ça se met à jour. Et donc, tu as quand même les signaux qui apparaissent petit à petit dans le framework. Ça n'empêche pas que la formule Excel va falloir l'écrire à un moment. Elle ne peut pas magiquement se matérialiser, malheureusement, par des mécaniques de migration. Donc, il y a quand même du code à migrer manuellement. Mais ils essayent de le faire petit à petit. Mais Angular est encore un peu à mi-chemin du process. C'est-à-dire que tu n'as pas toutes les API du framework qui ont été migrées pour gérer les signaux, par exemple.
Speaker #2
Et cette notion de breaking, elle est importante parce qu'en fait, sur Angular, leur objectif, c'est qu'il n'y en ait pas. C'est que vraiment, tu mets à jour de 16 à 17, à 17 à 18. Merci. C'est hyper fluide et il n'y a pas de truc cassant.
Speaker #0
Ce qui est marrant, c'est qu'ils ont la version majeure la plus élevée des gros frameworks du marché. Techniquement, c'est des versions majeures avec des breaking changes, mais en fait, ils sont relativement petits. Ils profitent que leur communauté et la culture. C'est pas parce que...
Speaker #1
on change la majeure qu'il faut tout changer quoi c'est pour ça qu'ils ont fait c'est assez réaliste tous les six mois depuis la 2 pour forcer un peu les rolling up drag comme on fait sur des navigateurs ou maintenant on est en 130 140 on sait même plus et voilà ça se fait tout seul pour
Speaker #0
terminer un peu est ce que je reviendrai bien alors moi je fais j'utilise plus trop les Ouais vas-y Cénac.
Speaker #1
Ouais j'ai juste, quand on est sur les frameworks, le dernier truc c'est que tu parlais un petit peu de Vapor dans ton talk. Tu peux peut-être nous dire quelques mots là-dessus.
Speaker #2
Vapor c'est un projet qui a été lancé par Evan New, créateur de VJS, il y a quelque chose comme deux ans je pense. Enfin vraiment très longtemps. On en a entendu parler tout 2024 et ça a sûrement démarré en 2023, mi-2023. Et où l'objectif c'est de... permettre d'avoir un framework Vue.js, déjà d'avoir un nouveau paradigme dans Vue.js, et que ça s'intègre un peu comme Angular, de manière hyper fluide, et qu'on n'ait rien de cassant. Donc ça s'intègre dans Vue.js, et l'objectif final de ça, c'est d'enlever le Virtual DOM. Sauf qu'enlever le Virtual DOM, qui est hyper important dans nos applications type Vue.js, puisqu'il permet de mapper le code qu'on a écrit. et le DOM derrière et d'avoir un rendu qui est hyper performant puisqu'on fait un diff sur le nouveau Virtual DOM après que les valeurs aient changé et l'ancien. Et à partir de ce diff-là, on est capable de mettre à jour les bons éléments dans le DOM plutôt que de re-rendre l'intégralité du DOM. Le truc, c'est que pour faire ça, ça demande énormément de changements dans le framework. Et l'arrivée des signaux permet de se dire qu'au lieu de faire un rendu au niveau du composant et donc à chaque fois qu'une valeur dans son composant change, on peut très bien se dire, en fait, on va targeter plutôt les éléments du DOM, et dans chaque élément du DOM qui aurait un signal, on va se dire qu'on va regarder cet élément du DOM avec son signal, et on va être capable de le targeter très précisément, parce que justement on utilise des signaux, et donc on est branché directement là où il y a les changements, et donc on n'a plus besoin d'avoir ce virtual DOM là, parce qu'au moment où on va mettre à jour une valeur, on revient dans ce fameux tableau Excel, Et il faut voir notre... notre élément du DOM comme cette formule dans notre Excel, au moment où on va mettre à jour la valeur qui est dans cette formule. on va être capable de ne mettre à jour que cet élément-là du DOM.
Speaker #1
On va avoir plein de petites formules Excel pour chaque binding dans le DOM, au lieu d'une grosse formule Excel pour tout le composant. Composant,
Speaker #2
exactement. Et donc, ça permet plusieurs choses. Déjà, de s'affranchir du virtual DOM, et donc de s'affranchir de tout le code qui gérait le diffing pour le virtual DOM. Donc déjà, ça fait pas mal de codes en moins. Ça fait aussi beaucoup de calculs en moins, parce qu'il n'y a pas besoin de faire le diffing. C'est automatiquement les signaux qui vont être capables de dire, bon, là, il y a un changement, donc je re-rends mon élément du DOM. Et puis ça va permettre aussi d'avoir des applications qui sont beaucoup plus précises sur les changements à faire, beaucoup plus légères, et l'objectif c'est de rendre interopérable à la fois le Vapor, donc avec ce système sans Virtual DOM, et des composants plus classiques dont on a l'habitude d'écrire, puisqu'il y a quand même un petit trade-off avec Vapor, comme il n'y a plus de Virtual DOM. Mais l'objectif c'est de rendre le tout interopérable, et à terme, c'est d'avoir son premier nœud applicatif en tant que en tant que vapore, donc un composant vapore, qui serait le produit composant vapore, et donc on aurait toute une application vapore, et là vraiment on aurait le virtual DOM qui pourrait disparaître. À terme, c'est ça l'objectif.
Speaker #1
Ok, donc pour faire ça un peu plus progressivement. Ouais, c'est assez intéressant de voir que côté application des changements dans le DOM... Vue est en train de converger vers une stratégie Angular ou Svelte par exemple et que côté gestion de l'état c'est les autres frameworks qui se rapprochent de ce que a promu Vue 3 en premier typiquement Angular et Svelte ont maintenant basculé sur des signaux qui sont un peu l'équivalent de ce que Vue a fait avec son API de composition mais du coup il y a quand même un vrai mouvement de convergence et d'où le fait que standardisation des signaux.
Speaker #2
Ce qui est hyper intéressant, c'est que là, ça peut paraître peut-être un peu abstrait pour les gens qui nous écoutent, mais je les invite à aller sur le Playground de vue, parce qu'aujourd'hui, c'est possible de tester Vapor dans son navigateur. C'est possible déjà d'écrire du vue dans son navigateur via le Playground, mais c'est possible de tester Vapor, et via juste l'exemple qui est fourni de base quand on va sur le Playground, on peut switcher, on peut déjà voir le rendu, donc le code qui va être généré à partir du code qu'on a écrit, le code compilé, et ensuite on est capable de passer le rendu en mode Vapor. Et en fait, on se rend compte, de manière extrêmement simple et précise, qu'on a bien... des éléments qui vont venir vraiment de manière très précise targeter les éléments du DOM. On va trouver une fonction qui va targeter l'élément du DOM. Et on voit bien cette nuance-là entre les deux.
Speaker #0
Pour terminer, on a parlé de la standardisation. Est-ce que tu sais dire un peu où ça en est ? Je crois que dans le TC39, il y a des stages. Est-ce que ça arrive dans mon navigateur et des nodes demain ? Est-ce que tu veux faire une prédiction ? Est-ce qu'on sait un peu où ça en est ?
Speaker #2
Oui, on sait exactement où ça en est. Il y a plusieurs stages. Il y en a six. Il y a six stages au TC39 qui vont de 0 à 4. Vous allez me dire, ça ne fait pas 6 parce qu'on en a un intermédiaire. Mais on part de 0 et l'objectif, c'est d'arriver à 4. Et à chaque fois, il y a des discussions qui sont faites et petit à petit, ça monte ou pas. Ce qui est important à savoir sur le TC39, c'est que potentiellement, la proposition meurt et on n'en fait jamais rien. Donc déjà, peut-être que les signaux, on ne les verra jamais nativement dans le navigateur. Mais aujourd'hui, c'est sous le stage 1. Donc c'est une proposition qui est en train d'être considérée. Ils sont en train de l'étudier et ils voient qu'est-ce qu'on peut en faire. Donc aujourd'hui, potentiellement, ça arrive dans 2 ans, 3 ans, 10 ans ou jamais.
Speaker #0
Tu veux tenter une prédiction ?
Speaker #2
Non.
Speaker #0
Je crois que c'est raisonnable. Nous arrivons déjà à la fin de cet échange passionnant. Esteban, avant de te laisser partir, on a une tradition Amixitonaire. C'est partager avec nos auditeurs et auditrices une ressource incontournable. Un site, un auteur, une autrice, un outil, un podcast, ce que tu veux, pour une tech plus éthique. Une ressource, j'imagine, en lien avec tout ce qu'on vient d'évoquer sur le front-end, les signaux. Yes.
Speaker #2
C'est compliqué de trouver une ressource éthique, parce que j'avoue que c'est pas forcément le mot que je mets tout le temps dans ce que je fais. C'est pas un truc que je fais de manière consciente. De faire les choses éthiques, de lire forcément des articles éthiques, c'est un peu compliqué à expliquer. C'est pas hyper conscient dans ce que je fais, mais c'est hyper bien que ce soit mis en avant et que vous soyez là, Mixit, pour le promouvoir. Donc une ressource éthique, un peu difficile pour moi, j'avoue. Une ressource éthique et signal, bon ben là, c'est encore plus dur. Mais je pense qu'aujourd'hui, j'ai deux ressources que je vais mettre en avant. La première, c'est GitHub. Alors dit comme ça, ça paraît un peu bien, mais...
Speaker #0
Je ne connais pas assez quoi.
Speaker #2
Ouais, c'est un petit truc sur lequel on peut pousser du code. Mais c'est parce que moi j'adore lire du code source et c'est comme ça que j'apprends le plus de trucs. Je lis assez peu de livres, donc c'est pareil, vous trouvez une ressource de livre. Non mais c'est la reco. Donc moi mes livres, c'est le code source que je lis dans le métro avant de m'endormir tout le temps. Et une deuxième ressource plus avec une vraie personne derrière, ce serait Anthony Fou. qui est une immense personne dans l'écosystème Vue.js, qui travaille aujourd'hui pour Nox Labs, qui est un partenaire avec VoidZero, une autre entreprise où ils font plein de trucs autour de Vite, qui a contribué à des dizaines et des dizaines de projets, qui a fait je ne sais pas combien de projets aussi, et qui partage régulièrement des trucs intéressants sur son blog, des infos intéressantes sur son blog, mais qui surtout crée beaucoup de choses et a une philosophie de partage qui est énorme, Et en voyant ce qu'il fait, potentiellement, ça permet aussi d'aller lire son code source, d'apprendre beaucoup de choses et surtout là où ça devient très intéressant c'est que évidemment au bout d'un moment quand tu as créé 50-100 projets tu peux pas les maintenir tous et donc il délègue la maintenance à des nouvelles personnes en fonction de leurs contributions et donc ça permet aussi de voir des nouvelles personnes arriver dans l'écosystème d'aller les suivre et c'est justement dans ce processus là qu'on peut suivre des nouvelles personnes comme Johnson qui est créateur d'Alien Signal Et comme ça, se créer son petit empire de liens et de connexions avec des personnes hyper intéressantes. Et creuser après via GitHub ou d'autres plateformes le code source et tout ce qui s'écrive.
Speaker #1
Merci infiniment pour ta participation aujourd'hui. Je rappelle à nos auditeurs et nos auditrices que vous pouvez retrouver la conférence complète d'Esteban en replay sur la chaîne YouTube de Mixit. Et si cet épisode vous a plu, n'hésitez pas à vous abonner et à partager le podcast autour de vous. Et d'ici là, gardez en tête que pour une tech éthique... Il faut garder l'esprit ouvert et critique. A bientôt.

Description

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue sur Mixit On Air, où la tech rime avec l'éthique. Je suis Hubert.
Speaker #1
Et moi je suis Cédric.
Speaker #0
Et à chaque épisode, nous plongeons dans les coulisses de la conférence Mixit pour vous faire découvrir les innovateurs et innovatrices qui façonnent notre avenir numérique. Aujourd'hui, on a le plaisir d'accueillir Esteban Soubiran, développeur web full stack chez MyAspace. Et avec lui, nous allons explorer la réactivité et les signaux dans le monde du JavaScript.
Speaker #2
Saut la terre ! Saut la terre ! Je vais vous prendre une crêpe au sucre.
Speaker #1
Salut Esteban et bienvenue sur Mixitoner, merci d'être avec nous. T'es venu nous parler des signaux et d'une librairie qui s'appelle Alien Signals. Est-ce que tu peux nous dire un peu comment tu t'es retrouvé à t'intéresser à ce sujet ?
Speaker #2
Ouais, déjà bonjour tout le monde, salut les gars. Excellente question, comment on commence à s'intéresser à une librairie comme Alien Signals ? Peut-être que déjà on peut expliquer ce qu'est Alien Signals. C'est une librairie qui implémente des signaux pour faire de la réactivité, notamment côté front-end, qui est très bas niveau, et suffisamment bas niveau pour que derrière l'algorithme puisse être utilisé dans différents langages. Donc ça c'est hyper intéressant, mais nous aujourd'hui c'est plutôt côté front-end qu'on va l'utiliser. discuter j'imagine et comment on commence à s'intéresser à ça je pense que c'est beaucoup de curiosité c'est se poser la question de qu'est-ce qui se passe dans le framework qu'on utilise au quotidien, et essayer de se questionner sur pourquoi, à un moment donné, quand on fait un truc dans notre interface, le code derrière qu'on a écrit réagit de telle manière. Et c'est de là, de fil en aiguille, qu'on commence à lire un peu de code source du framework qu'on utilise, et puis on suit les gens sur différents réseaux, et puis ils retweetent des trucs, ou ils partagent des trucs. Et puis on finit par tomber sur un gars qui a fait une librairie, qui s'appelle Aline Signals, et puis tu lis le code d'Aline Signals, et tu te retrouves à comprendre comment fonctionnent les signaux. Après des semaines,
Speaker #0
et des semaines à avoir lu le code source qui étonnamment tient dans deux fichiers quelques centaines de lignes et toi c'est quoi ton framework un peu utilisé un peu en ce moment qui t'a amené à atteindre ça ouais pendant très longtemps j'ai fait pendant deux ans j'ai fait l'angular de manière professionnelle parce que pas le choix mais
Speaker #2
à côté ça fait depuis 2018 que je fais du avec toute la partie de vue 2 où tu crées ton objet data et où là il y avait une magie exceptionnelle là j'ai jamais creusé le sujet un petit peu sur la notion de proxy mais sans plus basé sur des proxys je crois Vue 2 était pas encore sur les proxys,
Speaker #1
c'est arrivé quand j'y crois puisque les proxys existaient, ça aurait été avec MyScript 2015 donc c'était pas encore mais ça utilisait une technique un peu différente avec DefineProperty mais ça faisait un peu le même principe
Speaker #2
et ensuite derrière Vue 3 avec sa composition API que là j'utilise depuis que c'est sorti donc 2019 je crois un truc comme ça et là c'est dans mon temps libre à côté des trucs pro et là depuis décembre de manière pro c'est du Vue.js que j'utilise
Speaker #0
Alors depuis quelques années on entend beaucoup parler des signaux, peut-être un deux ans, un peu plus, ça dépend de votre assiduité dans votre veille. En quoi c'est différent d'autres approches de réactivité qu'on a connues avant ? On a évoqué ce qui avait été fait dans Vue 2, Vue 3. C'est quoi, pour les personnes qui nous écoutent, les signaux ça apporte quoi ? En quoi c'est différent ?
Speaker #2
Je pense qu'il y a deux choses qui sont importantes dans les signaux. La première c'est déjà d'un point de vue expérience utilisateur. L'un des trucs qui fait les succès des signaux et de manière générale de cette approche réactive, parce que quand on parle de signaux, l'implémentation de Vue.js aujourd'hui et de ce qu'ils appellent la Composition API, avec les refs, les computables, les watchs, c'est aussi des signaux. On peut le comparer à des signaux, c'est des mots différents, mais c'est des signaux. C'est toute l'approche que ça amène sur la facilité d'utilisation. que ça apporte et donc en terme d'expérience développeur c'est vraiment un gros gain là où VJS apporte un truc en plus c'est que sa Composition API est agnostique du langage ce qui n'est pas le cas dans d'autres frameworks par exemple chez Angular c'est pas le cas, il faut absolument que tu aies Angular autour donc ça c'est un autre truc, c'est que derrière tu as de par cette réactivité là qui ont été capables de... ils ont été capables de l'extraire du framework j'ai beaucoup parlé du JS mais parce qu'ils ont été assez pionniers là dedans ils ont poussé pas mal de choses et le fait d'être capable d'extraire cette réactivité ça a permis des nouveaux frameworks comme Alpine qui est entièrement basé donc Alpine qui permet un peu similaire à Unpoly ou à HTMX qui vous permet de mettre un peu de balises dans votre HTML pour faire des trucs réactifs dans votre HTML un seul fichier javascript et donc là Alpine aujourd'hui est entièrement basé sur la composition API de vue. Et donc il y a ces deux points là et après d'un point de vue plus développeur mais développeur de librairie, ce qu'apportent les signaux c'est ce côté hyper performant, beaucoup plus performant que les approches qu'on avait avant et surtout ça ouvre de nouvelles portes. Parce qu'en fait depuis le début sur le framework front-end, c'est toute cette notion de comment on fait une interface qui est réactive. et après le système de réactivité lui a beaucoup évolué ces dernières années mais l'objectif principal ça a toujours été de comment quand je clique sur un bouton il se passe un truc ailleurs sur ma page et toujours l'objectif c'était de faire le truc le plus performant possible et le plus robuste le plus performant possible et il y a eu plusieurs évolutions et là avec les dernières avancées du Javascript et beaucoup de bonnes idées parce que aujourd'hui l'implémentation de Synos c'est surtout des bonnes idées des choses intelligentes et beaucoup de tests qui ont été faits on en arrive à un truc qui est hyper performant, qui est beaucoup plus performant qu'avant et en plus plus agréable pour les développeurs donc c'est win-win pour tout le monde.
Speaker #0
Là tu disais que la partie composition API de vue elle est agnostique à vue. Genre moi je fais des web components un peu bas niveau sans l'intégrer dedans pour y rajouter de la réactivité.
Speaker #2
C'est addviews slash composition et tu l'installes et tu l'utilises. Et tu as tous les trucs de base donc les refs, les watchs, les computed.
Speaker #1
C'est un peu la même mécanique pour le coup, tu disais en Angular c'est pas vraiment agnostique, mais en fait chez Google ils ont deux frameworks principaux, ils en ont un qui est public qui s'appelle Angular et ils en ont un autre interne qui s'appelle Wizz, qui permet de construire YouTube, Google Search, etc. Et en fait les signaux justement ils sont agnostiques, c'est-à-dire ils sont extraits de tout ça, et ils sont partagés en interne chez Google entre les deux frameworks, donc tu as toute une partie en fait... pareil qui serait réutilisable de façon agnostique ils ne le poussent pas vraiment, c'est pas vraiment l'idée et même pareil pour Vue Reactivity je pense qu'il y a assez peu de gens qui l'extraient pour vraiment l'utiliser mais le concept est un peu le même dans les différents frameworks, c'est que ces briques de base elles sont au final pas tant liées aux frameworks que ça ce qui fait qu'il y a justement cette standardisation qui arrive, tu peux peut-être nous en dire quelques mots puisqu'il y a un effort qui est fait un peu là-dessus Oui,
Speaker #2
effectivement il y a un proposal du TC39 donc quel comité J'ai plus le terme exact mais...
Speaker #0
Technical Committee ?
Speaker #2
Oui ça doit être ça. Qui est le comité qui vise à établir les standards du JavaScript. Et donc il y a un TC39 sur la réactivité et sur la mise en place de la création de signaux directement au sein des Runtimes. Donc la création d'une spécification pour les signaux pour que les Runtimes l'implémentent. Donc Runtime côté... enfin dans V8, donc côté serveur, côté client, un peu partout. Pour l'instant, c'est dans un stade de création. Il y a des premières briques de specs, il y a une première implémentation qui a été faite par le TC39 qui est la moins performante de toutes les implémentations du Cineo. Mais parce que ça a été fait dans l'objectif simplement de montrer que la spécification est réalisable, que ce n'est pas un truc juste théorique. Mais aujourd'hui, il y a la possibilité d'utiliser l'implémentation, enfin plutôt la spécification du TC39 à partir d'une librairie comme Aline Signal. puisqu'elle est tellement bas niveau que c'est possible de la recréer, de recréer la spécification du TC39.
Speaker #1
Ce qui est peut-être intéressant de préciser, c'est que l'aspect qu'elle a été portée au TC39 par les équipes qui font les frameworks. C'est-à-dire que c'est principalement les équipes de Solide, Ryan Carnato, qui est quelqu'un qui a beaucoup popularisé le concept de signal ces derniers temps. Il faut dire que les signaux, ça remonte assez loin dans l'historique du JavaScript. Le concept existait déjà dans des librairies comme Knockout, qui existait il y a très longtemps, qui s'était un peu fait éclater par la popularité de React, qui est arrivé avec un système différent, et le JS DOM, etc. Et il y a des librairies comme Solid, qui ont été faites par Ryan, qui disaient, non, mais les signaux, c'est une bonne idée, et puis on ne serait pas obligé de faire du JS DOM pour le rendu derrière. Du virtual DOM. Du virtual DOM, oui, pardon. Oui, pardon, excuse-moi. J'ai dit n'importe quoi. Virtual DOM. Et qu'on pourrait faire un truc beaucoup plus fin pour la mise à jour du DOM derrière. Et il a réussi à faire beaucoup de vulgarisation là-dessus et à convaincre des gens des frameworks. Donc Evan, par exemple, de Vue.js, qui a finalement adopté ça en Vue 3 comme concept. Rich Harris,
Speaker #0
l'auteur de Svelte. Il a brandé ça un peu différemment pour Svelte, je crois, avec des ruins. C'est globalement des constructions. C'est vraiment le même. c'est la même idée sauf que lui il pousse en plus son pré-processeur beaucoup plus fort il y a quelques problèmes c'est pas le sujet d'aujourd'hui mais ce sera un sujet hyper intéressant avant qu'on creuse Alien Signal avec lequel t'as pas mal joué du coup si moi je vais voir un peu l'aspect du TC39 enfin le brouillon je vais voir quoi, c'est des nouveaux types c'est des nouvelles api ça va on va pouvoir en faire des poli fils et c'est leur chemin new signal ou un peu comme les promesses finalement on peut les poli filet à toute l'époque où il n'était pas encore sous supporté
Speaker #2
dit nativement quoi ouais du coup il ya effectivement ils ont qu'ils ont tout implémenté Et c'est effectivement rigolo que tu soulignes que ce soit le similar au promess parce que même eux quand ils l'expliquent et quand ils le descrivent, ils parlent aussi des promess parce qu'ils sont dans cette même idée là. Et donc tu as tout un polyfile, justement c'est l'implémentation qui sont faites, donc elle est accessible via un polyfile que tu peux utiliser. Et donc aujourd'hui ce serait des nouveaux types qui seraient disponibles dans ton navigateur ou dans n'importe quel runtime et tu aurais un nouvel objet signal. qui auraient différentes propriétés, et notamment une propriété de state, donc l'équivalent du signal, d'un lien de signal, d'une ref, d'en vue, et tout ça, une computed, là pareil on ne change pas les noms, et la possibilité de faire des effects et tout ça. Et donc c'est implémenté, et ce serait effectivement un nouvel objet, un nouveau namespace dans le runtime.
Speaker #0
Alors toi du coup, tu en as fait un sujet que tu as présenté à Mixit 2025, tu t'es intéressé à lien de signal, donc si j'ai bien compris c'est... Au départ, on créait un système de signal, ça a inspiré la spec, et maintenant c'est une impléme de la spec ? C'est un peu ça ou pas du tout ?
Speaker #2
Alien Signal ?
Speaker #0
Ouais.
Speaker #2
Alien Signal n'implémente pas la spec. Alien Signal est en dessous de la spec. Ils sont plus bas niveau encore.
Speaker #0
D'accord.
Speaker #2
Ce qui fait qu'à partir d'Alien Signal, tu peux implémenter la spec. Et c'est d'ailleurs un projet qui a été fait, si on va sur le repo GitHub d'Alien Signals, on va trouver un lien vers un autre repo qui doit s'appeler TC39 Alien Signals, ou quelque chose comme ça, qui est l'implémentation de la spécification du TC39 avec Alien Signals. Et Alien Signals aujourd'hui est tellement bas niveau qu'ils ont réimplémenté, enfin aujourd'hui ils vont aussi nourrir Vue, mais en fait ils ont réimplémenté plein de types de signaux à droite à gauche pour montrer qu'en fait ils sont vraiment très bas niveau et qu'ils sont capables de tout faire à partir de cette implémentation là. Donc ils ont une implémentation qui est très flexible, l'auteur l'a d'ailleurs réécrite plusieurs fois pour la rendre agnostique, et même l'interface d'Alien Signals est une implémentation des trucs internes que tu vas réutiliser pour d'autres implémentations. Et donc toi l'API d'Alien Signals en fait c'est une surcouche d'aliens signal.
Speaker #1
C'est vraiment une recherche sur l'algorithmie en dessous. Tu faisais une métaphore qui est intéressante sur Excel, comment ça fonctionne, où du coup les signaux seraient un peu les cases dans tableur Excel, puis un computit ça serait une formule Excel. Et l'idée c'est, c'est quoi le meilleur algorithme que tu peux faire pour que cette formule se recalcule efficacement, sans bug, si tu changes deux cellules en même temps, qu'est-ce qui se passe derrière, est-ce que ça se recalcule deux fois, etc. C'est ça.
Speaker #2
C'est le plus bas niveau. Et peut-être qu'il y avait une autre ou un autre début à ta question et que j'ai répondu qu'à la moitié de la question.
Speaker #0
Non, non, c'est ça. J'essaye de me projeter. Moi, je fais le noob des signaux. Du coup, là, j'ai une case Excel. Je mets égal A1 plus B1. Bon, là, si je devais le coder en GNS, facile. Mais j'imagine que si A1 et B1 sont eux-mêmes des formules qui dépendent d'autres formules, là, ça devient n'importe quoi.
Speaker #2
En fait, dans tes signaux, tu as deux grandes familles. C'est ceux des dépendances et des subscribers. Et donc, tu vas avoir une dépendance qui est... qui va être dépendance de quelque chose d'autre forcément, et donc qui est dépendance de l'autre partie, qui est dépendance d'un subscriber. Et donc tu vas avoir cette notion où le subscriber va venir s'abonner à ta dépendance, et va réagir en fonction de ce qui se passe. Et après là-dedans tu as plein de modèles de réactivité, et donc si on reprend l'analogie avec Excel, c'est dans ta cellule A1 tu as une valeur, dans ta cellule B1 tu as une autre valeur, et dans ta cellule C1 tu as ta formule, et bien ta cellule B1 et ta cellule B1... 1 et bien donc tu es là où il ya deux valeurs c'était dépendance parce qu'elles sont dépendance de ta cellule c'est un dans lequel tu as ta formule et ta formule elle est abonnée comme comme quand tu t'as tu t'abonnes à une chaîne youtube ou ou la chaîne de mixin honneur de mixin honneur elle est abonnée à ça et elle va être capable d'observer les ce qui se passe dans ces deux autres cellules et de réagir en fonction de ce qui passe et cette notion d'observabilité C'est vraiment la notion d'observabilité qu'on connaît, que ce soit au travers des observables ou au travers de l'observabilité d'une application, c'est vraiment cette idée de je regarde ce qui passe pour réagir.
Speaker #0
Et du coup, les frameworks modernes, là, si on fait un peu le bilan, calmement, on se remémore à chaque instant, les différents frameworks du marché, qui a mis un concept proche des signaux, qu'ils appellent comme ça ou différemment, et qui... va avoir tendance à profiter de la spec bientôt ?
Speaker #2
Je pense que la question se pose plutôt dans l'autre sens. c'est qui n'a pas de signaux aujourd'hui c'est React et si tu prends il y a une très bonne je partage à la fin de mon talk une très bonne vidéo qui est basée sur un article du créateur de Quick qui explique justement qu'il prend tous les frameworks et qu'il les met sur une sur une ligne, non pas temporelle mais une ligne de à quel point les frameworks sont signalisés à quel point ils implémentent les signaux et en fait tu as donc React le plus à gauche qui est celui dans lequel il n'y a absolument pas de signaux d'ailleurs un mode de réactivité qui est extrêmement différent de tous les autres qui est le moins performant mais le plus versatile c'est hyper intéressant mais c'est un Ensuite tu as Angular Vue qui implémente des signaux mais dans lequel c'est en cours. Et en fait, au sein de la réactivité des signaux, après tu as des concepts de à quel point les signaux vont targueter gros ou pas dans ton application. En fait, c'est quel est le scope de re-render de ton application ? Est-ce que tu es au niveau applicatif global comme React ? Est-ce que tu es au niveau composant comme Angular ou Vue ? Ou est-ce que tu es encore plus bas au niveau carrément éléments du DOM, comme justement les prochains, où tu vas avoir Svelte ensuite avec ses fameuses ruins ? et son pré-processeur et puis après tu vas avoir Quick et ensuite Solid qui est vraiment le plus axé signaux et celui qui a énormément poussé la chose et qui l'implémente de manière très profonde donc ça nous fait un grand spectre et donc aujourd'hui tous les frameworks tendent à utiliser les signaux, même Angular depuis aujourd'hui la version 14 vont dans cette direction là
Speaker #0
Et t'arrives à expliquer Même toi Cédric si t'as une idée mais pourquoi React il y en a toujours pas est-ce que c'est parce qu'ils traînent leur modèle qui est difficile à modeler, à faire évoluer vers ça est-ce qu'ils en ont juste pas envie ou les perfs qu'ils ont leur conviennent
Speaker #2
Je pense que c'est surtout pas leur philosophie déjà je pense que techniquement ce serait hyper compliqué de mettre en place des signaux dans React mais ensuite c'est pas leur philosophie, eux ils sont Euh... Aujourd'hui, React se définit plutôt comme une librairie, plus qu'un framework. Même si en vrai, le débat, on s'en fiche un petit peu, mais le débat, il est quand même intéressant sur l'API qui est donnée suite au développeur. Et donc, l'API d'optimisation des performances dans React, en fait, elle est donnée au développeur, et c'est à toi, en tant que développeur dans React, d'optimiser ton application. Ça, c'est très pratique. Parce que ça permet aujourd'hui à d'autres sur-frameworks de React d'exister. Tout ce qui est du React natif, ce genre de choses, ça existe parce que derrière, les implémentations font que ils ont accès à plein d'APIs pour faire ça. Ce qui serait beaucoup plus compliqué dans d'autres frameworks. Mais non, c'est pas leur philosophie, c'est pas leur objectif. Et quand on voit ce qui se passe avec les RSC, donc les React et tout, en fait, on comprend bien que c'est pas ce vers quoi ils tendent. Et puis, ça poserait tellement de problèmes. Et puis, implémenter ça derrière, ce serait une cascade énorme dans tout ce qu'ils sont déjà en train de faire. que c'est pas leur objectif, aujourd'hui React fonctionne très bien, il n'y a pas de gros problème de performance si on fait un petit peu attention.
Speaker #1
Ce que je trouve intéressant aussi c'est que c'est aussi un nouveau paradigme, le fait d'avoir ces formules Excel dans la façon dont on développe et que ça impacte pas mal la façon dont nous, développeurs on va faire nos applications web et ça fait que les frameworks aussi, ils ont leurs API qui évoluent c'est probablement plus notable dans Angular qui est en train de faire cette migration petit à petit Merci. Et où en fait, on avait besoin de mécanique pour pouvoir dire, quand les entrées d'un composant changent, il faut que je fasse quelque chose. Si maintenant, du coup, les entrées d'un composant, c'est un signal, du coup, tu vas faire une formule Excel, un computid, pour dire que si quelque chose change, tu vas devoir recalculer ce truc-là. Et donc, ça simplifie d'une certaine façon aussi le métier des gens qui font des composants, comme vous et moi dans nos applications de gestion de la vie de tous les jours. où on va avoir accès à ces nouveaux paradigmes qui sont des sources de... optimisation pour les frameworks, mais qui sont aussi des sources de nouveaux patterns, de nouvelles pratiques pour nous en tant que développeurs.
Speaker #2
Et ce truc-là, il est hyper intéressant, et c'est peut-être aussi l'une des explications pour lesquelles React ne veut pas migrer, parmi beaucoup de choses, et tout ce qu'on a déjà dit, mais si on prend le cas d'Angular et Vue, je trouve que c'est hyper intéressant, parce qu'ils ont deux approches très différentes, pas sur l'implémentation des signaux, mais sur la manière dont ils l'ont fait. Vue.js est passé de Vue 2 à Vue 3, et ils ont fait, paf, Vue 3, des signaux. Vous ne savez pas ce que c'est les signaux, vous ne savez pas les utiliser, et bien tant pis pour vous, maintenant c'est là, il n'y a plus que ça. Et ça a été un coup dur énorme dans la communauté, ça a un peu coupé la communauté parce qu'il a fallu tout réapprendre. Il a fallu vraiment tout réapprendre, tout refaire, et aujourd'hui on a des librairies qui se sont développées assez vite pour nous aider, mais ça a été très complexe au début et on a vraiment presque réapprené un nouveau framework. Là où chez Angular, l'approche elle est différente, on vous met des signaux, petit à petit, on va arriver avec la version 20, si je ne dis pas de bêtises, d'Angular. Ça évolue depuis la version 14, à chaque fois ils relisent ça en bêta, et puis ensuite en développeur, et puis ensuite c'est finalement utilisable. Et puis depuis la version 14, donc s'il y a 6 mois entre chaque version, ça fait 6 versions, donc ça fait 3 ans qu'ils font évoluer ça, et donc petit à petit ils ouvrent les choses et ils font en sorte que les gens puissent migrer de manière assez naturelle vers cette philosophie-là, et ça montre bien à quel point C'est un nouveau paradigme, mais c'est compliqué à prendre en main et c'est une petite révolution dans la manière dont on crée des applications parce qu'il faut presque tout réapprendre.
Speaker #0
Et ça au final, toi Cédric, tu contribues à Angular et Vue. Ça reflète un peu aussi l'image que j'en ai, j'en ai fait mais j'en fais plus trop, qu'Angular il y a un côté très enterprise et on me vend que tout ne va pas changer du jour au lendemain. parier, comme on dit souvent, tout bête en JavaScript, là-dessus pour toutes mes applis de gestion, mon centre de service, machin. Alors que Vue aura peut-être eu, sans forcément dire on change toutes les trois secondes, une approche un peu plus...
Speaker #1
Comment tu la décrirais ? Je suis d'accord avec ce que tu disais, Stéban, c'est que la version 3 par exemple de Vue, ça a été un peu difficile pour la communauté. T'as encore beaucoup de gens qui sont en train de migrer. GitLab qui est l'une des applis assez connues, massive en vue. ils sont toujours en train de migrer, même si ça fait 5 ans que Vue 3 est sorti.
Speaker #2
Et que la version 2 n'est plus...
Speaker #1
Et que la version 2 n'est plus portée. Donc cette mécanique de sortir un nouveau paradigme a marché dans un certain sens, parce que beaucoup de gens font du Vue 3, mais il y a aussi beaucoup de gens qui sont encore sur du Vue 2. Et ce que tu dis Hubert, c'est vrai sur Angular. Je pense que la grande force d'Angular, et c'est ce qui fait que beaucoup de gens le choisissent, c'est aussi cette stabilité qu'il y a dans le temps. et comme tu disais Stéban, ça sort avec des développeurs preview et t'es pas obligé de l'utiliser et le jour où tu dois l'utiliser, il y a des migrations automatiques qui vont le faire pour toi.
Speaker #0
Avec des codes main donés Ouais,
Speaker #1
ça s'appelle pas comme ça c'est un truc un peu spécifique à Angular, ils appellent des schématiques de migration mais le principe est le même et en fait tu le lances sur ta base de code ça analyse statiquement ce que tu fais et ça réécrit et en fait, il faut savoir que chez Google l'équipe qui fait Angular est chargée de maintenir les repos internes de chez Google et ils ont Merci. entre 4 et 5 mille applications angulaires à maintenir. Donc évidemment quand ils font des migrations au breaking, ils peuvent pas se permettre de faire les changements à la main même si chez Google tu as des mécaniques qui vont permettre d'écrire des migrations mais donc du coup ils ont essayé d'open sourcer une partie de cette mécanique de migration automatique pour que la communauté puisse en profiter et donc dès qu'il y a des changements breaking notamment sur les signaux ils vont lancer les migrations en interne chez Google, migrer leurs 5000 applications et quand ça marche c'est open sourcer et les devs comme vous et moi on le lance sur notre la V20 sort, tu fais un update et ça se met à jour. Et donc, tu as quand même les signaux qui apparaissent petit à petit dans le framework. Ça n'empêche pas que la formule Excel va falloir l'écrire à un moment. Elle ne peut pas magiquement se matérialiser, malheureusement, par des mécaniques de migration. Donc, il y a quand même du code à migrer manuellement. Mais ils essayent de le faire petit à petit. Mais Angular est encore un peu à mi-chemin du process. C'est-à-dire que tu n'as pas toutes les API du framework qui ont été migrées pour gérer les signaux, par exemple.
Speaker #2
Et cette notion de breaking, elle est importante parce qu'en fait, sur Angular, leur objectif, c'est qu'il n'y en ait pas. C'est que vraiment, tu mets à jour de 16 à 17, à 17 à 18. Merci. C'est hyper fluide et il n'y a pas de truc cassant.
Speaker #0
Ce qui est marrant, c'est qu'ils ont la version majeure la plus élevée des gros frameworks du marché. Techniquement, c'est des versions majeures avec des breaking changes, mais en fait, ils sont relativement petits. Ils profitent que leur communauté et la culture. C'est pas parce que...
Speaker #1
on change la majeure qu'il faut tout changer quoi c'est pour ça qu'ils ont fait c'est assez réaliste tous les six mois depuis la 2 pour forcer un peu les rolling up drag comme on fait sur des navigateurs ou maintenant on est en 130 140 on sait même plus et voilà ça se fait tout seul pour
Speaker #0
terminer un peu est ce que je reviendrai bien alors moi je fais j'utilise plus trop les Ouais vas-y Cénac.
Speaker #1
Ouais j'ai juste, quand on est sur les frameworks, le dernier truc c'est que tu parlais un petit peu de Vapor dans ton talk. Tu peux peut-être nous dire quelques mots là-dessus.
Speaker #2
Vapor c'est un projet qui a été lancé par Evan New, créateur de VJS, il y a quelque chose comme deux ans je pense. Enfin vraiment très longtemps. On en a entendu parler tout 2024 et ça a sûrement démarré en 2023, mi-2023. Et où l'objectif c'est de... permettre d'avoir un framework Vue.js, déjà d'avoir un nouveau paradigme dans Vue.js, et que ça s'intègre un peu comme Angular, de manière hyper fluide, et qu'on n'ait rien de cassant. Donc ça s'intègre dans Vue.js, et l'objectif final de ça, c'est d'enlever le Virtual DOM. Sauf qu'enlever le Virtual DOM, qui est hyper important dans nos applications type Vue.js, puisqu'il permet de mapper le code qu'on a écrit. et le DOM derrière et d'avoir un rendu qui est hyper performant puisqu'on fait un diff sur le nouveau Virtual DOM après que les valeurs aient changé et l'ancien. Et à partir de ce diff-là, on est capable de mettre à jour les bons éléments dans le DOM plutôt que de re-rendre l'intégralité du DOM. Le truc, c'est que pour faire ça, ça demande énormément de changements dans le framework. Et l'arrivée des signaux permet de se dire qu'au lieu de faire un rendu au niveau du composant et donc à chaque fois qu'une valeur dans son composant change, on peut très bien se dire, en fait, on va targeter plutôt les éléments du DOM, et dans chaque élément du DOM qui aurait un signal, on va se dire qu'on va regarder cet élément du DOM avec son signal, et on va être capable de le targeter très précisément, parce que justement on utilise des signaux, et donc on est branché directement là où il y a les changements, et donc on n'a plus besoin d'avoir ce virtual DOM là, parce qu'au moment où on va mettre à jour une valeur, on revient dans ce fameux tableau Excel, Et il faut voir notre... notre élément du DOM comme cette formule dans notre Excel, au moment où on va mettre à jour la valeur qui est dans cette formule. on va être capable de ne mettre à jour que cet élément-là du DOM.
Speaker #1
On va avoir plein de petites formules Excel pour chaque binding dans le DOM, au lieu d'une grosse formule Excel pour tout le composant. Composant,
Speaker #2
exactement. Et donc, ça permet plusieurs choses. Déjà, de s'affranchir du virtual DOM, et donc de s'affranchir de tout le code qui gérait le diffing pour le virtual DOM. Donc déjà, ça fait pas mal de codes en moins. Ça fait aussi beaucoup de calculs en moins, parce qu'il n'y a pas besoin de faire le diffing. C'est automatiquement les signaux qui vont être capables de dire, bon, là, il y a un changement, donc je re-rends mon élément du DOM. Et puis ça va permettre aussi d'avoir des applications qui sont beaucoup plus précises sur les changements à faire, beaucoup plus légères, et l'objectif c'est de rendre interopérable à la fois le Vapor, donc avec ce système sans Virtual DOM, et des composants plus classiques dont on a l'habitude d'écrire, puisqu'il y a quand même un petit trade-off avec Vapor, comme il n'y a plus de Virtual DOM. Mais l'objectif c'est de rendre le tout interopérable, et à terme, c'est d'avoir son premier nœud applicatif en tant que en tant que vapore, donc un composant vapore, qui serait le produit composant vapore, et donc on aurait toute une application vapore, et là vraiment on aurait le virtual DOM qui pourrait disparaître. À terme, c'est ça l'objectif.
Speaker #1
Ok, donc pour faire ça un peu plus progressivement. Ouais, c'est assez intéressant de voir que côté application des changements dans le DOM... Vue est en train de converger vers une stratégie Angular ou Svelte par exemple et que côté gestion de l'état c'est les autres frameworks qui se rapprochent de ce que a promu Vue 3 en premier typiquement Angular et Svelte ont maintenant basculé sur des signaux qui sont un peu l'équivalent de ce que Vue a fait avec son API de composition mais du coup il y a quand même un vrai mouvement de convergence et d'où le fait que standardisation des signaux.
Speaker #2
Ce qui est hyper intéressant, c'est que là, ça peut paraître peut-être un peu abstrait pour les gens qui nous écoutent, mais je les invite à aller sur le Playground de vue, parce qu'aujourd'hui, c'est possible de tester Vapor dans son navigateur. C'est possible déjà d'écrire du vue dans son navigateur via le Playground, mais c'est possible de tester Vapor, et via juste l'exemple qui est fourni de base quand on va sur le Playground, on peut switcher, on peut déjà voir le rendu, donc le code qui va être généré à partir du code qu'on a écrit, le code compilé, et ensuite on est capable de passer le rendu en mode Vapor. Et en fait, on se rend compte, de manière extrêmement simple et précise, qu'on a bien... des éléments qui vont venir vraiment de manière très précise targeter les éléments du DOM. On va trouver une fonction qui va targeter l'élément du DOM. Et on voit bien cette nuance-là entre les deux.
Speaker #0
Pour terminer, on a parlé de la standardisation. Est-ce que tu sais dire un peu où ça en est ? Je crois que dans le TC39, il y a des stages. Est-ce que ça arrive dans mon navigateur et des nodes demain ? Est-ce que tu veux faire une prédiction ? Est-ce qu'on sait un peu où ça en est ?
Speaker #2
Oui, on sait exactement où ça en est. Il y a plusieurs stages. Il y en a six. Il y a six stages au TC39 qui vont de 0 à 4. Vous allez me dire, ça ne fait pas 6 parce qu'on en a un intermédiaire. Mais on part de 0 et l'objectif, c'est d'arriver à 4. Et à chaque fois, il y a des discussions qui sont faites et petit à petit, ça monte ou pas. Ce qui est important à savoir sur le TC39, c'est que potentiellement, la proposition meurt et on n'en fait jamais rien. Donc déjà, peut-être que les signaux, on ne les verra jamais nativement dans le navigateur. Mais aujourd'hui, c'est sous le stage 1. Donc c'est une proposition qui est en train d'être considérée. Ils sont en train de l'étudier et ils voient qu'est-ce qu'on peut en faire. Donc aujourd'hui, potentiellement, ça arrive dans 2 ans, 3 ans, 10 ans ou jamais.
Speaker #0
Tu veux tenter une prédiction ?
Speaker #2
Non.
Speaker #0
Je crois que c'est raisonnable. Nous arrivons déjà à la fin de cet échange passionnant. Esteban, avant de te laisser partir, on a une tradition Amixitonaire. C'est partager avec nos auditeurs et auditrices une ressource incontournable. Un site, un auteur, une autrice, un outil, un podcast, ce que tu veux, pour une tech plus éthique. Une ressource, j'imagine, en lien avec tout ce qu'on vient d'évoquer sur le front-end, les signaux. Yes.
Speaker #2
C'est compliqué de trouver une ressource éthique, parce que j'avoue que c'est pas forcément le mot que je mets tout le temps dans ce que je fais. C'est pas un truc que je fais de manière consciente. De faire les choses éthiques, de lire forcément des articles éthiques, c'est un peu compliqué à expliquer. C'est pas hyper conscient dans ce que je fais, mais c'est hyper bien que ce soit mis en avant et que vous soyez là, Mixit, pour le promouvoir. Donc une ressource éthique, un peu difficile pour moi, j'avoue. Une ressource éthique et signal, bon ben là, c'est encore plus dur. Mais je pense qu'aujourd'hui, j'ai deux ressources que je vais mettre en avant. La première, c'est GitHub. Alors dit comme ça, ça paraît un peu bien, mais...
Speaker #0
Je ne connais pas assez quoi.
Speaker #2
Ouais, c'est un petit truc sur lequel on peut pousser du code. Mais c'est parce que moi j'adore lire du code source et c'est comme ça que j'apprends le plus de trucs. Je lis assez peu de livres, donc c'est pareil, vous trouvez une ressource de livre. Non mais c'est la reco. Donc moi mes livres, c'est le code source que je lis dans le métro avant de m'endormir tout le temps. Et une deuxième ressource plus avec une vraie personne derrière, ce serait Anthony Fou. qui est une immense personne dans l'écosystème Vue.js, qui travaille aujourd'hui pour Nox Labs, qui est un partenaire avec VoidZero, une autre entreprise où ils font plein de trucs autour de Vite, qui a contribué à des dizaines et des dizaines de projets, qui a fait je ne sais pas combien de projets aussi, et qui partage régulièrement des trucs intéressants sur son blog, des infos intéressantes sur son blog, mais qui surtout crée beaucoup de choses et a une philosophie de partage qui est énorme, Et en voyant ce qu'il fait, potentiellement, ça permet aussi d'aller lire son code source, d'apprendre beaucoup de choses et surtout là où ça devient très intéressant c'est que évidemment au bout d'un moment quand tu as créé 50-100 projets tu peux pas les maintenir tous et donc il délègue la maintenance à des nouvelles personnes en fonction de leurs contributions et donc ça permet aussi de voir des nouvelles personnes arriver dans l'écosystème d'aller les suivre et c'est justement dans ce processus là qu'on peut suivre des nouvelles personnes comme Johnson qui est créateur d'Alien Signal Et comme ça, se créer son petit empire de liens et de connexions avec des personnes hyper intéressantes. Et creuser après via GitHub ou d'autres plateformes le code source et tout ce qui s'écrive.
Speaker #1
Merci infiniment pour ta participation aujourd'hui. Je rappelle à nos auditeurs et nos auditrices que vous pouvez retrouver la conférence complète d'Esteban en replay sur la chaîne YouTube de Mixit. Et si cet épisode vous a plu, n'hésitez pas à vous abonner et à partager le podcast autour de vous. Et d'ici là, gardez en tête que pour une tech éthique... Il faut garder l'esprit ouvert et critique. A bientôt.

Embed