Les développeurs ne caresent pas de performance.
Si c'est une performance libre, je vais le prendre.
Ou une performance très chère.
Mais quand c'est très difficile, je ne veux pas se changer.
Je veux explorer des tools vraiment développeurs,
comme Millie, qui automatiquement optimisent
des choses qui permettent de faire une performance libre.
Hey, avant que nous commençons cette semaine,
nous allons annoncer qu'on a commencé une newsletter.
Nous allons passer à mail.devtools.fm.
Justin va faire la newsletter et curer un set d'interessants
de links sur les news de DevTools qui ont passé au bout de la semaine.
L'une de nos news va également obtenir une breakdown
de l'épisode que nous avons réellue cette semaine
avec des pensées de notre post-show.
Si vous êtes intéressés, nous aimerons vous joindre.
Bonjour, bienvenue à la podcast de DevTools.
C'est un podcast sur les tools développeurs
et les gens qui font les choses.
Je suis Andrew et je suis ma co-host Justin.
Salut tout le monde, nous sommes vraiment excitées
de voir Aiden avec nous aujourd'hui.
Aiden a créé une libraire qui s'appelle MillionJS,
qui fait que nous réactons rapidement.
Nous sommes vraiment excitées de parler de ça aujourd'hui.
Mais avant de l'enlever, Aiden,
Would you like to tell our listeners
a little bit more about yourself?
Hey, thanks for having me on.
As Justin Andrew introduced,
I work at MillionJS,
which is a virtual dorm replacement for React
that makes it much faster.
I'm currently 18, I live in Portland, Oregon,
but I'm heading up to University of Washington
in like a week.
So excited for that.
Yeah, I think you win the award
for the youngest person ever on DevTools FM.
So congratulations for that.
What made you like get into React and web development
and led you towards MillionJS?
I started coding in fifth grade,
not because I wanted to start coding,
it was because I like playing cool math games
on my school computer.
And you know, I was hard riding Papa's Beats-O-Ria,
and so I was like obsessed with that game.
But when my school district
blocked my games, flash games on their computers,
I was devastated.
I was like, there's some way to bypass this, right?
Turns out there is.
The thing about the blocky system
was it only looked at the URL on your website.
And so I could have an iframe embedded on my own website
and then it would literally,
I would be able to play cool math games on there.
So from there, I just kind of dove into web development.
I mean, I learned HTML.
I know people say that's not a programming language,
but it is a programming language.
You kind of dove it from there.
I'm curious.
So I remember when I started trying to learn programming,
I didn't start with web development.
I tried to learn C and C++ search, which was a mistake.
For me, anyway, I didn't have a lot of great resources,
but how was the learning path for you?
Did you find it that you had like plenty of resources
and getting started?
There was like enough material,
or was it still kind of sparse
and sort of hard to get started with?
Definitley better than maybe 20 years ago,
but I feel like I have a very weird learning path
or nontraditional.
I think what most developers do
is they either go through a boot camp
or they go through school,
or they learn, or at least in boot camps,
you learn React, you learn tools,
or in school you learn the fundamentals first,
or people are just interested in getting an O'Reilly,
C++ book, and they learn like Game Dev or something.
But I kind of learned everything backwards.
When I was talking to other programmers,
they were using Git,
and I didn't even know how to commit and Git,
but I knew how to make a website
or library using JavaScript.
So that was a definitely weird experience for me.
I felt like I was learning everything backwards.
Yeah, I find it really cool
that your first delve into programming
was hacking around your school's firewall with iFrames.
Excellent use of iFrames.
I don't know about other uses of iFrames,
so that's definitely a good one.
So what led you to React?
Did you try out other frameworks?
How'd you end up there?
I was big on not using frameworks
because I thought they were too complicated.
So I got into Vue by building my own Vue.
So I built Vue,
and then I learned how to use Vue correctly.
So I just kind of played around there.
And then one day I found about this thing
called the virtual DOM,
and I was like super hooked on it.
So from there I literally rebuilt React,
kind of learned React,
and from there just now I do React it.
I found it interesting because it was really hard
to wrap my head around the complexities of React,
and the only way for me to really understand it
was to kind of rebuild it myself.
I find that true with a lot of coding things.
You really have to get down and into the code
to really understand.
So you said you were excited by the virtual DOM.
I don't think many people
probably think that to themselves often.
How did you get to that excitement?
Were you finding performance pitfalls
in your home bake framework,
or did you just like the idea of what it entails?
Both, yeah, for sure.
I was using inter-html calls,
and if you know anything about that,
doing big html changes is a terrible idea.
So that's where I was looking at virtual DOM,
and that was a thing where I could actually,
I mean, number one,
I could take huge swaths of html
and diff it against something and have it perform okay.
But also, it was just a really interesting concept
learning about how to traverse a tree,
how to build a tree,
how to do efficient diffing,
and things of the sort.
Yeah, it is a pretty fun concept.
I remember, I think I came to React,
mostly from jQuery,
so it was like a similar sort of thing,
but different, right?
You're editing a bunch of DOM nodes,
and then you're like, okay,
how do we do this faster?
This kind of gets us into thinking about millions,
so you'd sort of rebuild your own version of React
to sort of learn the internals
and started using React,
and we're excited about the virtual DOM.
What started making you think,
hmm, this isn't exactly very performant,
or there could be more optimizations
to how this happens?
Yeah, I've always been pretty frustrated
about how websites are built today.
I grew up without a computer,
and then the first computer I got was insanely,
like it couldn't load Wikipedia in a good time.
And so I've always been on the side of computing,
where it's like everything is really slow,
everything doesn't, it's not state of the art.
My grandma even knows the 2015 iPad.
Whenever I send her a TikTok, it doesn't load.
And so I've always been frustrated
with the way we build websites now.
I mean, most developers have an M1 MacBook,
et c'est génial pour eux,
mais évidemment, pour des utilisateurs comme moi,
et beaucoup d'usagers de l'univers,
c'est un peu de problème.
Et donc, je me suis dit,
qu'est-ce que si nous avons construit un meilleur virtual DOM?
Qu'est-ce que nous pouvions faire avec React,
mais aussi faire ça beaucoup plus vite?
Et la façon dont je l'ai approché,
j'ai déjà vu beaucoup de frameworks
qui ont essayé de replacer React,
et qui ont aussi état de performance.
C'est comme un fil, tout le monde sait ce fil.
C'est comme, plus vite,
plus vite, et aussi plus facile à utiliser.
Mais je pense que le fait que...
Je n'ai pas...
J'ai aimé comment Svelte
a introduit un nouveau concept,
mais je ne pense pas que ça puisse faire
un changement de manière meaningful
sans essayer de faire que le réacte de réaction
soit adopté quelque chose de plus vite.
Et donc, mon approche avec Million
était, OK, qu'est-ce que nous pouvons faire
quelque chose de très vite,
mais aussi, permettre aux utilisateurs de réacte de réaction.
Donc, transitionner le quota de la statistique
pour quelque chose de plus vite.
Nous aimerons que Raycast
sponsorise le podcast.
Raycast est une app pour Mac
qui est comme un spotlight,
mais en fait, utile.
D'ailleurs, simplement en ouvrant les files, les URLs,
ou d'autres app sur votre computer,
ça donne des features cool
comme l'histoire de clipboard,
le management de la main-d'électrique,
vous pouvez même voir votre calendrier.
L'une des choses vraiment cool
de ceci, c'est l'API d'extension.
C'est construit sur React
et créé des extensions
qui sentent que les contrôles de native
sont super facile.
Et puis, ils ont une store
où vous pouvez distribuer vos extensions
à tous vos amis.
Raycast est pas que de beaucoup de cool
petits features
que vous vous découvrez
en temps que vous utilisez.
L'une qui ne peut pas être
la plus changeante de la fonction
mais c'est encore une bonne
est l'Emoji.
Je n'ai jamais pu
rappeler le shortcut de la clé
pour mettre le système de l'app
je ne l'ai toujours pas vu
quand je ne l'ai pas vu.
La récaste est construite
beaucoup mieux.
Elle m'en souvient de mes émotions
et elle les filtrera super facilement
en fonction de mes workflows.
Vous pouvez aussi vérifier
avec Raycast Pro.
Avec Pro, vous pouvez prendre
l'advance de Raycast AI.
Et Raycast AI
peut faire un whole bunch de choses.
Vous pouvez utiliser pour transmettre
texte sur une page,
summariser les pages
ou, comme,
utiliser pour ce que je fais
c'est quand je développe les choses.
Je l'utilise comme
un code de buddy
pour me introduire les nouveaux concepts.
Je visse généralement
la récaste avant de visiter Google.
Pour apprendre plus sur Raycast
visite raycast.com
ou visite le 30 octobre
où nous avons parlé
à la CEO Thomas
sur le produit
et pourquoi ils l'ont construite.
Vous voulez advertiser
avec DevTools FM?
Visite le DevTools FM
sur le sponsor
et vous pouvez advertiser
avec DevTools FM
juste comme ça.
Vous voulez qu'on tombe les ades
et qu'on se met à l'intérêt?
Vite un abonné de souscriber
sur des plateformes
que nous soutenons.
Nous aimons vous avoir.
Alors,
quels sont ces improvements
de performance?
Vous avez dit que
le dom virtuel
pourrait être plus rapide.
Comment avez-vous fait?
Rien.
La main chose que j'ai vraiment focusée
sur c'est la réconciliation.
Pas parce que c'est le plus important
nécessairement,
c'est juste que c'est vraiment accessible
pour moi de construire.
Le moyen que ça fait
c'est de faire quelque chose
qui s'appelle le dom virtuel.
Donc, pour contexte,
un dom virtuel
est quelque chose
qui permet
comme un framework
comme React
pour réactuer le dom
ou comme réactuer l'URI.
Donc,
chaque fois que vous faites un component
de réacteur,
comme un changement de state,
ce changement de state
peut être traduit
à des changements de face

Le problème avec le dom virtuel
c'est qu'il doit faire
quelque chose qui s'appelle
un dom,
c'est-à-dire un dom.
Un dom, en fait,
comparé à deux trees
de différents UIs.
Donc, imagine
que vous avez votre dom
dans un dom
et vous comparez
deux différents
types de pays.
Peut-être que l'une
a l'anime,
l'une a l'anime.
Et c'est OK.
Mais quand votre feu
s'est fait très grand,
ça sort de mal.
Imagine que
votre app est au nom de l'en,
où l'en est un numéro
de nos dans la rue.
Le dom de bloc
fait un autre approche.
En fait,
le dom de la rue
a quelque chose à l'envers,
il traite
le dom de la rue
comme un template
ou comme un blueprint.
Et donc,
il peut se faire
savoir où
les parts dynamiques
sont dans le dom.
Comme
dans votre component,
vous n'avez pas
tout ce qui est dynamique.
C'est là que vous pouvez
avoir un dom
et une id.
Mais
ce qui s'occupe
est quand il y a des choses dynamiques.
Et donc,
le dom de bloc
se fait savoir où
toutes les choses dynamiques
sont,
le contenu de la statuette
et c'est comme un
direct update
de votre state
à l'UDI.
C'est ça que
le réacte traditionnel
avec
comme
le déficit
chaque noeve,
en tant que
ce qui va passer
et tout le monde
vous avez ajouté une optimisation
pour le déficit
des notes
dans ce processus
et juste
dire directement
que vous avez changé
ceci, c'est dynamique
et je vais directement
le déficit
le noeve
associé avec ça.
Exactement.
Donc
comment a-t-il
ce processus
en essayant
de faire
le dom de bloc
pour le réacte?
Ça semble
qu'il y aura beaucoup de
des lois de blocs
et beaucoup de choses
qui sont
juste
difficiles
à contendre
depuis que le réacte
n'est pas construit pour ça.
Oui,
franchement,
c'est un pain de la vie.
Le réacte
fait que
c'est

très difficile
à
travailler,
comme,
à l'interne
comme,
même dans
l'une autre
bâté,
comme,
je ne sais même pas,
comme,
comme,
comme,
c'est un








bien froid
doctors
et
papiert
a
et rappeler mon app en tant que millions,
et rappeler les sub-trees de mon app en tant que millions.
Ce qui va me faire choisir l'un ou l'autre.
C'est vrai.
Le processus intérieur, si vous utilisez notre API manuel,
est de rappeler différents composants que vous croyez en train de se démonter.
En termes de réconciliation.
Il y a des false-modes, en termes de l'implementation.
Par exemple, si nous rencontrons un rendement conditionnel,
nous espérons que les composants ou les blocs soient déterminisés.
Ils sont très stabilisés dans les structures JSA.
On dirait que vous avez une rétournée plus tard.
Si vous avez un exemple de récouru,
si votre data n'est pas rétourné,
ou si votre state de rétournée ne rétourne pas,
ça ne marche pas avec nous,
car ça a deux branches.
Ça peut rétourner deux différents types de récouru.
Un peu de nos limitations sont fixées depuis mai 2023.
Nous recommandons maintenant de utiliser le mode automatique,
qui automatique détermine
quand vous utilisez des blocs
et peut-être optimiser
et vous permet de optimiser les composants conditionnels.
C'est cool.
Qu'est-ce que l'approche recommandée ?
Vous recommandez de la rétournée automatique ?
Ou est-ce que vous vous rappelez votre app ?
Ou est-ce qu'ils utilisent le manuel ?
Qu'est-ce qu'ils choisissent ?
Quelle version ?
Pour 99% des applications,
le point d'utilisation de la rétournée automatique
est de la rétourner.
Mais dans certaines applications,
ça ne marche pas.
Ça ne fait pas de difference significative.
Notre intention est de...
Vous pouvez aussi utiliser ça.
Si ça ne fait rien, ça ne fait rien.
Pour le cas de 5% de la rétournée automatique,
votre application est
en train de se concentrer en performance.
Vous êtes dans une compagnie de stock de travail,
vous avez un point de vue très rapide,
vous avez 10 000 divs sur la page,
et ces types de applications
nécessitent une intervention manuelle.
Les idées sont assez simples pour cela.
Vous savez quand vous utilisez le manuel.
Je pense que c'est très facile,
je dois customiser ça granditement.
Vous pouvez utiliser ça.
Nous avons une documentation très bonne
pour comment utiliser et quand.
Ça ne devrait pas être trop difficile.
Dans ces cas, quand vous utilisez,
vous devez être très spécifique.
Vous avez une liste longue,
il y a un bunch d'items dans la liste,
ils sont tous en train de retourner
un html avec une route stable.
Vous devez être très proche de la route,
et ça va être un html que vous pouvez utiliser.
Exactement.
Vous savez que vous êtes sur un device bas,
et vous avez un lag,
et ça ne marche pas,
et en ce cas, c'est une bonne idée
de utiliser le million.
Est-ce que vous répliquez le besoin
pour la virtualisation,
ou vous recommencez de la virtualiser,
même si vous utilisez des millions?
Ça fonctionne tendantement avec la virtualisation.
Je pense que si vous n'avez pas de virtualisation,
c'est un problème.
La idée est que si vous avez la virtualisation,
c'est très lent,
et que vous devez mettre le million.
Parce que, oui,
à ce point, c'est un issue d'adapte.
Le moyen dont vous ne pouvez pas
conditionner,
ça me rappelle de solide.
Avec solide, c'est la même chose
où vous avez...
C'est comme un component réact,
mais si vous faites un retour en plus,
ça se démarre.
C'est drôle, parce que
j'étais sur Ryan Carniata,
qui est un solide créatif.
Nous parlions de la similaires
de la approche des millions et de solides.
C'est vraiment intéressant.
Je pense que le meilleur moyen de penser
est que le million est solide,
mais sans les signes.
Tout le monde
est conceptuellement la même chose.
C'est intéressant.
Je pense que si,
dans la fin de la fin,
il y a beaucoup de réaction
que le solide a,
qui a été tout le monde,
c'est une fréquence très performante.
Si c'est,
d'ailleurs,
fait pour les mêmes raisons exactes.
C'est comme,
surtout,
ce retour en plus,
ne pas le permettre,
ou le faire,
pour les déterministes.
Oui,
il y a toujours des limitations,
malheureusement.
J'ai des idées sur comment faire,
c'est un peu de temps.
En parlant de temps,
depuis que nous sommes sur le sujet,
et que vous avez mentionné plus tard,
vous êtes dans une phase
très transitionnelle de votre vie.
Vous allez de la haute-school
à la collège.
Je pense que dans la haute-school,
vous avez des temps en fin de la fin
pour travailler sur ce projet.
Ceci ne sera pas vrai,
quand vous allez à la collège.
Qu'est-ce que le plan pour les millions de millions
de J.S.
quand vous vous transitionnez
dans cette phase de votre vie?
J'espère continuer à travailler sur ça.
Mon but est de
essayer de faire le projet plus autonome.
Je veux juste être capable de le faire
comme...
Mon but est que
si je ne travaille pas sur ça
pour une semaine,
à moins il y aura des updates
qui vont se faire.
Donc,
des moyens que je vais essayer
de faire c'est par des bounties.
Et donc, en mettant des bounties,
si vous faites quelque chose,
vous avez 30$
ou quelque chose comme ça.
Et aussi,
en s'adverant à un corps de corps
qui est capable
de
garder le projet en vie,
faire surement que les choses
soient faites,
ce type de chose.
Mon expérience est vraiment
un peu différent de...
je pense...
mon expérience de la haute-school
était, je pense,
plus visite de mon expérience de la college.
Comme un...
comme un américain asian,
mon parents me fassent
et pour les
choses de la haute-school,
j'ai pris
7 classes de la AP
en juin 2018.
Donc, oui.
Je suis très heureux pour la college.
C'est beaucoup de liberté.
Je dois
faire les choses que j'ai envie.
Et ne pas avoir à prendre 7 AP.
Oui, la haute-school n'a pas...
je n'ai pas eu plus de temps
à la haute-school que j'avais à la college,
en tout cas.
Donc, on a touché un autre point.
Donc, vous savez,
en parlant de votre...
votre sort de la chacune de la chacune,
plus tard,
mais vous êtes gardant
un library d'open source
et, vous savez,
il y a tous les challenges
de faire quelque chose d'open source,
communication,
vous parlez d'une maintenance,
comme de construire une équipe.
Des skillets très différents
que de apprendre un programme.
Donc, quelle est votre introduction
dans l'open source
et comment vous vous sentez...
je ne sais pas,
comment vous sentez-vous comme ça?
Vous sentez-vous comme que
il y a encore des choses à apprendre?
Vous sentez-vous comme que
il y a des zones que vous voulez
improvement?
Oui, c'est une bonne question.
Je suis allé dans l'open source
parce que c'était un moyen
pour moi de partager mon travail
avec le monde,
de pouvoir bâtir quelque chose
et voir l'impact de ça.
Et de s'y valider.
Donc, l'une des choses
d'open source
était la première
vidéo que je faisais.
Et c'était vraiment cool
de voir les gens,
pas seulement utiliser
leur site,
c'est vraiment cool.
Réfracter le site
pour utiliser l'enquête,
mais aussi
voir les gens créer des problèmes,
vous savez, pour le contribuer.
C'est vraiment cool de voir
que j'avais,
tout le monde dans ma vie,
je n'avais pas beaucoup de contrôle.
C'est au moins un endroit
où je peux voir les gens,
je peux faire quelque chose
que les gens trouvent
qui est important.
Je pense que c'est pourquoi
l'open source est vraiment cool.
D'autant les stars,
les hypes,
tout ça,
c'est fondamentalement
cool de voir les gens
pouvoir bénéficier
de ce que les gens
sont excitées.
Mais, comme vous l'avez dit,
sur le site de l'open source,
c'est difficile.
Surtout,
c'est vraiment intéressant.
Je pense que
les premières deux années
de m'avoir travaillé sur million,
c'était juste
comme un cosplay
et un maintainer d'open source.
Peut-être
que chaque deux semaines,
je serais un issue,
mais
franchement,
ce n'était pas beaucoup d'activité.
Et puis,
il y avait
une période
de transition
trop grande
où je suis allé
faire des 10 issues
à 100 issues.
Et ça a suddenly
été comme,
tout ce cosplay,
je me suis dit,

je me suis dit,

je me suis dit,
je me suis dit,
je suis Slob.
Il a tropjadi
l'ully.
Et experienced.
J'étais



du
pienne.
Réelise took
this
de la communauté, de la communauté, de la finance d'entraînement.
C'est tellement de choses à penser.
Je me suis aimé la analogie du cosplay.
J'ai l'impression que ça aussi.
Tu es en public et en public, tu es en source d'une technologie,
mais quand tu es dans ta tête, tu es comme...
Ah, si ça se dérange, ma vie sera meilleure.
Et je vais avoir ce projet d'amazing que je suis à la tête.
Et ça se passe et tu te dis que c'est une vraie responsabilité.
Et c'est d'autres gens qui sont en train de se faire.
Ils ne sont pas juste NPCs, donc tu dois être un peu comme ça.
Tu as un visage sur la communauté, c'est certainement quelque chose
que nous avons trouvé par les gens.
Un des deux plus successifs que je dirais que j'ai vu en source
c'est Anthony Fou et Cinder Sorehouse.
Ces deux gens ont des milliers de projets,
mais ils n'ont pas des milliers d'heures pour le faire.
Ils sont excellents en s'appliquer une communauté
et en s'intéressant à mettre un projet en train,
surtout Anthony Fou.
Donc, la direction de ce projet est la vision de la vision
de la santé de millions,
plutôt que de la vie de la star-développe
en s'en battant tout à main.
Exactement.
En fait, Anthony Fou est un monstre.
Je ne sais pas comment il se dit.
Il est bien.
C'est un point important,
car c'est comme ça.
Quand les gens ont commencé à protéger leurs expectations
de ce que leur projet devrait être,
comme vous, vous vous implementez,
ou vous fixez ce bug, c'est important pour moi.
Mais ça change votre relation avec le projet.
Maintenant, c'est comme ça.
Vous êtes sortant de rencontrer les préoccupateurs,
mais avant, vous êtes en train de travailler sur quelque chose qui est fun.
Je l'ai trouvé, et je pense que Andrew peut réaliser ça.
C'est une bonne récipe pour les gens de la burn-out,
si vous ne l'avez pas à l'aide.
Vous devez être en train de se faire attention
à la situation des gens,
à la base de la construction,
à la façon dont je vais dire non,
ou à la façon dont je vais s'en prendre un poursuit.
Et à la façon dont je vais faire des choses.
C'est un challenge réel.
C'est difficile.
Oui, la construction de la construction
est quelque chose que je suis encore en train de apprendre.
Juste la semaine dernière,
j'ai passé 80 heures,
juste sur un souci.
C'est un très...
Ok, donc,
le souci avec Million est que
il serait si bon si c'était juste facile.
C'était quelque chose d'avocat.
Je n'ai pas besoin de faire
quelque chose que personne ne soit
comme un malade de virtual.
Et aussi, je pensais à tout ça.
J'ai juste besoin de faire ça.
C'est un...
C'est un peu plus bon,
c'est peut-être plus bon si c'était plus simple.
Mais oui,
j'ai besoin de apprendre comment toiter les expectations,
comment toiter les responsabilités.
Je n'ai jamais fait ça dans ma vie.
En faisant tout ce que ce soit,
c'est quelque chose que je dois apprendre.
Oui, les responsabilités et de dire non,
des choses difficiles.
Surtout à la fin d'un projet de source,
tu es comme, oh, les gens veulent ajouter des choses.
Oui, vas-y et ajoutes des choses.
J'adore ajouter des choses.
Et puis tu dois avoir de la preuve
de ces éditions.
Et tu as dit, oh, je dois faire ça
au final.
Mais je pense que tu as fait ça en regardant les docks.
Tu as fait un bon travail
en ne pas faire le API,
en allant dans des doigts.
Tu as vraiment un bloc
et deux autres choses.
J'aimerais toucher sur ces deux autres choses.
Mais c'est un bon moyen
de faire ça.
C'est de la faire ça,
et de la faire ça.
Et puis, je vais juste
dire les deux blocs.
Ou les deux autres choses.
Un de moi fait le sens,
l'autre je ne vois pas comment ça se fait.
Pourquoi est-il
un four-component
et pourquoi est-il nécessaire
d'utiliser millions de JS?
Le four-component est en fait optionnel.
En fait,
ça permet
à l'adresse
d'éficientement vendre
un liste avec blocs.
Imaginez-le
effectivement
comme un replacement pour la map.
Ouais, c'est assez
ça.
Pas tout ça nécessaire anymore.
En fait, nous sommes ici
macro. Macro
semble comme un babel feature
plutôt que mon
réact reconcile
replacement feature.
Pourquoi est-il en API?
C'est un feature
qui me fait
vraiment bourgeois.
Je me suis dit, je dois
évaluer ça. Je peux aussi
faire deux lines de code et
c'est mon feature.
Je ne pense pas que personne l'utilise,
mais c'est là que vous voulez.
L'approche du réact
est la même chose où tous les internaux sont
un secret de garde.
Exactement.
C'est toujours un truc fun.
Et puis quelqu'un utilise ça
et vous voulez le remettre en plus.
Vous vous dites,
c'est juste un truc fun.
Et puis vous réactez
et avez des variables.
Si vous utilisez ça, vous allez être fiers.
Vous avez juste mentionné que vous avez
passé 80 heures
en fonction de l'histoire.
C'est beaucoup d'hours.
Pourquoi est-ce que c'est difficile?
Je voulais essayer de

faire
une complète.
C'est la hydration de la nest.
Une chose que vous pouvez faire avec million
c'est
avoir un réact component
et dans ça, vous avez un bloc million
et dans ça, vous avez un bloc million
mais
la nest
n'est pas toujours hydrée.
Je travaillais sur ça
pour que ça soit hydré.
Et le truc est
que je faisais
une set-up de nest.
J'avais million sur le côté
et la nest.
J'avais un setup RSE
mais le truc est
la nest fait que c'est difficile
de développer les libraries.
Et peut-être parce que je n'ai pas un bon setup.
Mais aussi
à un moment
j'ai eu 91 aéros de hydration.
Je ne pouvais pas trouver le span
dans la diabe.
Et donc
en développant ça c'est difficile.
Et honnêtement
je fais ça tout le temps.
Un peu de ces issues sont en train
de travailler avec le service.
Ou des hydrations de la nest
ou des compilations de la nest.
C'est
mon processus.
Pour ces réactes nest
millions de choses
j'ai vu que
l'issue qui était liée au défi
était
réacte ne hydrate pas
les portales.
La raison pour laquelle
les portales ne existent pas
sur le service.
Pour hydrer quelque chose qui n'existe pas
ça ne fait pas beaucoup de sens.
Pourquoi ils existent?
Quand tu fais ce
rendering de nest
la nest rendra
via un portale réacte
pour que le réacte soit encore
un peu plus de la nest.
Exactement.
Le réacte ne connait pas
les choses millions
et c'est
encore un truc de la nest.
Il s'est fait couper
le blog de la million
et ne sait pas de quoi c'est.
Mais ça s'exprime
pour l'hydration.
Comment tu le réactes?
Je peux vous dire que je
ai quelque chose dans le service.
Le réacte 3 Fiber
c'est un projet
un des
développeurs qui a créé un projet
qui s'appelle It's Fine.
Si tu connais ça, c'est le
cartoon dog avec le feu
c'est un projet de la née.
Je suis en train
de
utiliser ce truc
pour passer des restrications.
Ça sera un experiment
intéressant.
Je me suis fait
couper le blog de la

Je suis curieux
que si on s'est fait
couper le blog,
le réacte ne connait pas
les choses millions.
Ça fait du sens.
Tu as parlé avec le réacte
et je suis curieux
si tu engage avec
les gens, si tu as des
informations.
Je ne sais pas pourquoi.
Je ne me suis pas dit
que je me suis mis trop
trop fort, mais je
j'ai essayé de parler avec
les gens.
Je ne pense pas qu'ils sont très intéressés.
C'est un des choses
où je suis sûr que
ils sont très busy
ou quelque chose d'autre.
C'est intéressant,
parce que je me sens
que c'est probablement un peu
d'une chose que tu peux apprendre
même en se défendant
pourquoi ils ont fait des décisions
que ils ont faits, je suis sûr
que ça serait très éducatif.
Si tu parles avec ça, tu dois le faire.
Pour ce qui est intéressant,
je pense que le réacte
de la décision n'est pas
non sensible.
Je comprends
Dominic
je l'ai oublié
de la fête de la fête
de la fête de la fête
il a
fait un prototype de ce réacte
en 2018.
Pas milliers, mais la même implantation
qu'une millière. Il a été
en train de travailler en inferno
et des réactes très vite
pour longtemps.
C'est
ce que Dominic
pourrait vous présenter
dans le réacte de la fête de la fête
il y a quelques ans, ou 5 ou 4 ans
d'un an, mais
il y a des réactes
de la fête de la fête
en temps de temps
d'un an.
C'est un autre approach
de réacte.
C'est cool
de voir la support que tu as
fait sur Twitter.
Je vois souvent
le sentiment que tout le monde
sait ce que tu fais.
Et c'est
une des personnes
qui a dit que je l'ai essayé
dans le passé.
C'est un bon petit
et un peu de ces.
C'est cool de voir.
Dominic est un force
et c'est intéressant de vous dire
qu'il a un truc similaire
il y a quelques ans
et c'est probablement
si nous faisons un concurrent
ou si nous faisons ce truc et ils ont choisi un concurrent.
Ça veut dire que la mode
ne fonctionne pas
en concurrent.
Ça devrait travailler.
De ce que je comprends,
concurrent optimise
la phase de réacte
et pas la réconciliation.
De ce que je comprends,
le fait de le faire
ne fait pas
tout à l'heure et en temps de réacte.
Donc, sur un component par component
de base ou de la fête
et ça commette tous ces changements.
Je l'ai testé
avec le réacte
et ça a toujours été le travail.
Mais je ne sais pas si ça fait
un grand différence.
C'est
aussi fascinant.
Je pense que les implications
de ce travail
sont très bien.
Je suis curieux
de voir
comment vous vous faites
avec ce travail.
Vous avez commencé
et vous avez dit
que je voulais faire une optimisation
et ça s'est fait
et que tous vos projets sont en train de se faire.
C'est un des quelques choses que vous êtes en train de travailler.
Vous avez un point
où vous voulez faire
un tour et puis
faire la première chose que vous faites
ou tout ça. Je suis curieux de voir
où vous êtes en train de faire cette tour.
Je suis en train de faire ça depuis 2 ans.
J'ai eu des projets de côté
mais
je suis curieux
de voir ce travail.
J'ai créé
un site Trivia
pour
des choses de Trivia Club.
Je
j'ai
créé un site Club
pour le million.
Mais c'est
ma fête depuis les 2 ans.
Je me suis dit que je suis curieux de créer des websites.
Si
vous me donnez un TELWIN et un HTML
je vais créer
une websites décennie.
Mais je peux travailler sur des tools de détail
ou des types de tooling.
Je me suis dit
que je vais avoir des amis ou des familles
qui me sont dit que je vais construire un site.
Et je me suis dit
que je ne sais pas
ce que vous avez demandé.
Vous voulez construire ce type de tools?
Oui, tout le monde.
Je me suis dit
que je vais construire

Mais je me suis dit que je vais construire


qui ne sont pas assis
pour le téléspèche.
J'ai demandé
ce que j'ai trouvé.
Je me suis dit que je vais construire
un site de détail.
Et je me suis dit que je vais construire
un site de détail.
mais je pense que ce qui a été fait dans ce projet, ce qui a été intéressant pour moi,
les développeurs ne voulaient pas...
Ils ne voulaient pas de performances.
Ils ne voulaient pas de performances.
C'est évidemment si c'est une performance, je vais le prendre.
Ou un performance très chiant.
Mais si c'est pas un bouton, je ne veux pas changer de Dino.
Je ne veux pas changer de Dino.

Il y a évidemment des trade-offs.
Je veux explorer des tools vraiment très développeurs,
comme Millie, qui automatiquement optimisent
ou des choses qui permettent de faire des performances.
Beaucoup de compagnies ont pris beaucoup de monnaie
sur des tools comme Century, Datadog,
ou des consulteurs de performance
qui ont fait des milliers de dollars.
Mais les gens n'ont pas vraiment vu les problèmes de performance.
Le site est très lent pour certains utilisateurs.
Je veux pas focuster sur Millie,
je vais plus en profiter sur des choses,
pas seulement en pensant sur la réconciliation
et des choses dans lesquelles on peut aussi
faire des infrastructures frontales
ou des infrastructures bactériennes.
Il y a beaucoup de choses pour explorer des performances
que je pense être très intéressantes et qui devraient être explorées.
Oui, ce que j'ai fait est vrai.
Je sais que sur les circles de Twitter,
il peut se sentir un peu plus fermé
parce que beaucoup de gens parlent de performances
et de choisir des tools de performance.
Mais la réalité est que quand vous êtes dans une compagnie spéciale
et que beaucoup de gens contribuent à un produit,
ils sont comme des components de construction
et des UIs.
C'est la plupart des temps que c'est tout qu'ils pensent.
Ils utilisent les tools disponibles pour faire le travail.
Les performances ne sont pas desquelles
que de l'un des PR.
C'est comme si vous avez un millier de PRs
sur une quatorze ou autre.
Et maintenant, le site est très lent
et les gens disent que c'est très lent.
Il y a beaucoup de choses.
Je pense qu'il y a quelque chose de...
Je dirais que les développeurs sont fondamentaux,
les lesés, ils ne veulent pas travailler sur les choses
au-delà des choses importantes.
Les lesés sont probablement les mêmes.
Ils sont très fondamentaux
en se solvant le problème en main,
ce qui est bien.
Je pense donc que ce focus
de la pensée des tools
qui sont de la grande surface
et qui ont des performances holistiques
sont aussi très difficiles.
C'est vraiment difficile.
Et je pense que c'est pourquoi
les autres frameworks, comme Solid
ou Svelte,
pensent en pensant
à des autres means
de rendition
ou de la façon dont on peut
faire sans un virtual DOM
ou quelque chose de très vite,
avec une méthode d'interessant
de hydration.
On doit prendre
des études très étranges
pour pouvoir
réagir à la performance.
Je suis très intéressé
à voir où vous le prenez.
Et si vous vous faites un million
ou vous vous en faites des projets,
je pense que l'écosystème
a besoin d'une performance holistique
pour le moment.
J'aime l'angle de penser
comme si je ne m'en sois pas
parce que c'est le meilleur de la code,
que vous ne soyez pas en prenant
de performances et que ça se passe naturellement.
C'est pourquoi
des projets réactes qui sont en train de se faire
en ligne, je suis très excité
et j'espère vraiment que
ils ne sont pas en train de se faire
de réacte ou de ne pas
faire de même un membre de use
pour le callback.
Mon risque serait de s'en faire
et puis
les choses de réacte off-screen
si on peut en faire ça.
Ce que je vois
des features qui sont en train
de se faire en ligne,
c'est que c'est le meilleur de la performance
mais vous ne devez pas penser à ça.
J'espère vraiment que nous pouvons y arriver.
Comme vous l'avez dit, c'est pas simple.

virtualisation
pour une partie accessible
de ma app
c'est beaucoup de travail.
Pour sûr.
Vous avez des
des défis, les développeurs ne
ne caresent pas de performances, c'est vraiment intéressant.
Vous avez d'autres
des déptiques spécifiques que vous pensez
que vous avez sorti de la même chose?
Je pense que
dans le sens des dents,
je pense que beaucoup
de benchmarks sont déprimés.
Je pense que les gens ne caresent pas
de benchmark et c'est ok.
Je pense que
à l'extérieur de ce genre de choses,
quelque chose qui a été très frustré
est l'EBT chat et le documentation.
Ça s'arrête.
Ça s'arrête vraiment.
Je suis en train de
faire des issues en PR
qui sont vraiment générés par l'EBT chat.
Oh mon Dieu. Je sais
que c'est pour aider
un programme qui m'a aidé.
Il y a beaucoup de spam qui a été créé
dans le passé.
C'est terrible.
Je ne pense pas que c'est trop spécifique
de déptique, mais je le suis.
Le point de benchmark
m'a aidé
par performance.
La partie difficile de performance
pour moi en travaillant
sur une application de réaction
de réaction est de savoir quand ça va wrong.
On n'a pas vraiment des outils
qui disent que
vous vous rendez une longue liste
dans votre app.
Ça a été de prendre 10 secondes
à prendre 20 secondes.
Si je pouvais avoir ça,
ça serait un outil pour vous.
Un futur qui peut vous faire
coucou.
Oui, c'est exactement ce que je vais travailler
sur.
C'est possible d'utiliser des outils de déptique
pour ça, mais
d'avoir le temps de monitor les pêches
et de faire des choses plus granules
que de la vente.
C'est incroyable.
Je vous souhaite de vous relier.
OK,
la dernière question.
On a souvent demandé
une question de futur.
Mais
depuis que vous êtes un programme
ou un programme plus jeune,
depuis que vous êtes en 5e grade,
c'est une longue période.
Qu'est-ce que vous vous sentez
en ce moment le plus excitant
dans le monde de JavaScript?
Si vous voyez quelque chose
plus excitant,
vous sentez le plus excitant.
Oui,
c'est le retour
à Vanillegius.
Je pense que le type script
de tous les bases est le moyen.
Je ne sais pas.
Je pense que
les projets
comme Bund,
qui réduisent DX,
qui font mieux
et qui font mieux.
Les effets de la networks
sont incroyables.
Si vous pensez en fait,
peut-être que vous êtes en Macbook
et que vous êtes un peu plus vachement plus vachement
mais sur quelqu'un d'autre,
comme ce que j'ai,
comme une crème de chute,
ça ne marche pas.
Comme ce que la NTM
tiendra 100 secondes,
Bund peut prendre 10 secondes.
Et finalement, je pense que ces tools
sont en train de se faire,
même si c'est million,
même si c'est Bund, même si c'est Quick,
et ça fait que les choses sont plus accessibles
pour les gens.
L'information est critique.
L'accès à ces websites est critique.
Les gens comme moi,
ou mon grand-mère,
ou les autres,
si vous êtes dans la chambre avec un service bas,
ou en train de subways,
ces choses se matternt.
On doit construire des tools
qui pensent sur la performance.
Je suis vraiment excité
à la mondiale de la fin de l'année,
vraiment excité à Bund,
vraiment excité à la performance.
Bund est incroyable.
On a parlé de Jared il y a un an,
et
la performance que nous avons
expérimente maintenant,
n'est pas même vraiment son goal.
Il n'y a pas été réglé
encore, qui a été élevé
par toute cette église de JavaScript.
Je suis très excité
à voir où ça se passe.
C'est cool cette semaine,
de voir un blow-up et d'avoir un bon
ton de l'amour.
Ça va retourner au réplique.
De la façon dont
les performances
sont très proches,
c'est génial.
Les gens et Dino
sont en mode de la direction positive,
parce qu'il y a
quelque chose qui se passe,
quelque chose qui se passe en Bund,
et les gens disent,
on peut faire ça.
On a entendu
que, d'abord,
Dino n'a pas
supporté
l'impact de l'NPM,
et Bund, en s'en arrivant,
est dit, on va être compatible
avec l'NPM, et Dino
dit, on peut faire ça aussi.
C'est intéressant de voir
tous ces outils se battre,
pour que
l'écosystème s'improve.
La compétition est bonne,
ou pas nécessairement
la compétition, mais la collaboration
du système.
Un peu de compétition.
Avec ça,
on va transition à des outils de la maîtrise.
La première chose
que j'ai fait, c'est de la
app Github Activity Viewer
que j'ai utilisé pour trouver des choses.
C'est Espresso
de la team MoonRepo.
MoonRepo est un
monorepo que je n'ai pas vraiment
regardé.
Mais ils créent un peu d'autres outils dans l'écosystème.
L'un est Espresso,
qui est une nouvelle
compétition de l'app.
Mais ce qui est intéressant,
c'est que
vous écrivez la source
pour la compétition de l'app.
Et puis, comme un consommateur de l'app,
vous dites, je veux ça dans ce format.
Vous pouvez dire,
je veux installer
tout ceci
en ES2016,
pour que ça soit importe ou exporte.
Je ne sais pas si ça va
travailler, mais je
aime voir les gens
ignorer que le Node
de la transition de l'ESM
a été
un monde de pain et de hâte
pour tous les gens qui sont
invités.
Et ça peut prendre
un nouveau outil comme ça,
pour nous sortir de ça.
Je suis content de voir où le projet va.
C'est cool.
Ensuite, on a Obsidian LSP.
On a parlé
avant,
sur le podcast, je utilise Obsidian
pour la note-taking.
Et
si vous n'avez pas entendu de LSP, c'est
ce que Microsoft
a créé pour VS Code,
pour vous donner des typescripts,
auto-completion et tout.
Les LSP sont vraiment fascinés.
C'est un protocole, c'est un
language-over-protocole.
C'est un protocole vraiment fasciné.
Il faut le voir.
Mais quelqu'un a écrit un LSP
pour Obsidian, donc Obsidian utilise
les files marqués.
Mais il y a
un syntaxe spécial,
il y a ce syntaxe backlinking.
Vous pouvez faire un backlink
et vous donner des options auto-completion
pour vos backlinks.
Vous pouvez
utiliser Obsidian
pour les files marqués
et pour
les files LSP.
Vous pouvez
avoir VIM integration, ou EMAX,
et tout.
C'est cool car
ça fait
les notes de Obsidian,
les marqués de Obsidian,
si vous avez besoin de
le faire en VS Code,
vous avez cette option
et vous avez une bonne expérience
de l'intervention.
C'est cool aussi de voir
l'amour et le vie de Obsidian
en plus de l'année précédente.
Toutes mes packages de Obsidian
ont plus de stars que tout mon autre
et je l'ai utilisé pour une semaine.
Le nouveau CEO est le killant.
Il fait un bon travail.
Les team Obsidian, ils ont été
un petit et un petit team pour une longue
période, donc ils ont fait un excellent travail.
Ensuite, nous avons le Web Components
DOM Part API.
Je vais vous parler de l'API
pour un petit moment.
Google
introduit cela comme
un feature expérimental dans la version récente.
C'est-à-dire
que ça vous permet
de faire des frameworks
d'éfficiel
de les notes.
C'est-à-dire
que
ça fonctionne interne
et que ça fonctionne interne
et
ça fonctionne interne
et ça peut réduire
la code de frameworks et
travailler à
un niveau néerlevé.
Je l'aime toujours quand la plate-forme
ajoute des APIs qui font que les frameworks
ont besoin de plus de travail.
C'est toujours bien.
J'espère que je vais juste s'adapter à un moment.
Oui.
Ok.
Mon dernier tip pour la semaine est
un
replacement express
pour Bun.
C'est
un server node
pour Bun et c'est très très vite.
C'est un peu plus vite
que les frameworks de Bun.
C'est plus vite que le Hono et le Bau.
Il y a des types de sécurité
même si vous n'avez pas des types
d'aide,
c'est bien.
Ça fait vraiment facile.
J'aime bien voir un type de sécurité
car ça fait que le développement est plus facile.
Vous pouvez intégrer des trucs comme SwaggerDocs
très facilement.
Si vous cherchez un server
de JavaScript très vite et vous voulez essayer
de Bun, je vais probablement checker
Alesia.
C'est vraiment cool. J'aime l'application
d'application d'application d'application
수āh
d'UP
d'Eton Nizer,
il y a удоб totalité
sur
Alesia, Bun,
HTMX.
C'est une liberté successe.
Mais :)
Je ne pense pas que c'est ça mais c'est encore
toujours éman CDC 없.

alcohol.
Rex, on a qu'un discouraged
de mettre built-in khaki
Aminus.
Well, whenever this recording is released today or yesterday was the day when
Unity announced that they were going to start charging for game installs.
So they're going to charge the developers of the game every time a user
installs their game, which is not great.
And the community, obviously, all these game developers are pretty upset.
So I've been looking at game engines.
I've always been really interested in them.
And I particularly love like 2D pixel art base games, because it reminds me of my childhood.
And this is a game engine that I encountered today on Twitter.
It's called Murder.
But yeah, it's it's specifically designed for doing like 2D pixel base games.
And it's it's a gorgeous framework.
It's got good documentation.
It's only like it's there's only like two people that are
that are maintaining it or whatever.
So, you know, it's like pretty small.
But I don't know, it's nice.
And I love these like little engines or whatever.
So I was just, you know, looking for alternatives of things.
There are a lot of really great game engines out there, like Godot is a
is a or got it, I guess, is a really popular open source one.
But, you know, there's a lot of really fun indie engines out there, too.
They're charging for installs.
That's, that's, I think it's crazy.
They're charging for installs.
Yeah.
And that's on top of, like, you know, already having like developer license.
So, yeah, it just that seems like.
It's going to kill like all indie game dev on Utidae, probably, right?
Basically, basically.
And the other thing is, like, it infects like streaming games
and web based games, too.
And the question is, like, what does it mean to install?
So, like, for a web based game, technically, you install it every time
you play it, right?
So it's like, yeah, you know, I don't know.
Just that seems.
It seems like a really poor business decision on their part.
It does.
OK, last up, we got Quick Boot JS.
So I was just on Twitter schooling and some some guy put out.
This is crazy library.
So basically, from what I understand, it runs like your app.
And then it figures out which parts of the parts of the code don't run.
And then it just, like, removes them or effectively removes them.
And this is kind of crazy.
Like, normally, we what we understand is reshaking us is it just sees
if these things are dependent on each other.
And obviously, like, things will be dependent on each other,
but they might not be used.
So this is a really interesting way to approach that.
It reminds me of things like Quick that try to defer things as much as possible.
Andrew, you beat me to it.
Yeah, reminds me of Prepack, which was a project from Facebook
that tried to do the same thing, and then they just ended up throwing it all out.
Yeah, but this is maybe to be sad.
I remember building a library back in the day.
Just wanted to use this to make my code small.
Yeah, JavaScript reshaking is hard.
Like, you think it's simple.
It's like maybe even just that import, export stuff.
No, there's things like, what are they called?
Like, you have to mark things as pure that they don't actually have side effects.
And like, sometimes some things won't get marked as pure and like randomly,
your bundle blows up.
That's something I wish we could solve in JavaScript,
is like, just make it so that I can actually
tre-shake my code rather than having to run four different tools
that all kind of do it a little bit.
And then hopefully it actually works in the end,
because that's what the current state of tooling is today.
Just like four tools that half work
and then the end they kind of work because you put them all together.
Exactly, yeah.
Welcome to JavaScript.
We pay for the speed and the choice of tools
with the lack of intense tooling sometimes
that can do cool stuff like that.
OK, that wraps it up for tool tips.
Thanks for coming on, Aiden.
This was a fun talk, both from your perspective
of trying to make React faster and as a person
that's like so early in their career
and has kind of like fresh eyes for the things
that we've been looking at for over a decade at this point.
So thanks for coming on.
Yeah, I'm super happy beyond.
Honestly, this is probably one of my favorite podcasts I've said.
So thank you so much for making it so fun.
Awesome.
Yeah, it was great to have you and just, you know,
I just want to say props for diving into such a hard problem.
I know high school in particular
can be really stressful getting to high school
and, you know, having worked on this for a few years.
It's a huge accomplishment
and definitely props for that.
You should feel very proud of what you've done.