Maintenant, je pense que Marcos est au point où c'est le meilleur framework de multi-page app
que vous pouvez utiliser en termes de performance et, probablement, DX, et ce genre de choses.
Et notre next goal est de faire le meilleur framework de spot que vous pouvez utiliser en termes de les mêmes choses.
Bonjour, bienvenue à la DevTools FM podcast.
C'est un podcast sur les tools de développement et les gens vont les faire.
Je suis Andrew et c'est ma co-host Justin.
Bonjour, tout le monde.
Notre guest aujourd'hui est Dylan Piercy.
Donc Dylan est sur le team d'engineering à eBay et a travaillé sur MarcoJS.
Nous sommes vraiment excitées à parler de votre travail sur Marco.
Mais avant de nous le dire,
Would you like to tell our audience a little bit more about yourself?
Yeah, so yeah, my name is Dylan,
and I've been at eBay now for almost eight years.
I've basically been working in like front end open source tooling, whatever stuff.
For quite a while, very into like progressive enhancement,
low javascript, that sort of thing.
And that sort of brought me into the Marco world,
which is something that you know a framework that a lot of people haven't heard about at all.
Although, you know, recently people are talking about it as far as like,
oh, it's innovated in these certain ways and all that stuff.
And it's actually super interesting and we're continuing to innovate with it.
But yeah, I've been at eBay mostly working on that and other like front end tooling that we have at eBay.
And yeah, so I'm happy to go into like a history of Marco or like whatever you guys want to,
you know, chat about, because that's mostly where I'm at working on Marco.
Cool, yeah, before we dive into Marco,
why don't we talk a little bit about like what it's like to work in platform engineering at eBay?
eBay's really fascinating company, been around for a long time.
And I'm sure you all have some really, really interesting like platform challenges.
So, so what's your experience been like on the platform engineering team at eBay?
Yeah, I mean, it's been really rewarding to work on
because you get to build something and then see it be, you know,
roll out to so many teams and have a lot of, you know,
people like direct feedback from teams who either like the product
or are trying to make it work for certain use cases.
And so, you know, like I said, I was working on like some open source stuff before,
but being able to build something that's open source and get feedback on it
from people who are deploying it at scale, like right away is super great.
As far as, you know, eBay goes, it is a very old company.
So there's lots of tech debt that, you know, we're continually trying to address,
but there's also like lots of expectations around performance
and what it actually means to, you know, for the product to be done
and accessible and like all those sorts of things.
And so, like, you know, that is a big thing
that we're constantly trying to keep in mind,
like this experience was built in 1995
and was able to be, you know, streamed over DSL
to whatever computer and it worked moderately fast.
Like, why is it slow now?
Right.
So that it's very interesting to have that kind of perspective.
So in your work, are you like primarily just like focused on Marco?
Is there like other sort of like tools
that the platform engineering team or like your part of the team
ends up like touching?
Yeah, so there's a whole bunch in the ecosystem,
like the Node.js ecosystem at eBay.
Like, we've got to think about internationalization.
We've got to think about how we're setting up our servers.
We've got to think about how things are deployed.
We've got to think about the CI's and like all this sort of thing.
Like everything, it's fairly holistic
in terms of the front end experience.
And then as far as Marco goes,
there's like integrations into all these different things
or oh, we want to deploy to the edge now.
So it's like, well, what does it look like to deploy
Marco to the edge and all that stuff?
So there's a lot of things like that.
Plus, there's just like general like guiding teams on,
what is the best way to architect this?
Because Marco is,
you kind of have to have a different mentality.
It's not a single page app.
You're thinking about things more in terms of,
oh, what JavaScript am I actually sending to the page?
Or like, when can I flush this and all that stuff?
There's just different things that you have to think about.
And so helping teams through that sort of thing.
Yeah, but a lot of random tooling,
even like testing tooling,
like visual regression testing or whatever,
there's things,
like we're not happy with a lot of solutions
that are out there for that.
So we build tools around that sort of thing
and lots of different stuff,
which is, yeah, fun.
Nice, nice.
Before, one last question before we move on to Marco.
So you've been at eBay for a while
and like you mentioned,
eBay's, you know,
for a tech company, pretty old.
And the web has evolved a lot over that time.
So I'm really curious,
as you've watched the web evolve and,
you know, things like,
in some ways become simpler,
like, CSS is a lot more capable now
than it was like five years ago,
10 years ago, whatever.
What are the like,
biggest takeaways and the evolution of the web
that make your work easier or harder today?
Is it like,
is it substantially different?
Like, I'm sure eBay has a lot stricter browser support
requirements than a lot of organizations would have.
So I'm just curious,
like, where things are
and like what's your big learnings are to this point
and like how the evolution of the web has affected your work.
Yeah, so I mean,
at least for me,
the way I think about a lot of things
is how we can like progressively enhance things.
So I'm trying to think about
what the lowest common denominator is,
given what our like targets are right now.
And like,
as long as you have that mentality,
it kind of doesn't really matter
what comes out
because you're trying to think of
how to work within those limitations.
And you can still,
you know,
deliver really good things
and enhance on top of it.
But as far as like the web goes,
I think the trickiest thing
is that,
you know,
a lot of people are building web apps now,
like full fledged applications in the browser
and they're like,
well, I can do anything in this application.
I can, you know,
have this long live session,
I can do animations across pages
and like all these sort of things.
And so some of these trade offs
that you might make
if you're trying to serve
the lowest common denominator,
you might not want to make
for those types of experiences
or at least it's very challenging
to figure out
how you're going to make that work
with those experiences and enhance it.
And so a lot of developers,
especially now,
obviously are like,
well, these tools can do everything I want,
right?
And they give a good DX as well.
So it's like,
why don't I just go with that?
And part of the answer,
like from our perspective,
is, well,
okay, what about the users
that that doesn't work for?
And also,
what about performance?

that's basically what it comes down to for us.
Now, in terms of
the like,
server-side rendering
and links and forums
and all that stuff,
obviously,
browsers have continued
to get better at that sort of thing
as well with like,
you transitions
and paint holding
and the BF cache
and like all these sorts of things.
There are features
that are still being added
for this like,
you know,
non single page app model
that I think are making things
a lot nicer.
But yeah,
so that the fact
that developers are kind of
expecting
that they can do
anything on the page
like that it is a full app
is something that is
you know,
continuing to increase.
And so we're trying to
meet developers
where they're at
as well
and make it
so you can build
these things
without the compromise
which is the hard part
and that's kind of our goal.
Thanks to WorkOS
for sponsoring
today's episode
of DevTools.sfm.
So picture this,
you're on a Zoom call
with a potential customer.
The demo went great,
they're interested
and then
comes the famous ask
to you support
SAML
or SSO
some other
enterprise feature.
And you pause
and you say
yeah,
it's on our backlog,
we can prioritize that for you.
And then you just have to get to work.
But
if you don't have time
to build that,
that's where WorkOS comes in.
WorkOS gives you everything
you need to make your app
enterprise ready.
So thank SSO,
SCIM,
audit logs,
fine grain rolls,
even domain verification
and credential storage.
Everything with modern
well design
APIs
and SDKs
that you won't hate using.
Their admin portal
handles onboarding flows.
They have the vault feature
to help secure secrets.
And the docs are really good.
Their actual modern developer docs,
they're clear,
example driven,
written for humans.
It's delightful.
Everything is modular,
so you only need to use
what you need.
And it scales with you
as customers
start asking for more functionality.
So the next time you're asked,
someone asks you,
do you support Sal
or some other enterprise feature?
You can just say yes and mean it.
And if that sounds good to you,
head over to WorkOS.com
to learn more.
Yeah, so that's a good transition
into talking about Marco.
Marco doesn't aim to be that
like spa model
with all those bells and whistles.
It was bred from a much different set
of constraints.
So can you detail like
what constraints led
to the inception of Marco?
Yeah, so I mean,
obviously Marco
was created at
and used primarily by eBay.
And it came about in 2012.
But, you know,
eBay, like I said,
has been around forever.
Like since 1995,
obviously you had like auction web
and all that stuff.
And it was actually written in Pearl.
And then Pearl was too slow
as it started to scale.
So they switched to C++
but that was too un maintainable.
So they switched to Java,
which was a little bit faster.
But the thing is,
obviously during that time,
JavaScript is becoming
more and more prolific.
And you can do more and more
on the client side.
So JavaScript starts sneaking
and enhancing certain parts
of the experiences,
which is good.
I mean, basically,
you end up in 2012
with this experience,
which is Java rendered,
string concatenation,
like pretty fast.
And then, you know,
snippets of JavaScript
that enhance various parts
of the page.
And another thing
to keep in mind with eBay
is that, you know,
a lot of people are coming
to eBay from a link
that someone shared
or from a search engine
or whatever.
So like this whole amortized
cost savings
that you get from a single page app,
you don't necessarily get
with eBay or people might
go to eBay
and open up like 10 tabs.
And it's like, OK,
well, if that's 10 spas
you're opening,
you're not really saving that much.
You're just using more memory
and all that sort of thing.
So anyways,
eBay was in this place
where they have this Java app,
sprinkling of JavaScript.
But the big problem is,
you've essentially got two apps.
And if you want to do
some rendering on the
JavaScript client side,
you've got to implement it
in a totally different way
than if you're working
on the server side.
Two different paradigms
as well.
So it's just like a maintenance
nightmare to manage this.
And at the same time,
in 2012, people are like
coming out with React
and Angular.
And all these tools
are popping off.
So the question obviously was,
well, can we just use these tools?
And the answer was,
kind of no,
because we could not compromise
on those performance metrics.
But obviously,
we still wanted to have
this unified developer experience.
And so basically,
initially, React was considered
as one of the things.
But the things that we needed
basically right out of the gate
is streaming.
And probably,
most people are familiar
with streaming right now.
But streaming is something
that's been in Marcos
since 2012.
And ultimately,
all streaming is sending
as much HTML
as you have available
without waiting
for whatever services
you have
that are responding
with the loaded data
that you had to get
that specific to the page.
And the nice thing
about streaming is
obviously,
you can send out stuff
to the browser
and have the browser
start downloading
assets and images
and showing content
to the user.
Without having to wait
for your slowest service.
And at eBay,
there's a lot of services.
Some of them are slower
than others.
So it's super important
that we're able to deliver that.
So essentially,
if we were to say adopt
React or Angular or whatever,
the fact that there wasn't streaming
would essentially mean
that we're just throwing
two seconds or so.
The page load time
is just going to be two seconds longer,
which is just not acceptable.
So we'd have to shim that back in
or something like that.
And also at the time,
Angular didn't even have a
server-side rendering story.
At the time,
they were saying
just pre-render it
with a web browser,
which is obviously
terrible for performance.
So that gets to the
horizontal scaling aspect of it.
How can you
actually render fast,
not just get the content
to the user fast,
but actually render fast
so you don't have to
have so many servers?
Because eBay also
has some server farms and stuff.
So the other thing was,
okay, obviously,
spinning up a browser
is super slow.
But even in React,
you have to spin up a VDOM,
or not spin up a VDOM,
but create a VDOM
and then serialize that to HTML
versus string concatenation.
So we're comparing
against the Java app.
And so the Java app
is just concatenating strings.
And it's basically
like two orders of magnitude
faster than React
can render its HTML.
So it's like, okay,
how are we going to compete
with that
and the fact that we don't have streaming?
And then the other thing is,
the snippets of JavaScript.
Like we're comparing
a full page being rendered
in the browser
versus snippets of
hand-coded JavaScript
basically for the interactive pieces.
So essentially,
there's no way to compete
on the server rendering performance,
the streaming performance,
or the snippets of JavaScript.
And so that's where Marco
kind of was like,
okay, how can we answer these
while still having a unified DX?
So even from 2012,
when Marco was created,
had streaming,
had islands architecture,
although at the time
we just called progressive,
or sorry, yeah,
we had progressive rendering
and partial hydration
is what we call islands.
Anyways,
so we had all these things
sort of from the beginning
and that's essentially
been our mental model
because we wanted to have the DX
where you're writing
in a single paradigm,
but you can have client rendering
and you can have server rendering.
And so Marco was
the first front-end framework
to support streaming.
Like there was dust,
but like, you know,
server-side rendering technologies
that could do streaming,
but no real front-end framework
supported streaming in 2012.
Marco's the first islands architecture framework
and also Marco's the first
framework that actually compiled
differently for the server
versus the browser.
So those are places
where Marco,
you know,
kind of innovated
even way back in 2012
and we've just been refining that
sort of ever since.
But we've also been
looking at like
what the major foot guns
of this approach
and, you know,
like I said,
it's very easy for people to deopt,
especially with islands.
And so comparing,
like,
basically that's like
why Marco up to today.
I think Marco even has
you know,
all these things
whereas most frameworks
have like two of those things
right.
But yeah,
so Marco six
is the thing that we're
we've been working on
for six years.
It's actually been
a very long time
and there's like a joke
like what will come first
GTA six
or Marco six,
but what we've got
six is delayed so
we're good.
But anyways,
yeah,
so Marco six
is the main thing
that we've been working on
and the goal of Marco six
is to make it so that
you're not having to think
as much about
these islands
or this architecture
and that you can
write things like
you know,
most people are familiar with
writing a single page app
looking thing
and have it actually deliver
you know,
just the amount of JavaScript
that's necessary
and you know,
stream things out automatically
and like that sort of thing.
So that's
kind of where we're at.
Did you have any questions
about like history of Marco
before like
or where do you guys
want to take it?
Yeah,
I kind of want to dig into this
a little bit
before we move on
because it's like
I think it's important to
set the stage for people,
especially if people were newer
in the industry.
So we're talking about
like the time that
Marco came out,
there was like
there was no web pack
really.
There was like
the world of bundlers.
There was actually a bundler
like beside Marco,
there was also LASSO
which was eBay's bundler.
So like yeah,
there was no web pack.
I mean, yeah.
I think web pack was around
but not in the way that
people would think about it today.
Anyway.
Yeah, I mean it's really
it's really wild to think about like
how far ahead Marco was
and a lot of like
the core technologies
because like when
when React
sort of first hit
the public space,
yeah, you're right.
It's like all
like just rendered a string
was the big thing.
And I think view
like view to
or something sort of
beat them to the streaming
rendering like setup.
And it like took a while
to get streaming rendering
and then even still
like just years of churn
of like, okay, well like
how do we handle like
styles in the head or whatever?
You know, it's like
a bunch of like
challenges in that space.
And meanwhile,
like Marco had
out of order streaming
which is
this insane feature.
You could say
React had streaming
since I want to say
it was like 13
or something like that.
Like they had the render
to node stream
but it's like
it's still a synchronous render.
They're just chunking it up
because it's so slow
that you might as well
flush some of the
H&L wire going.
Anyways, so view is like
kind of the same thing
where it's still a synchronous render.
And so Marco from the beginning
has had the out of order
flushing where basically
asynchronous content
does not block
the synchronous content
and things shuffle into place
as the browser
receives it.
And so,
yeah, that's a big thing
for Marco for sure.
But yeah,
there's actually been so many
so much tooling
that we've had to consider
uniquely just because
of the island's architecture
or the streaming
or whatever,
like pretty much nothing
supported that.
Like streaming,
how do you stream in Storybook?
How do you consume?

do you know what I mean?
Like no tools actually support
these patterns.
So it's really great for us
that different frameworks
are picking up
these technologies and strategies
just because it means
that we're gonna have to do less work.
Like we don't have to maintain
our own bundler anymore,
which is really nice.
And,
but even things like
we have our own serializer.
Obviously,
we have our own compiler
and our compiler
is maybe closer to a bundler
than it is like,
you know,
a spelt compiler
or whatever
where it's looking at
an individual template.
So there's just a lot of things
that we've had to consider,
but at the end of the day
our goal is just to make it
so that you can have
a nice DX
while still delivering
that performance
because we still,
to this day,
can't really compromise
on that performance.
Like you're not gonna go to
you know,
some executive and be like,
okay, is it all right
if we just like,
you know,
cut the performance in half,
just that we can move a little faster.
And the answer so far
has been no.
So I'm sure a lot of those constraints
also influence
the way the syntax came about too.
Because if you can't rely
on JavaScript for things,
what's your next tool
in the box?
Well, it's HTML, right?
Yeah.
And so I mean,
it also plays a little bit into
that Marco wants you
to be thinking
from the HTML first.
Like you're writing an HTML template
and that template
is declarative
and things just like
go through that
and Marco does the right thing.
Like that's the goal.
Whereas JSX sort of,
you know,
it's just an abstraction
around like function calls
and JavaScript objects.
And obviously you can compile it
to different things
like solid does and whatever.
But at the end of the day,
it's just,
you put a snippet of stuff
inside JavaScript.
Now, the problem with that
is as soon as it's inside JavaScript,
you have to understand
all of the JavaScript
in order to do any optimization
or you're going to be
breaking people's assumptions.
So like if you're using
something like quick,
you know, quick has a bunch of
limitations around
where you can introduce state
or you've got to use the dollar
in certain places and all that stuff.
And you're like breaking
JavaScript expectations.
So Marco's approach
has been to basically
start from HTML.
So like
when you're right in the template,
you're just writing HTML.
But we want to make a language
that is as if
JavaScript and HTML
were invented together.

So you actually have
JavaScript imports in Marco
and the attributes
are actually JavaScript values.
So you don't have to like
curlies around them
or anything like that.
You can just,
you know,
set a JavaScript expression
as the value.
And there's a whole bunch of things
like that.
But the other piece
is that we don't touch
your JavaScript.
Right.
Like any JavaScript expression
you have in the Marco template
we'll just run
as JavaScript runs.
But that's why we introduce language
that we can optimize
however we like on
on the outside of that.
And the thing
that's kind of cool about that
as well from a DX perspective
is it means
that we can enable things
that you couldn't do
at least in a syntactically
good way in JavaScript.
So like we don't have hook rules
for example.
And control flow
is composable.
So like in a Marco,
in Marco,
there's like an if tag.
But you can create your own if tag.
Like everything is composable
because our primitives
are our language
rather than
some contract
with how you write
JavaScript with a dollar sign
or whatever.
So that's been one of our goals
to make it so that
the DX is good.
You can write this template
that looks like HTML
but has all the
JavaScript power
that you would want.
But then also
like given that
we've created this language
and restricted it in a way that
can be analyzed.
That's what allows us to do
the future stuff
that Marco 6 is all about.
Yeah.
I find it funny how like
both Marco and JSX
kind of took the same prompt
and went like the polar opposite direction
where it's like
we wanted to combine HTML
and JavaScript.
Marco like just leaned into the HTML
JSX obviously into JavaScript.
I think a lot of people
might think like oh
but JavaScript is more powerful.
So you should just like lean into the
JavaScript side of things.
And that like I've seen a lot of people
be like well
is this kind of like
view or angular
or whatever
where you have this kind of
DSL and HTML
that in some ways
is kind of like hobbled
and you don't really know what's
what you can do
or what the limitations are
and it's like just a totally
different language.
But Marco isn't so much that.
Marco instead of trying to like
take HTML
and like use HTML syntax
to mean different things.
Marco actually extends HTML
with new syntax.
So it's like very clear.
Oh, this is a Marco feature.
Like oh, this is how a variable is introduced.
Whereas if you look at something like
view,
you know,
it's like an if statement is v dash if
like it just looks like an attribute
and you can't tell the difference
between a JavaScript expression
and a string
as far as like
syntactically looking at the template.
So I like to think of Marco
in terms of
view is to JSDock
as Marco is to TypeScript.
Like view,
you're kind of going in and
sort of annotating HTML
and spelt to a certain extent
is that way as well.
Whereas Marco is like
well what would it look like
if we actually added reactivity
and variables
and all these things
to the HTML language.

And we add imports to the language.
Like
there's no
you don't have to like
create a script tag.
You just do a JavaScript import
at the top of the file
or wherever you want really.
And it just kind of works.
Right.
Like we've extended
the HTML language
with new syntax,
which
you know,
is kind of nice
in terms of
the DX.
Like you're not having to
like it looks like
you're writing JavaScript.
It looks like this thing
that was cohesively built together.
But it's also nice in terms of
okay,
we've defined what this syntax means
which means we can optimize it
however we like
as long as we
you know,
keep that contract
or whatever.
Versus like
you know,
if you've got a hook
the reason there's
hook rules
is because
JavaScript executes
from top to bottom.
Right.
And that's just like
you expect the JavaScript
to roughly execute
from top to bottom
and I'm sure you can do throws
and all that stuff.
But like at the end of the day
you're going to execute that thing
from top to bottom.
But with the variables
that are introduced
in Marco templates
because we have a different
like syntax,
it feels less weird
that maybe these ones
are reactive
and fine grained
and like all that sort of stuff.
But your JavaScript
we still leave alone.
So your JavaScript
runs from top to bottom.
So yeah,
Marco is a
probably
the
one of the most like
how can we
augment html
rather than like
just add annotation
stage to mel.

Another framework
that I've
kind of drawn inspiration from
not that Marco
has necessarily drawn
inspiration from
but that I think is
like in the same vein
if you've ever seen imba.
So imba is like
you know,
another framework
mostly client side oriented
like it doesn't really have
you know,
any of the things
that I would look for
in a framework.
But as far as like
their language design,
they're like,
okay, well,
let's just create
like a concise mode
html
thing that is just
an entirely different language
that is specific
for building UIs.
See Marco is
like that
except
anytime we add
new syntax
to the language
we want it to either
look like
JavaScript syntax
or html syntax
like at least in like
the same
like syntactic category
like it should look
similar.
So like the imports
like why would we have
custom imports
it's just
JavaScript imports
defining html
obviously it's just
you write out your html
the attributes
like yeah,
the values are JavaScript
but you're already
familiar with JavaScript.
Like we have
shorthands for methods
but they borrow from
the JavaScript method
shorthands
like basically
we're just trying to merge
the two syntaxes together
in a cohesive way
without like abusing
and either of the syntaxes
if that makes sense.
So that's Marco
from a language perspective
which is honestly
the thing that I think
people are least interested in
because it's like
oh,
this is a thing
that I just like
have to learn
and it's like different
from JSX
and like what about tooling
and all that stuff.
I think it's super nice
obviously in my bias opinion
to write in
and I think
you know we've made a lot of
in hindsight
good decisions
in the language
but I think the main thing
that
as far as people
like looking at Marco
they would more care about
what is
what is its performance
characteristics
and all that stuff
but I do think that
like once you try
the Marco language
especially around
composability
and all that stuff
like wow,
this is
you know actually
super nice to write
like if you go to
component part
I don't know if you guys
have seen component party
it's just a site
that compares
like
you know
the same quote
unquote code
across all different
frameworks
or whatever
and you'll go and see
that the Marco examples
are basically
always the shortest
and not in a way
that's like superficially
like oh,
we cheated on some syntax here
it's like
no,
these examples
are just easier
to represent in Marco
because there isn't
the boilerplate
yeah,
so anyways
that's Marco as a language
yeah,
I was going through
the docs before this
and one thing
que j'ai étendu
c'est que vous avez
cette
tag id
qui est
comme réaction
équivalente
à
utiliser id
et ajouter
une id
dans votre exemple
c'est que vous avez
juste ajouté
une ligne
à la place
dans le marquard
et vous êtes terminé
en réaction
si vous voulez
faire la même chose
vous devez
de vous
poursuivre
ce que vous vous
vous en mettre
dans un component
et vous vous en faites
tout ça
comme vous l'avez dit
boilerplate
et vous vous en vous
vous en vous en vous
pour avoir
cette ligne de code
là-bas
ouais et je pense que
si
si votre audience
a vu
comme
Dan's original
talk
sur l'introduction
de réaction
de hooks
c'est comme
le bénéfice
de ce
est clair
si vous regardez
comme
comment le code
doit-on

pour
en order
pour refactor
cette classe
réaction
component exemple
vers ce
réaction
réaction
component exemple
et vous savez
les hooks sont
vraiment
bonnes
comparé
aux classes
en termes
de
pouvoir
collocer
la
cycle
méthodes
et ce genre
comme ça
mais les hooks
ne vous

vous
colloclocat
laite
ou
rendant
fonctionnalité
avec
le hook itself
où
c'est marco
avec
on ne
n'a pas de restriction
que
n'aie pas
peut introduire
variables
et
render
contenu
et tout ça
donc
et c'est
vous savez
tout le tria
alors vous pouvez
avoir un
si
statement
en marco
et conceptuellement
juste mettre un hook
dans
le si
statement
et ce
que le
state est
juste initialisé
quand
le si
statement est active
et c'est
déçu
quand
ou
la
clean up
quand
le
si
est
clean up
et donc c'est
très facile
pour faire
où
tout le
template
style
behavior
tout est
collocé
et peut être
très facile
comme
le top
le bas
le snipe
en un autre
component
et donc
refacteurant
marco
est aussi
beaucoup plus
plus facile
que
dans
jsx
pour les mêmes
raisons
que comme
vous savez
les hooks
font
beaucoup plus
plus facile
et nous
juste
nous le
plus plus
plus tout est composable
comme je vous l'ai dit
vous pouvez
construire
votre si
statement
vous pouvez
construire
votre
state tag
qui est
vous savez
évidemment vous pouvez
construire
votre
comme
vous
vous
vous
réacte
mais
vous pouvez
oui
c'est
très
beaucoup
à
chaque
state tag
et marco
vous pouvez
construire
vous-même
vous vous
vous
vous
vous
vous
vous
vous
vous
vous
vous
vous
vous



ce type de
des
mais peut-être
peut-être
je veux avoir
comme
un
type de
type de
ou quelque chose
c'est comme
ok
je vais juste
tomber
mon
type de
type de
ici avec
un
type de
type de
et on est
fait
bien
c'est très facile
de faire
ces
types de
factor
et de
la compétition
d'express
comme
comment
de loin
de marco
c'est
pour
comment
de longs
donc
en parlant
de
un
sort de
la progression
de marco
on va
on va
parler un peu
un peu
sur
v6
parce que
c'est
un
un grand deal
donc
ce
ce qui est
différent
ce qui est
nouveau
ce qui est changé
oui
donc je veux dire
que
il y a deux grands
choses
dans v6
et v6
a été
en progrès
pour six ans
comme je l'ai dit
c'est un grand effort
et
vraiment
c'est comme
comment on peut bouger
plus
vraiment
le reste de la
chose
dans la langue
et aussi
comment on peut le faire
c'est que
les déops
que vous
traditionnellement
vous voyez
par
l'architecture
n'est pas
une chose
qu'on n'a pas de
pensée
de plus
ce sont les deux
vrais goals
de marco
six
donc
par la langue
qui va
je veux dire
on a été
en tant que
en parlant
l'API des tags
qui est
la nouvelle
chose
dans marco
six
dans marco
cinq
le moyen que vous introduisiez
le state
et
l'expo
est
par un classe
donc c'est comme
comme
le réact
classe
vers
l'API des hooks
donc
donc
marco six
tient
le
genre
de
des hooks
comme
l'API
d'exeptes
que c'est
comme
la

et
plus
facile
de refactor
et
vous savez
ce genre de choses
c'est
ce qu'est
juste comme
le
dx
autour
les tags
l'API
en bringing
plus
dans la langue
mais
le
autre
goal
de ça
par
juste
dx
est
comment on peut
optimiser
les
plus
donc
le main
déopte
que vous voyez
dans les frameworks
d'islandes
donc
si vous regardez
le fresh ou le astro
ou tout
c'est comme
mais où est l'islande
et comme
est-ce que je suis créé
une islande mega
parce que
avec une islande
chaque component
qui est utilisé
dans l'islande
est une partie de l'islande
comme il se fait
bundler
il se fait
faire
et
tout ça
où il y a
évidemment le
goal
est de
faire juste
le JavaScript
qui est
nécessaire
pour
quoi que soit l'interact
que vous avez
comme si c'est
le regard
ou comme
quoi que soit
et donc
marco
comme vraiment
de marco 1
jusqu'à marco 5
il y a été
une islande
base
fréquence
et
c'est très facile
d'être en islande
avec marco
comme vous allez
et vous ajoutez
des comportements de client
et ça devient l'islande
au moins
il y a déjà
une islande
que c'est
consommé
dans l'islande

et tout ça
mais
vous regardez
comme astro
vous avez
de l'asthro
de l'islande
et vous avez
de l'asthro

vous avez
de l'islande

de l'islande
ou de l'islande
ou tout
c'est comme
en écrire
deux différents
technologies de rendition
donc si vous voulez
partager des choses
entre les
templates
c'est comme
comme bizarre
comme vous ne pouvez pas
vraiment
faire ça
ou vous avez
quelque chose
comme
fresh
où c'est comme
vous avez
l'islande
et ces sont les isles
donc vous devriez
penser à ce que
ces isles
vont être
mais maintenant
ce que vous voulez
ajouter un peu
au-dessus
de
comme votre page
ou est-ce que
la page
doit devenir
une islande
et donc c'est
où les diopnes
sont venus
jouer
et en fait
marco
c'est sort de
plus facile
pour les diopnes
parce que c'est
facile de créer
les isles
vous pouvez juste
mettre un class
et ajouter
des comportements clientiles
et maintenant
ce n'est pas une isle
de toute façon
donc
le moyen que vous
traditionnellement
vous avez
de la solution
est que vous pourrez
changer votre state
en bas dans la pétale
donc vous utilisez
comme une transclosure
ou plus de components
ou quelque chose
pour changer le state
en bas dans la pétale
pour que votre page
soit encore plus
de service
et que vos isles
sont relativement
petits
mais c'est
quelque chose que vous
avez à penser
et quelque chose
que vous avez à penser
en ce moment
c'est quelque chose
c'est un
point de vue
de l'inquiétude
et de l'inquiétude
et de l'inquiétude
et de l'inquiétude
et de l'inquiétude


et de l'inquiétude
et de l'inquiétude











et de l'inquiétude
Instead, Marcos 6
regarde votre state
et vos événements
et donc il regarde
l'équivalent de
un state de utilisation
et dit
OK
comment
où est-ce que ce state de utilisation
propagandise
par l'application
?
On va juste envoyer
la code pour ça
et donc ce que Marcos
fait
est qu'à la place où
le state
est basé
dans les fréquences
vous créez un state
et puis autres places
vous référent
et c'est comme
comment vous l'avez écrit
dans Marcos
mais dans Marcos
la compétition est comme
que vous l'avez écrit
le state
et il se follow
ce changement
dans l'équivalent
de l'équivalent
et il plume
dans ce changement
donc quand le state s'éteint
c'est comme
je sais que je dois
aller y aller
en éteint cette classe
je sais que
je dois y aller
en éteint
cette condition
je sais que je dois
y aller
en éteint cette texte
mais c'est bien grand
et donc ce que ça veut dire
c'est que vous pouvez ajouter
un state
à la place de votre application
que ça va
et que
ça va passer
par un million de components
et ça va finalement
faire une classe
et tout ce que vous allez avoir
dans votre bundle de JavaScript
est une code
qui
updates le state
et directement
updates la classe
donc vous pouvez penser
de la façon similaire
à
comme solid
ou quelque chose comme ça
où vous avez
des signes
vous savez
évidemment en solid
vous avez un state
que vous définissez
potentiellement
sur le top
et vous pouvez plumer
ce signal
par un million de components
et finalement
quand c'est
registré
ou comme
consommé
dans une
computation
ou quelque chose comme ça
c'est où ça va le lire
et
qu'une change de signal
va profiter directement
dans
en marco 6
c'est essentiellement
le même chose
d'exception
à la temps de compilation
et le bénéfice
est
qu'on a
essentiellement
une code
qui dit
que ce state
directement
va
et updates
ces choses
donc on va
tricher tout autre
et c'est
ce que vous allez
arriver
avec
essentiellement
pas de JavaScript
donc on a
notre
comme je ne l'ai pas
probablement vu
comme des exemples
et
comme tout ça
des clons de hauteur
c'est
comme un sort de facto
comme
comment vous envoyez
un JavaScript
comme
comme un sort de benchmark
ou quelque chose
et
donc
dans le
exemple marco 6
c'est
maintenant
comme 200
bytes
de code user
comme dans le template compilé
pour
donner la fonctionnalité
qui est requise
pour le seul
interactive page
dans cette expérience
vers les
comme les fréquences
vous le sentez
le tout
comme
le component
ou quelque chose comme ça
donc vous êtes probablement
regardé
vous savez
plusieurs 100 bytes
ou quelques kb
ou quelque chose
ou si vous n'êtes pas
un framework d'islandres
vous allez regarder
l'app
qui devrait être
vous savez
plus de kilobytes
plus vous avez
le
format de runtime
qui
dans marco 6
est
aussi très petit
et donc c'est
notre goal
vous n'avez pas de
penser
à
comme
où est-ce que l'islandre
vous
vous utilisez
votre state
et marco figure
comment
et
comme
ce qui doit être
envoyé
pour le browser
pour faire ça
donc le
autre piece
de ça
qui est
comme un tout
tout
ce qui est
comme un tout
ils vont
aller ensemble
c'est la résumabilité
ce que vous avez
probablement entendu
referé
par
comme
de
et
ils
vous savez
on travaille
sur
c'est
comme
mais
basiquement
dans marco 6
c'est aussi
résumable
parce qu'il y a vraiment
deux issues
quand il s'agit
de
initialiser
ou hydrer
la code
qui
fait le browser
c'est
comme
vous avez
combien
ça fait
d'actuellement
faire
ce code
et initialiser
et pour les
fréquences
ça signifie
renseigne
tout
c'est
vous savez
tout le monde
dit
hydration
c'est
juste attaché
les handlers
et les effets
ou quelque chose
mais en pratique
chaque
comme les fréquences
vont être
faire un remettage
en bas
matcher
ceci
contre le don
et puis
renseigner
les effets
et les handlers
donc
et vous savez
en marco 5
c'est l'islande
donc ça
fait
un peu de
ceci sur le server
mais l'islande
en itself
est encore
en marco 5
de vdm
et ça
va
remettre
et vous savez
attaché
les handlers
et matcher
ceci
de cette façon
et ça
ça peut être
lent
et donc
en marco 6
on a
ça
ça
parce que
parce que
on a
cette whole
traité
basé sur la règle
et le state
propagandise
tout ça
et on le sait
comme les dépenances
de tout
parce que c'est
tout représenté
dans les templates
marco 6
va
en fait
le server render
et dire
Hey client
ici sont les effets
que vous avez besoin
et ici est le
les handlers
que vous avez besoin
d'attaché
et ici est le state
qui était
référé
par ceux des handlers
pour que ça
peut
continuer
de où le server
est
donc basé
la hydration
en marco
est
juste
ou en marco 6
c'est
juste attaché
les handlers
et les effets
donc ça
comme
la partie de la règle
est vraiment petite
mais puis avec
la
comme la
réchauffe
que j'avais mentionné
ça aussi
signifie que les bundles
sont
vous savez
incroyablement
petit
et donc
oui
et aussi
comme
juste comme
une partie de la performance
parce que nous avons
compilé votre programme
pour
essentiellement
ce que ce serait
si vous avez
manuellement
évoqué
les signes
comme le state
sait exactement
comment
d'aller
en dépassant
tout les dépenances
c'est aussi
très fast
comme juste
juste
le client
rendant la performance
c'est très fast
c'est super fast
sur le service
pour les mêmes raisons
tu sais
Marco 5 est fast
sur le service
super fast
sur le client
mais puis
probablement
le plus fast
framer
en termes
de
hydration
et
bundles
de l'esprit
maintenant
donc c'est ce que Marco 6
est en train de faire
c'est
c'est fasciné
il y a
il y a beaucoup
de
un
il s'est senti
comme il y a beaucoup
de compilations
complexité
et un peu
de bundles
complexité
ici
oui
et donc
je pense que
comme
Marco a toujours
eu des bonnes
capacités


nous l'avons mentionné
plus tard
que
en original
vous avez
construit
votre
propre
bundles
ou
un pipeline
un truc
qui s'appelle
LASSO
un très customisé
tool
qui a beaucoup
de capacités
même de l'avant
et donc
je pense
que
comme vous l'avez
expérimé
ceci
j'ai été
pensé
comme
il y a des parallèles
et complexité
pour
réactes
des compagnons
un peu
de
juste comme
l'optimisation
perspective
et comme
comment vous
vous les préparer
ces choses
et les envoyer
dans les correctes
de la manière correcte
donc
qu'est-ce que le tooling
qui ressemble
aujourd'hui
pour
comme Marco 6
je veux dire
vous avez
des plugins
est-ce que c'est un pipeline
custom
qui se construit
comme
ce que ça
semble
utiliser
nous avons fait
ça
pour un while
plus tard
que les rscs
et ce n'est pas
donc ce qui est
quelque chose que nous avons
eu
à
vous
déjà
sorti
pour adresser
ce qui est pourquoi
je dis que
le compiler marco
est plus
plus
plus
que un bundler
que
que
quelque chose comme
un sphéleau ou quoi
donc on a
eu
cette layer de abstraction
devant
ce que le compiler marco
nous fait
plus facile pour nous
pour construire ces
integrations
dans des différents
bundlers
ce qui est
comment nous pouvons
bouger
de l'assaut
dans le premier place
parce que l'assaut
c'est
comme
je veux dire
vous pouvez
utiliser
pour quelque chose
que vous ne
utilisez pas marco
ou quelque chose
mais c'est
une chose qui est
pour marco
et donc
oui
pour répondre
à la question
en termes
de bundler
integration
on
on a
ce qui est
donc nous avons
des integrations
pour
vous savez
un
la
v
v
s
bill
web
pack
évidemment
l'assaut
et il y a
même un browser
5
1
mais la
chose principale
est que
comme
la manière dont nous avons
les choses
à
cet point
c'est relativement
facile pour nous
pour nous
d'adresser
ces
après
le facte
comme
on a
ce part
c'est
un petit
pote
le
autre piece
c'est
comme
comment vous
integrer
avec
les typescripts
et ce genre
et ça a été
un grand
challenge
pour sure
comme pendant
marco 6
développement
c'est
quand nous avons
les typescripts
et ce qui était
la
Campaign
des

la
Sh
les
iat

passer
cette
Dorothy
ferment
^^
les éléments, ils savent leur type déjà.
Donc, si tu fais un div et tu veux avoir un référence à la div,
tu n'as pas à faire le type de développement HTML.
C'est juste que tu sais que c'est un développement HTML.
Donc, il y a des choses comme ça que nous pouvons improving.
Mais oui, c'est beaucoup de travail pour nous de maintenir ces intégrations.
Et on est en train de être cognizant de ça, comme quand on fait quelque chose
qui est contre le Grand, c'est spécifique à Marco.
C'est comme, comment on peut abstracter ça en un moyen
que ça va faire mieux pour nous de l'intégrer avec d'autres outils dans la ligne?
Oui, la intégration type, en particulier, est à mon avis.
Parce que l'un des choses qui m'a toujours abonné
quand je fais de l'intérêt pour les sites, c'est que la intégration type est géniale.
Je peux utiliser des components réactifs qui sont en type script
et je n'ai pas de manière à le tester.
Donc, en pratique, comment on peut construire une intégration type type
pour votre travail de langue custom?
Parce que tu n'es probablement pas en utilisant le TSC directement, hein?
Oui, je sais.
Donc, nous avons un rappeur sur le TSC,
pardon, il s'appelle MTC, le micro type check.
Et donc, le type script ne donne pas de bonnes boules
pour construire les langues custom.
Donc, chaque frameworks qui ajoutent une nouvelle langue
pour le type script sont essentiellement hacks sur hacks sur hacks.
Et c'est le cas pour Views, Felt et aussi nous.
Donc, généralement, la façon dont ça fonctionne
c'est que tu boules dans le type script compiler,
ou dans le CLI ou dans le service language qui s'occupe de la code.
Et tu dis, hey, ceci, ce file ici,
tu peux résolver ça de cette façon.
Et aussi, c'est un file type script.
Et donc, on fait ce qu'on fait,
c'est qu'on prend votre template marco,
en fait, nous avons un bon DSL
qui est capable de transmettre à beaucoup de choses différentes.
Donc, on prend cette template et on compile ça pour le type script.
Pas que ça soit le roulant,
mais que ça soit capable de être type check
dans le moyen que tu veux.
Et donc, on a fait le code type script,
et pour l'éditeur, on source-map le code de votre original.
C'est généralement comment ça fonctionne,
et c'est comme la plupart des tools sortent de l'intégrer.
C'est un grand pain,
c'est très hacky,
j'ai hâte de voir comment les tools réagissent
à la version de type script de la nouvelle version GO.
Mais, à moins, nous ne sommes pas en train de se faire,
comme nous avons vu, et Felt,
et Astro, aussi,
on doit faire ce genre de choses.
Donc, avant, c'est pourquoi je disais
que les frameworks adoptent les choses que nous voulons,
comme les îles, ou les streamings, ou tout ça,
et aussi le type script, en ce cas,
sont super bénéficiaires pour nous,
juste parce que c'est comme,
oh, quelqu'un d'autre a fait ça,
on n'est pas en train de le construire de scratch.
Donc, oui,
type script est une bonne chose, pour sûr.
Oui, je suis heureux d'investir dans ça.
C'est l'un des plus grands challenges, je pense,
quand il s'agit de les langues template.
Les langues base, c'est...
C'est ça, je veux dire,
tu n'as pas de la possibilité de construire beaucoup de customise.
Donc,
j'ai vu,
tu as fait du travail sur le service langage pour Marco,
c'est ce que l'expérience a été?
Oui, donc,
le service langage est,
c'est plutôt bien,
pour pouvoir travailler sur,
c'est relativement simple,
comparé à les autres choses que nous essayons de faire,
mais,
aussi, Marco, comme langage,
c'est constrainé,
qui fait que c'est plus facile de faire,
certainement, l'intelligence,
et tout ce genre de choses,
et les conflits.
On a un compiler en face de ça,
donc,
ce n'est pas un stretch de prendre un compiler,
et c'est AST,
et CST,
et plomber ça en existence.
Donc, on a un peu de la main,
ce qui est quelque chose qui est probablement un challenge,
pour, je sais,
solid et tout comme ça.
Si tu voulais changer le sens de JSEX,
tu ne peux pas.
C'est toujours un travail,
le show tag et solid
sont toujours les constraintes,
en termes de types,
et des choses que ça a,
pour le moment,
parce que tu ne peux pas changer le JSEX,
tu n'en as pas,
mais,
on a bien sûr,
on a le langage,
donc,
si,
on a considéré ça,
mais si,

si,
si,
si,
si,







si,
si,
si,
si,

si,
si,


si,
si,



si,

si,
si,

si,




si,
si,

si,
si,
si,











Donc, quand je dis que le 6 de Marcos a commencé six ans plus tard,
c'est-à-dire que six ans plus tard, c'était peut-être la première ligne de code
pour ce qu'il serait dans le base de code de Marcos 6, ou quelque chose.
Mais c'est plus sur lesquels on sait que les députés d'Islands sont super amusantes.
On sait qu'on veut une plus composable langue en termes de boules et tout ça.
Qu'est-ce qu'on va faire pour y arriver?
Il y avait un bon peu d'exploration qui a été placée.
On n'était pas nécessairement allé de la place de VDOM pour les signes.
On pensait que nous pouvions avoir un truc de la base de VDOM.
C'est très difficile quand on n'a pas de constraints.
On est en langue, on est en temps de rent, et on peut faire tout ce qu'on veut.
Le but est d'y mettre en place un petit code possible.
Et aussi, le but est de faire que le code que vous avez écrit soit le plus beau possible.
C'est un grand but.
C'est un grand nombre d'exploration qui a été placé.
Qu'est-ce qu'il faut pour ce API?
Quels constraints devraient être nécessaires pour faire surement que ce code n'est pas fondé?
Mais aussi, on n'était pas nécessairement en temps de travail sur Marcos 6
pour les années de l'année passée.
On a été construit un peu d'autres choses,
supportant les équipes de l'EBay,
et tout ça.
On a construit une integration type,
mais c'est quelque chose qui a été dans la tête de nos minds
dans une forme ronde pour 6 ans.
Je dirais que le développement réel de Marcos 6
était comme le plus grand,
que nous savions que nous serions construits.
Et il y a moins de détenus,
c'était probablement 3 ans de développement.
C'est encore une longue période.
Mais au bout du jour,
à l'EBay,
la performance s'intéresse.
C'est très facile de déopter,
si on peut en faire ça,
ça va être une grande victoire.
Mais au-dessus de ça,
il y a aussi beaucoup d'expériences microfrontes
qui sont construites,
je ne parle pas beaucoup d'ici,
mais avec la microfront,
il y a deux options.
Il y a either share code,
je pense qu'il y a 3 options.
Vous n'avez rien,
et vous avez un peu de duplication,
et c'est une expérience très solide.
Ou vous avez share code entre la microfronte
et l'application embedite.
Si vous avez share code,
vous êtes défeuilleuse
pour la microfronte,
vous avez une expérience très solide.
Vous voulez vraiment évoquer la share code.
Mais le but est de faire 2
petites expériences.
Vous n'avez pas de risques
pour la share code,
l'orchestration,
les résilience et tout.
Marco6 est très bien
dans cette expérience embedite,
ces solutions microfrontes.
Vous pouvez dire que vous voulez
mettre en place
une globale header,
c'est ce qu'on appelle.
La header est une microfronte.
On ne veut pas la header
pour l'impact de la
expérience de l'application.
On veut avoir une expérience
comme petite,
donc ça veut dire
une expérience très petite.
Mais ça veut dire
que si la header est en train de
utiliser les islands,
vous devez vraiment penser à la
élan, vous voulez vendre un minimum
de JavaScript pour la header.
Mais en Marco6, vous vous
vous dites que le DX est bon,
et ça se passe
comme 3KB.
C'est assez petit que ça se passe
dans nos budgets.
La header est une chose
intéressante,
parce que vous voulez avoir
la première flèche
dans 20 kilobytes,
et si la header
s'est faite,
la page
s'est faite pour le reste de ça.

ces microfrontes
sont vraiment...
Marco6 s'appuient
aussi en général.
On veut avoir des expériences
très rapides et petites,
et c'est le but.
Qu'est-ce que le Marco6
fait pour l'opération?
Si vous êtes tentant de faire un
produit en Marco,
est-ce que
vous avez besoin d'un serveur

de la set-up,
de la run en Marco app?
On a un nouveau métaframe
qui s'appelle Marco Run.
Il est arrivé l'année dernière.
Il est
similaire
à la sphelt kit,
ou à la Nuxt,
ou autre chose.
Il a le concept d'adaptor,
donc vous pouvez
créer un adapter qui dit
que c'est la façon de changer
la compilation et la runtime.
Nous avons des adapters pour Netlify,
un adapter statique
pour construire sites statiques,
ou le mode de base de base
pour les adapters.
C'est facile de déployer
ce point.
Traditionally, Marco est
un app de base.
C'est ce qu'il y a,
mais il y a aussi
des benefits de la
service rendu.
Mais c'est aussi bien
pour les sites statiques,
parce que le site statique
est une page de service rendu
que vous avez emplissée.
Si vous utilisez Marco,
vous avez tous les mêmes
benefits en termes de violence.
Vous avez le JavaScript
nécessaire pour cette page.
Pour commencer
avec Marco,
je vais probablement commencer
par le micro-run
de la metaframe.
Nous faisons
un overhaul
pour un site doc
pour Marco.
Si vous allez au site
de Marco,
il y a encore
5 docs,
mais il y a un banner
qui dit que Marco 6 est ici.
Vous pouvez le voir
sur le site Marco 6,
qui est encore un travail en progrès.
Il y a encore des bugs pour vous
voir.
C'est l'un des choses que nous
essayons de faire,
de faire un documentation
dans un bon endroit,
et de commencer par parler
d'un documentation dans un bon endroit.
Nous pensons que c'est utile
pour les gens, pas seulement à l'EBay.
Comme nous l'avons appris,
nous aimons toujours
poser une question de future.
Je pense que c'est assez obvious
que vous avez
travaillé longtemps pour
mettre le V6 à la porte.
Je suis vraiment excité
de vous dépasser.
Qu'est-ce qui se passe
sur le horizon ?
Est-ce que
Marco veut se solider
ou est-ce que ça se stabilise
et que le système économique est bon ?
Oui,
les prochains
quelques mois sont en train de
stabiliser et de fixer les bugs
et de faire surement que des députés sont adressés
et des choses comme ça, de la porte
et tout. Mais en plus long terme,
nous avons une vision
plus grande pour Marco.
Donc, évidemment,
pour la date,
vous utilisez Marco si vous pouvez
utiliser un app multi-page.
Si vous pouvez utiliser Astro
ou si vous pouvez utiliser Fresh,
vous pouvez utiliser Marco et ça serait
mieux.
Mais, évidemment, il y a un
bunch d'applications qui font
sens pour être un app
comme pas tout est en forme de links
dans le browser, tout le monde.
Donc, le futur face,
nous avons un plan,
c'est tout ce qu'il y a
mais un plan pour
faire l'aise à
construire des expériences app
et c'est où la plus grande
exploration de la prochaine est, c'est
comment nous pouvons avoir ça, pour que vous
envoyez encore un JavaScript minimal
mais que vous puissiez avoir
une app single-page,
pour construire tout ce que la single-page app
puisse faire en keeping le service possible.
Donc, c'est assez similaire pour les components de

d'exception
sans tant d'inquiétude
et avec des considerations
qui devraient être
puissantes et tout,
pour pouvoir se faire
faire les choses comme ça,
à travers l'expérience entière.
C'est une des prochaines choses que nous allons travailler sur,
et des stratégies de la laison
pour la petite version de JavaScript
que vous avez encore sur la page.
Mais oui, donc,
à partir de maintenant, je pense que Marco est
au point où c'est le meilleur
framework de multi-page app
que vous pouvez utiliser en termes
de performance et, probablement, DX
et tout.
Et, vous savez, notre next goal est de
faire le meilleur framework que vous pouvez utiliser
en termes de les mêmes choses.
Bon, ça nous rapporte pour nos questions
cette semaine Dylan. Merci pour votre
commentaire, c'était un super intéressant épisode
sur les choses différentes qui vont à Marco.
C'est de l'avenir, mais aussi de la
précédente, donc c'est très intéressant
de voir où elle va, et merci pour la discussion.
Ouais, merci pour le chat avec moi, c'est bien.
Ouais, merci Dylan.
J'ai toujours été très intéressé à Marco
et vraiment excité à voir où elle va, donc
garde la bonne travail et on est
heureux de vous suivre.