Ils me sont montré Marco et je me suis dit que c'était possible.
Le streaming et tout ça.
Je savais que si un endroit où SSR était important, c'était très clair.
Je me suis posé en place un point solide,
ce qui était réelé jusqu'à être certain qu'il y aurait une solution de SSR.
Bonjour, bienvenue à Debtools FM.
C'est un podcast sur la production des taux et les gens qui le font.
Je suis Andrew et je suis Michael Hoche.
Salut tout le monde.
Je suis vraiment excité à avoir Ryan.
Ryan, vous êtes le créateur de Solid.js.
Je suis très excité de parler de ça.
Solid est une frère intéressante en fréquence.
J'aimerais entendre comment vous le décrivez et parler de la réaction de contraste,
l'évolution de l'écosystème et tout ce genre de choses.
Mais avant de nous dépasser,
Would you like to tell our listeners a little bit more about yourself?
Oui, c'est drôle car je suis décédé à la fin de mon travail sur Solid.js.
Je suis un développeur.
J'ai été construit dans les web depuis le 90,
quand j'étais en cours de l'année plus jeune.
Et j'ai construit un peu de la
JavaScript en plus d'un peu plus d'un an.
Et puis j'ai sorti dans la whole.net
dans les 2000s et
j'ai revu à la JavaScript en 2010
à la fin de la fréquence de la single-page app.
Et j'ai été très investi en Frontend
depuis jamais.
Mais oui, je bêtais des produits
et j'ai construit des websites pour God.
Je ne sais pas si c'est 30 ans maintenant ou quelque chose.
J'ai presque, je pense, 28 ans.
Alors,
on va commencer avec la grande fréquence que vous avez mainement connu pour Solid.
Vous m'avez dit avant le record que c'était un peu plus fort
que les gens pensent.
Donc, vous pouvez nous parler de la condition
de quand vous avez commencé, pourquoi vous avez commencé.
Oui.
En 2010,
getting back in JavaScript was amazing for me.
I had been doing all this dotnet programming,
a little bit of Ruby and PHP before that.
And it was fine,
but there was something really awesome
of going back to just building with HTML
in a sense in JavaScript and single-page apps
were like that all over again.
And I found a JavaScript framework
that I really liked called Knockout.js.
And I don't know what about it appealed to me.
There's something weird about its model.
It had these things they called observables.
It's funny because these days we call those signals,
but it basically let you kind of write your state
in this way that you could just update it
and it would just make those exact updates on the DOM.
And it was really cool because it didn't really care about much else.
It was just all based around these observables.
And I don't know, it was something clicked for me.
I had always tried...
When I first got into programming,
I really wanted to go into game programming.
And I spent a lot of time playing around with DirectX.
That's how I got into .NET and whatnot.
And something about Knockout,
I'm not clean enough,
pulled out a different old influence of mine,
which was programming circuit boards.
I'm actually a computer slash electrical engineer
by trade, not computer science.
And there was this whole idea of like,
if you apply to change,
it would apply everywhere at the same time,
like when you're modeling hardware.
And I just knew instinctively how to program that way.
It's just something that always made sense to me,
where your data itself was also declarative.
It's the best way to put it.
It wasn't just your UI, but your data.
Anyways, jumping forward a bunch.
It was a cool concept.
It was a bit messy.
There's lots of problems with Knockout.js.
I'm not going to hide those.
But if you fast forward like four or soish years,
no one was doing this anymore,
mostly because of React come out at that point.
And they were like,
worrying about state changes and all this
is really complicated.
Just forget about it.
We've made it so it's good enough
to just re-render everything.
Like instead of worrying about stuff ping ponging
all around your app
and stuff changing and not what's going on,
we'll just wipe it out
and start over again, essentially.
And the funniest thing is,
this is an old thing in graphics.
Actually, there's an idea of something called
retained in immediate mode
and React was immediate mode.
It means you don't keep the artifacts
around from time to time.
You just replace them as you go.
Where a retained mode is about mutating
an existing model.
And in game programming,
almost everything at that point
had gone to immediate mode.
It had some benefits like constant frames per second
and all those things where retained mode
could be incredibly performant
when nothing changes,
but it was unpredictable
what would happen when stuff did change.
So there's a lot of philosophy or ideas
already behind these different approaches.
But as it turns out,
the DOM itself is retained mode.
You have this model that you update and mutate.
So there is this kind of discrepancy
of trying to apply something almost like a game engine
on top of the DOM
because the models, they have to abstract.
Like they're not one for one.
And when React got popular,
it irked me a bit that
there's a lot of claims about performance
and all these things.
And I'm like, no, I'm pretty sure stuff like knockout
that leverages the retained mode approach
are more performant.
And personally, I just like the model,
the whole class components we had back then,
like and the whole kind of re-rendered data.
I mean, sure, that fits fine for some people.
But for me, I gone really,
I really like that thing from knockout
where I could just go like create an observable,
create some state, create some drive state,
and then just put it in my UI
and only those pieces update.
There's just something that just felt natural to me.
I admit at that time period,
I didn't think anyone else was on the same page.
The other popular frameworks, like Angular even,
was like, look, we don't have special data,
you just update normal JavaScript objects.
React state looks like normal JavaScript objects.
I didn't think anyone was going to bother
trying to do this kind of special data.
And the problem was knockout.js.
No one was really updating it anymore.
So I was kind of like sitting there.
I used to professionally at my work in production,
we had these knockout apps
and we kind of built our own patterns on top of knockout
to make it more predictable.
Old knockout, I mean, as I said, there was problems.
It would ping pong all over the place
and the rendering was not very performant.
Every time you added,
they had these weird data bind things.
I don't know if you've ever seen this,
but whenever you added a new template to the page,
it would have to make the HTML elements
and parse for these data bind attributes
and then apply them and then apply the transformer.
It was not particularly performant.
So when I kind of stepped back, I was like,
yeah, React got a lot of things right,
both from tooling perspective, things like JSX,
things that allow us to do work ahead of time,
and not parse through these big dom trees
and also just like unidirectional flow,
all those kind of philosophies
about control and expectations of how your app should be.
The early days of JavaScript on the web
were ones where we really had no set way of doing stuff
when we were just doing jQuery imperative type stuff.
As the need got greater,
we tried to build frameworks around 2010,
but we didn't really have an idea
of what best practices are, right?
And I mean, the very first big React talk
was rethinking best practices, right?
This is the kind of thing that I realized.
React had a lot of really smart ideas
in terms of bringing predictability and consistency.
And it was easier to work with the teams,
but I still like the other model regardless.
So, I was looking at these things and around 2015-ish,
I was like, very clear that knockout
wasn't gonna get updated.
I was looking at some other projects,
like technical knockout or whatever.
And I had this problem.
I had knockout and production code in my work
and I was like,
maybe I could just make a lighter weight or alternative,
like maybe something use compile templates,
update the tooling and kind of get knockout back again.
And that would become solid JS eventually.
I worked on it here and there,
like little ideas, played in little examples.
And then I finally was like,
okay, it's on a private get ours
or actually BitBucket, I think.
But at a certain point, about mid 2016,
I just made a commit
where I just made a repo called framework
and I just put in these ideas that I had.
And at that point,
I didn't have stuff like JSX.
I had like templating that looked a bit like views
or angulars, like SF and S4.
I had like,
I was just kind of playing around with these ideas,
but I had a system where the signals were in the forefront,
so to speak,
where the reactive data was right there in your face.
It wasn't hidden.
Even view at that point,
tried to make the stuff look like plain objects.
So I was like,
I'd found a pattern that I liked from my work
and then I decided like, okay, here, let's give it a shot.
To be fair, again, I said no one would like it.
So I just spent a couple of years there playing with it,
in my own little private.
Repo.
And at certain point,
I was like pretty proud of what I'd done.
And I was like, okay,
I wanna prove that this approach has wings.
So I started looking for online benchmarks.
There had been some in the past,
like these funny circles, demos and stuff.
There was lots of ones.
There was a ReinFlorins remix,
React Router had actually made this like DB mon database monitor one
that showed like reactors really fast
because of the way it could diff the whole page of data
like multiple times a second.
And I just collected all the benchmarks that people used
and was like, okay, does this have wings?
And that actually forced me to actually open source the project
because in order to actually put the thing in the benchmarks,
I need to actually have it released.
So that's what I did.
And that was, I guess, April 2018.
It was shortly after I'd made the decision to switch to JSX.
I actually had come across a different library called SJS,
or surplus.
And no one, it's not a particular popular one,
but they had actually used signals with JSX.
And I blew my mind.
I was like, this is what I wanted to do.
I almost just dropped my project and was like,
can I work with you, Adam?
What's the name of the main tanner?
Let's do this.
And he was like, I'm very busy with my startup right now.
I wanted to add all these features
because I was really into proxies.
I was like, in my head, I was like,
I told you no one wanted declarative data.
So I was like, maybe there's a way that I can make proxies
like the baseline and then people won't feel it like the difference.
But the trick, the hard part about making proxies,
the baseline is he had a very smart heuristic
where he'd look at the JSX and look for any place
where a function was called.
And if a function was called,
then it would know to make that a reactive expression.
If I added proxies, then every single property access
in the JSX would also become a reactive expression.
So there were changes that had to be made.
I started realizing that when I took my react patterns
and people would access data at the top level in the component,
like destructuring props,
it would cause whole sections of the tree to re-render randomly
because it's a little bit complicated.
But there was a bunch of issues with reactivity and nesting
and this unpredictable ability basically.
And I was like, OK, no, I needed to solve this.
So it took a little bit of time playing around with it.
For the most part, I wasn't too worried about components
because I was a big fan of web components.
That was like how I thought the future was going to be.
So I was like, OK, I'm just going to focus on the reactivity.
I'm going to use web components for the components and let's go.
And that was basically the start of SOLID.
No one really cared that much.
I mean, to be fair,
we started winning at those benchmarks.
And not just the ones that we'd expect to win,
but even the ones that were good based on diffing like VDOM.
The proxies were the key.
I realized that using proxy data diffing,
we could also have performance where diffing was required,
things like Ryan Florence's benchmark.
And I guess coming into 2018,
coming to the end of 2018,
I was pretty happy that I'd come up with a pretty performance solution
that worked for me.
And if no one else liked it, who cares?
But the big changing moment for the project
was actually October 26, 2018.
I remember the state because it was a huge day for us.
And it was when Danny Bromoff came on stage
and introduced the world to react hooks.
Because when that came out,
it was like being in the eye of the storm.
If SOLID had JSX and signals,
it basically looked like modern react with react hooks.
And I didn't think anyone would like these patterns.
But when they were like here,
use state, use memo, use effect,
it looked identical to what we were doing with SOLID.
And I was like, wow.
I mean, I did take the JSX from them,
but they're actually telling people
that they should mark and make their data look declarative.
And bigger shock for me at that time was,
even though it looked the same,
it didn't work the same.
I was like, I actually think what we're doing might be better.
Like they simultaneously pointed people in a direction
where the kind of way you authored components
looked the exact same.
But the mechanics behind signals are really powerful.
And that wasn't the only one who noticed this.
Right after that announcement,
Rich Harris was like, started going,
oh, we could do something like this.
And he's like, well screw it, we're a compiler.
And that was what triggered Svelte-3.
And also within that same week,
Evan U from Vue was like,
we're going to expose our reactivity system.
I said, Vue had signals under the hood the whole time,
but they didn't let you use them.
They were like just using option data objects
that they saw the hooks and like,
oh, we can just use our reactivity directly.
Like the old knockout days basically.
And this changed everything
because suddenly, solid was not only top of the benchmarks.
From an ergonomics DX standpoint,
it looked like the best practice
for how you should author UI.
So it was definitely,
that's when I put on the map.
I started writing articles on medium
trying to teach people about these concepts
because there are differences.
And react components, re-render.
And in a reactive framework with fine-grained render,
like solid, they don't.
It's only the expressions where there are signal reads.
I'm not sure how familiar the audience is with this at this point.
It's kind of funny because outside of the react ecosystem now,
these ideas have almost completely taken over.
But back in 2018,
that was not the case or even 19 or maybe 2020,
people were like, oh no, you're bringing the magic back.
It took a couple of years with hooks for people to go,
oh yeah, this is more tricky.
I used to say that was the line.
When you started having to use ref
for things that were not DOM elements,
you've crossed this line
because once you have to stop putting stuff in state
because you're worried about re-renders happening
or to share a state between different effects
or different calculations,
you know that react has gotten away
from those classes components.
So yes, it re-renders.
And that part's simple,
but you're no longer,
can ignore the way your components update,
which was the react-regal selling point.
And given that,
my perspective has been that
it's actually easier with a reactive model
to see what updates because it's right in front of you.
There's no outside of the hook.
This hook depends on this, it updates.
There's no like stale closures.
We'd like to stop and thank our sponsor for this week,
but we don't have one.
So if you'd like to sponsor DevTools FM,
head over to devtoolsfm.com.
Slash sponsor to apply.
And if you wanna find another way to support the podcast,
head over to shop.devtools.fm,
where you can buy some merch and rep the podcast.
With that though, let's get back to the episode.
So you've also been one of the core maintainers of MarcoJS
and Marco is a very fascinating framework
that I feel like was very ahead of his time too.
I actually talked to Patrick back in 2016, 2017,
maybe I don't remember exactly when.
So Marco was sort of made at eBay,
that's my understanding and they were kind of using it.
And it had all these like incredible features
that like I remember trying to do
the server side rendering story for frameworks
like React and Vue and everything used to be not great.
And there was like no streaming server side rendering
in particular, it was like all blocking
for basically all modern frameworks
or modern at the time.
And I remember like Marco had like a really elegant solution
to this like way before other teams
were like really being able to get to it.
So I'm interested to hear about the story
of like how you started working on that
and how it shaped your thoughts on solid too.
Yeah, definitely.
Marco has been a huge influence
and Marco, I couldn't believe it
when I was shown to me that this existed.
It actually, the story of Marco actually picks up
almost right after what we were just talking about.
I started writing articles on medium
and I was doing performance testing on components.
But the bigger implication of the work
that I was doing with solid
was that component model
doesn't have to be the update model.
Basically, yes, you write your code as components.
It helps you modularize, you get all the benefits
from code organization,
you get from something like React,
you have these reusable pieces.
But there's no need to say when you update some state
that the component and all the components
underneath it all have to like re-render.
And what was important about this
is as I was testing these extreme
kind of more benchmark testing things,
looking at the real cost of components when I called it,
I kind of came to the conclusion
that in a lot of frameworks,
components were pure overhead.
A lot of, classically,
a lot of reactive frameworks
made components really expensive.
They made them like an interfacing point
where it was doing all the,
reactivity was resolving.
And the coolest thing about a virtual DOM
is that you can just call the function over and over again
and there's cost, but it's not as much.
And I borrowed that concept from React
also because I used web components at the time.
So when I introduced my own component model on solid,
it was very lightweight.
I was like, oh, if people want the thing,
they'll use web components.
Over time, my benchmarking, I was like,
oh, actually, I just don't need
or want the web components.
But essentially, this basis meant
that I was looking at how to do these little pinpoint updates
and ways of keeping the code
really small and efficient
without this kind of overhead of components,
but with the DX of it.
And this was actually very interesting to the Marco team.
They actually found me through my medium articles
because I was writing these concepts,
looking at these benchmarks.
Et par le point Patrick had moved on from eBay
et le team was in the middle of doing a big migration
from Marco 3 to Marco 4.
Et essentiellement, ils ont vu que le travail
de se faire en utilisant les components
et de la réactivité fingrane
a aussi appris au problème de la hydration.
C'était la première fois qu'ils ont vu ça.
Ils ont réalisé que si vous avez cette connaissance
de la graphite, de ce que les données appartiennent,
vous pouvez les évaluer en tout autre code.
Il ne faut pas venir à l'un de les clients.
Marco était populaire,
mais je n'ai pas compris à l'heure,
pour inventer un concept de ces jours,
appelé les islands,
où vous avez essentiellement des components
qui sont les plus clins de la surface.
Les components de la surface
sont un concept similaire aussi.
Et cela leur permet de faire un peu plus de JavaScript
pour les choses statiques.
Si vous regardez un site comme eBay,
il y a des points d'intractability
avec des cartes, des boutons, des parts.
Il y a aussi beaucoup de marquants de statiques.
C'est important pour eBay
d'avoir un bon SEO,
d'avoir des choses très performantes
en temps de load.
Ils ont besoin de réduire le JavaScript.
Et la raison pour laquelle ils ont fait ça
était qu'ils avaient mis les bas-bordes
en Java,
et ils savaient qu'ils voulaient
de bouger vite et de modernes choses
pour bouger à JavaScript.
Et parce que les performances
étaient importantes,
ils n'avaient pas pu faire ce mouvement
si ils pouvaient montrer
que un web server
pourrait être comme un Java.
Et c'était assez stupide.
Ils avaient du travail très fort
pour arriver à des approaches
qu'on n'a pas vu.
Ils avaient leur propre bundler
appelé Blasso en temps
qui était en fait en faisant
dynamique sur le vol de la bunde.
Les deux sont en devin et prod.
C'est drôle,
on n'a pas vu ça
encore,
jusqu'à la vite.
Il y avait une vite
entre Blasso en 2014
et vite en 2020.
Le whole web package
n'était pas ça.
Et ils avaient ces îles
et ils avaient aussi
une autre vite
en ordre
et en ordre de stream.
Ils avaient pu
envoyer la vite
en mode de rédé.
Donc,
si vous avez
des doigts
de services différents,
vous n'aurez pas le plus
plus haut service
sur le page
qui s'est rendu
tout le pays.
C'est une nouvelle technique.
On a pu faire
ce type de code
depuis 97, je pense.
Et c'est drôle
parce que les frameworks
ont toujours, même sur le
bac,
joué avec le
mais peut-être pas
l'embrassé de la même manière.
Des grandes entreprises,
mais c'est comme un base
quand vous allez
prendre
votre eau de PHP
et pas
ici,
vous êtes en ordre de stream.
Et Marco Team
en solvant
ce qui est vraiment inspiré
par Facebook
de tous les places,
ils avaient quelque chose
qui s'appelle BigPipe.
Et
c'était un moyen
de streamer
les assets
et de streamer
les vues et ce genre
pour tous ces différents services
et de les dépasser ensemble.
Ça peut sembler
un peu micro-services
pour vous,
mais ce n'est pas nécessairement
de micro-services.
C'est pour comprendre
que
les parts de la page,
les parts des assets
peuvent être bloquées
et streamées
comme ils sont prêts.
Et ça signifie
que votre long-tail
se fait beaucoup mieux.
Vous n'avez pas ce problème
de la toute
chose qui est bloquée.
Et
Marco était
un fréquent
et ils ont révélu
l'open source,
ce qui est même
plus grave
2014, 2015.

les
features
que nous avons
vraiment
très excitées
dans 2021,
Marco a
repassé
dans le 2016
ries 있는데.
J'ai began
chodziver
en 2019
et ils vousguaient

l'occasion

moi
du temps,
j'ai pu
parler
la caméra
et
mon

m'a childhood
éposé

quand
ils sont
conf İnsen
C'est
un point
il n'est pas
pas
déb Kirén
de
sa
poil

c'était un bon S.S.R solution.
Je me suis prêt à mettre le trigger et à relier le sol en 2019.
Mais je n'ai pas fait ça, parce que je voulais faire sure que les APIs sont correctes.
Je me suis rendu compte que Marco et moi, c'était incroyable.
Comment personne ne sait ce que c'est?
En tout cas, c'était une opportunité incroyable.
Ils ont offert un travail pour le teamwork de la équipe.
Je suis relocé à San Jose.
Je suis canadien de Vancouver.
C'était une autre chose.
Je me suis rendu compte que j'ai été en train de travailler pour Big Tech en Californie.
C'était un changement de vie.
C'était incroyable, la manière dont j'ai été en train de apprendre,
de voir comment les performances se sont matées pour ces entreprises.
Parce que nous avons des équipes productives.
C'est mon premier temps sur l'autre côté, parce que je suis un mec productif.
Je suis le lead productif.
J'ai évoqué des produits.
Et en regardant les plateformes,
il y a des équipes productives qui vous embêtent pour tout le possible,
que les choses ne sont pas faites de faible,
ou que les efforts de soutien sont énormes.
Vous pouvez comprendre comment les choses sont en train de faire pour toujours
dans ces environnements, pourquoi il y a tant d'advices.
Mais le team Marco était un troisième membre,
donc soutenant tout de l'EVE, c'était un peu,
il y avait aussi un team qui a fait des components UI,
que nous avons travaillé à Jason,
mais ce n'est pas un grand team.
C'était un temps intéressant,
parce que beaucoup de contracteurs et de personnes qui sont venus,
ils se sont dit pourquoi ne nous n'avons pas utilisé React.
React n'est pas suitable,
nous n'avons pas pu garder notre performance.
Il y avait beaucoup de résentement contre Marco,
pas des gens qui ont été là depuis longtemps,
et des gens qui l'ont compris,
mais des contracts, des gens qui sont venus.
C'était une balance intéressante.
Le leadership a changé en 2020.
Il y avait des scandales, je ne sais pas les détails,
mais le CEO de l'EVE a été répliqué.
C'était un temps intéressant,
parce que ce que le team a besoin,
c'est que, même si j'ai été venu pour une raison technologique,
c'était qu'ils ont besoin d'un des gens,
de l'abattre et de faire sure que les gens s'entendent les importants.
J'ai travaillé beaucoup sur l'éducation et les matériaux de training,
qui aussi,
qui ont évoqué le nom de l'éco-systeme,
parce que Marco a eu ces écrits,
des concepts, des fragments de la base,
que l'on a introduit,
ce qui est, ces jours, ce sont les suspens.
C'était presque un décès avant leur temps,
et il était disponible en source,
et personne n'a pas l'air de l'inclure.
J'ai commencé à réaliser, en regardant,
qu'il y a beaucoup de technologies en source,
qui ont ce potentiel,
mais elles n'ont pas l'air populaires,
donc personne ne le sait,
et ils peuvent s'adopter en partie.
Mais, peut-être que,
en étant capable de construire votre site,
avoir cette puissance à votre fingertips,
un décès avant,
il se dévient en pratique semi-common,
c'est un changement de jeu,
si cela vous a apporté.
Il m'a inspiré d'en faire plus.
J'ai commencé à apprendre
de la service et de l'appliquer à la solidité.
La solidité a été 1.0 en 2021.
J'ai commencé à travailler sur Sol's Start,
qui est un métaframer pour la solidité,
et de la s'assurer que le service soit rendu en connaissance.
Mais, oui,
Marco est incroyable.
On a travaillé sur la prochaine version,
qui n'est pas encore là,
je l'ai dit à tout le monde,
et c'est vraiment difficile,
quand vous êtes en train de travailler,
c'est tellement incroyable.
Ceci, ceci, ceci,
qui m'a inspiré,
pour la prochaine version de Marco,
n'est pas réellement réellement,
mais
il a été réellement réellement réellement,
par exemple,
qui est en fait résumé.
On a réalisé
que cette technologie
de la salle de fin de gris
avec
cette hyper-narrowe
hydration,
et l'analysation de la compagnie
nous permettra de poursuivre
plus de JavaScript, plus de RunLess.
C'est fou.
C'est très facile.
C'est la première fois que je vois
un app très interactif,
quelque chose d'inquiétant,
quelque chose où vous cliquez
sur un démon simple,
et ça devient plus petit
quand vous êtes en S.S.R.
Ça fait sens,
vous êtes en train de travailler sur le service,
mais comment pouvez-vous
en faire en sorte que vous avez un compte,
des boutons, des rôles,
des changements, des études,
des études, des choses, comment vous pouvez
en faire en sorte que vous avez le service ?
En tant que service,
c'est plus que vous pensez.
En plus de S.S.R.,
ce n'est pas le cas,
quand vous vous ajoutez un rendu,
votre JavaScript se rend plus grand.
C'est intéressant.
Marco était très important
pour le développement,
c'est juste d'understand que nous ne sommes pas
à la place où nous devons être.
Il y a beaucoup de places
et de l'espace,
dans ce genre de zone
qui est encore
à la place.
Pourquoi pensez-vous que Marco n'a pas été
en train de travailler ?
C'est un peu triste
que ça n'a jamais été un appeal plus grand.
Il y a quelques choses. Patrick est en train de

si eBay a pu le même
et que META a pu,
ça pourrait être un peu différent,
mais quand le premier autorité
a pu,
il y a eu des choses qui se sont faits
avant le 3 de l'année,
ou...
Je ne suis pas sûr.
C'est très compliqué.
Marco était un peu extreme
sur sa template.
On parle d'innovation,
ils avaient des components single file,
mais ils ont aussi utilisé
leur compilation
pour des syntaxes spéciales.
Marco est un genre de
compilier.
C'est drôle.
Ces jours, je pense que c'est beaucoup plus accepté.
Mais
on parle de...
Felt3 a
créé un compiler pour les masses.
Marco était en train
de travailler en 2015.
Il y a 4 ans
avant Felt3.
Les gens ne sont pas
les cintes.
Ils sont très sensibles.
Il y a des raisons mécaniques
pour les analyses compilier.
Mais...
Je pense que c'est un zone
qui est un peu bizarre.
On parle de la période de temps
quand tout le monde parle de la page single.
Quand Marco...
On parle de la période de 20,
20, 20, 20, on parle de Marco.
On a des questions.
Qu'est-ce que le gouvernement de state?
Et c'est...
Quoi que tu veux.
Le gouvernement de state n'est pas le focus.
Je pense que tu peux poser le gouvernement de state.
Comment avec le routier?
Il n'y a pas de routier.
Parce que c'est un framework de la paix.
Tu n'as pas besoin d'un routier.
Et aussi, la conception est
que la paix,
la vieille chose,
la page re-loads,
pour les choses
que tu veux sur la page fast,
c'est bien.
Quand tu es en train de faire des pages,
tu peux faire des résultats sur Google.
Mais si tu es en train de faire une app
très interactive, tu ne veux pas re-loader la page.
Les choses, les browsers ont été plus vides
et la streaming a été très obvious.
C'est très cool que, avec un MPA,
tu pourrais être sur une page,
cliquer sur la prochaine page,
et les trucs de la paix, comme la chelle,
pourraient être loadés
presque immédiatement, comme une CDN.
Et le contenu pourrait être streamé.
Tu verras les indicators de loader.
Donc la différence entre une app single
et une dame, c'est que les gens ne se sentent pas
si grand, parce que tu as juste switché la page.
Les trucs, ils se dégâchent jusqu'à
les contenus disponibles.
Les browsers se dégâchent,
puis tu verras le header,
donc il n'y a pas de flic et de la loader.
Il ressemble à un peu d'interact,
mais on a été vendus
pour un peu d'un peu,
le client de la rendering était un délicat.
Et je ne vais pas vous dire,
il y a un grand bénéfice,
mais il y a des choses qui ont fait
différente que tout autre à l'heure.
Et oui, je ne sais pas.
C'est une des choses intéressantes, parce que,
comme je ne sais pas comment la mentalité
changeait si rapidement en 2020,
où les gens étaient comme ça,
quand Astro ou Fresh ne sont pas là,
ou pourquoi les gens ont des components de server,
pourquoi ça a s'est réveillé et que les gens l'ont accepté.
Je pense que c'était parce que de la Covid
et d'économie, et d'incrédits,
il y a un tout petit temps
où tout le monde pensait
qu'ils pouvaient faire du môtre
et d'échamage.
Les wai fidélóg doctors
Lehrer,
They shown money for station
to creating
certificates
that help
finding
products
who build
thealle
frameworks
reportad

superpower
Mais si vous regardez le mouvement de la métaframe de 2020,
entre la suite de JAS ou de la remise,
vous commencez à penser à comment les entreprises ont été instrumentales
et en poussant cette mentalité en termes de SSR,
vous commencez à comprendre que c'est peut-être pourquoi.
Mais à la fois, Marco était la chose qu'on ne pensait pas.
Les développeurs de la back end sont comme,
pourquoi j'ai besoin de ce type de JavaScript ?
Et puis, les front-ends sont comme,
vous n'avez pas l'approche du hok du plus tard
à la management du state.
Ce n'était pas passionnant.
Oui, je suis pas en train de regarder mes PRs.
J'ai eu quelques PRs pour Marco, c'était en 2015.
Je pense que, à la fois,
le service de rendition n'était pas vraiment un truc pour les frameworks frontiers.
C'était un truc, mais le service de rendition ne était pas ça.
Je pense que le service de rendition en particulier était juste pour le public.
Il y a aussi d'autres choses.
Nous avons lsp, le langage de service,
ce qui est fantastique.
Parce que, à la fois, aucun éditor que vous utilisez
a des bonnes features de toutes ces langages.
Et Marco, en tant que le plus éditor que vous utilisez,
vous n'avez pas de bon contexte de highlight,
d'autocomplete, etc.
C'était une partie des temps qui ont fait ça difficile.
Je pense que c'est un truc qui a été très important.


Mais, je ne sais pas.
C'est vraiment révolutionnaire,
car je me souviens d'être un peu pire.
Je pense que l'un des choses que j'ai regardé à l'époque,
c'est que je travaille sur une équipe avec des designers
qui savent comment faire des CSS et HTML.
Et beaucoup de les frameworks frontiers sont très bizarres.
Et c'est un truc qui est très différent de la service.
Il y a des PHP ou des autres.
C'était vraiment la première fois en classe
et l'établissement de la pattern isomorphique,
les components de single file, les hydrations.
Toutes les choses que j'ai fait sont incroyables.
On a un membre sur ma chaîne
qui est le hashtag Marco fait d'abord.
Le liste est extensif.
C'est vraiment un truc qui est incroyable.
Ils ont fait un certain set de trade-offs
qui ont donné leur pouvoir incroyable,
mais c'était vraiment difficile.
Le tout de la tooling, c'est encore à ce moment.
Je fais mon propre stream,
et j'ai eu Dylan en une fois.
On a spent tout le temps en construisant la langue.
Il était vraiment en train de montrer
comment il est arrivé avec toutes les différentes tutories,
comment faire syntaxe,
comment faire autocompletion,
comment faire l'intention de l'intention,
comment faire parsing,
chaque compilation,
chaque partie de l'exemple,
ce qui fait que tu construis les langues.
C'est un peu drôle,
en une main, les gens se disent
que quand ils voient quelque chose,
ils disent que pourquoi ne pas faire un JSEX,
pourquoi ne pas ajouter un feature?
Tu comprends combien de choses
tu dois toucher pour pouvoir faire ça.
Il n'y a pas de petits trucs,
tu peux essayer de l'utiliser,
ou tu vas tout de suite,
c'est important pour moi,
je vais tout de suite.
Marco était l'un des premiers à faire ça.
C'est aussi un de ces trucs,
où tu te dis que tu vas tout de suite.
J'ai eu l'expérience assez,
pour ne pas être...
J'ai eu une seule développe,
pour prendre le temps.
Tu sais que c'est des choses,
et des gens pensent que nous avons copié,
et on réacte.
C'est plus de...
Templating.
OK, c'est disponible.
OK, JSEX, bon.
Je me souviens,
nous avons eu l'approche des signes,
avant que les hooks arrivent.
Et c'est...
C'est la compétition de fonction,
avant de la finir.
C'est beaucoup de travail.
C'est comme...
Quand tu as signé,
tu es...
C'est un effort triple.
Mais,
ce que Marco peut accomplir,
et c'est très évident,
dans la prochaine version,
c'est quelque chose que...
Les gens n'ont jamais vu.
C'est incroyable.
Tu es en train de le faire,
je ne peux pas attendre pour ça,
mais...
Comment ça a été,
la source de clôtures,
à ce point?
4 ans?
C'est pourquoi je n'ai pas le temps
de parler de ça.
Je veux dire,
les choses semblent que nous avons
terminé les problèmes,
et nous nous sommes en train de
se battre en 2022.
Mais c'est toujours difficile,
quand tu as quelque chose
que tu dois,
en première et en foremost,
faire du travail internement
à l'EBay,
ou à ta plateforme.
Donc,
la version cliente,
pourrait être relée aujourd'hui.
C'est un truc,
mais tu es comme,
ok,
comment tu fais tout le stream,
tout ce genre de choses.
Ce sont des features
qui sont dépendantes
du système d'éco,
et c'est comme,
oh,
tu sais,
c'est...
Ouais,
c'est intéressant.
Comme je l'ai dit,
je ne parle pas de ça,
parce que le potentiel ici
est très haut.
Je ne sais pas si
ce sera reçu
plus bien que ça,
en 2015.
C'est...
C'est toujours un alien,
un creature mondial,
mais...
c'était une bonne expérience
pour moi,
parce que ça m'a donné
cette capacité
pour être sur les deux
très opposants
du spécificat des designs,
pas juste le service
et le client,
mais,
l'anglais
et le JavaScript.
En un peu de façon,
le réacte
est la popularité
de l'anglais
et je ne pense pas
que c'est le cas anymore.
Je pense que Solid
est la première
des frameworks de JavaScript

Et Marco est,

quand les gens
ont fait le langage,
Marco est la plupart de ça.
Donc,
ça m'a donné cette capacité
de l'expérience
de l'extrême
sur les deux côtés
et de l'expérience
sur les autres espaces de solution
et de comprendre,
en mon avis,
l'une des meilleures
de la manière non compromisée
de l'approche
sur les deux côtés.
Et ça m'a aidé
à comprendre
les éléments
que j'ai fait,
que je n'ai pas aimé
les traitements,
et
m'a aidé à savoir
où j'ai besoin
de solutions à faire.
Dérilier
sur ce point de JavaScript,
un autre chose
que Marco
a pionnié dans ce space
était un approche de compiler
où un compiler
est une partie
intégrale de l'emploi.
Svelte continuait à l'envers.
Solid a ça maintenant.
Reacta même a ça maintenant.
Et je me sens qu'on a
des deux
compétitions d'envoi
où les gens sont comme
compilers sont bons,
ils font des codes plus facile.
Et puis, l'autre côté,
c'est que
je n'ai pas envie de
aller à un point de compilation
à mon application.
Donc,
dans votre opinion,
où pensez-vous que le futur
est en train de faire


Et donc,



qui n'a pas besoin
de compilers anymore ?
J'ai vu que Solid
a un compiler optionnel
mais avec un tout un peu
de traitements.
Oui.
Non.
Oui.
C'est un truc
qui a sauté
une certaine chose.
Mais c'est sauté
un long, long, long
temps.
Il y a des extremes
comme Marco
et, en général,
c'est sain.
Svelte 3,
c'est sain.
Parce que c'est
comme les gens
qui vont aimer
et qui sont comme JavaScript.
Let X
ne peut pas
dans un JavaScript
qui signifie
que ça va réactiver
les updates.
C'est juste pas un truc.
Mais,
d'autre côté,
les compilers sont
dans un JavaScript
depuis
dans différentes formes
pour toujours.
En fait,
on peut regarder
des trucs comme un coffe
ou des langues
et on peut s'éteindre
dans un type.
Un type
est compilé.
Un JavaScript est pas
comme...
un solution.
Mais,
bundlement.
Bundlement,
c'est une formule de compilation.
Il y a un tout billet
vers le no-billet.

essentiellement,
c'est pas...
C'est pas...
C'est pas
un grand granuleur.
Pour ceux qui ne sont pas là,
c'est quand vous
vous dédiculez
un code en-deux
à votre bundle.
Mais,
ce code en-deux
n'est pas juste
ce que vous importez.
Les modèles
de la couture
sont basé
sur des features
qui peuvent être utilisées.
Ils peuvent être
en train de droire le code
dans les fonctions.
Un des
les raisons solides
si smalles
est que
si vous ne importez
certaines features
comme les suspens,
on peut être
d'accord,
c'est impossible
d'avoir
un variable
qui signifie
que chaque switch
dans l'app
peut
passer
si
il y a des transitions.
Parce que
ce global
que nous avons,
que nous avons
quand vous
vous dédiculez
ce code,
on peut être

déderir

des séances
qui n'ont pas de


Les




des
des
des
des


des






des
des


des
des


des
des

des
des
des
des
des
des
des
des
des
des

des

des
des
des

des





des
des
des
des
des

des
des
des
des
des

des
des
des
des
des
des
des





des
des



des
des


des
des
des
des
des
des
des
des
des
des
des
des
des

des
des


des

des
des
des

des
des
des
des
des


des
des
des
des
des
des
des
des
des
des
des

des
des
des
des
des
des
des

des
des
des
des
des


des
des

des
des
des
des
des
des
des
des
des
des
des
des
des

des
des
des
des
des
des
des
des
des
des


des
des


des

des
des
des
des

des


des
des
des
des
des


des
des
des
des
des
des
des
des



des


des
des
des
des
des


des
des
des
des
des

des
des
des
des
des
des
des




des
des


des
des


des

des
des
des
des

des
des
des
des
des
des
des
des
des


des
des
des
des
des

des
des
des


des
des
des
des


des
des
des
des
des

des
des
des
des
des

des
des

des
des
des
des
des