Hey, everybody, welcome back to another episode of JavaScript Jabber. This week
on our panel, we have a j O'Neill Yo yo yo, coming at
you live from an eight hundred c C engine. Not really though, but
I am looking at getting a motorcycle, all right, Dan Shapiir Hi from
a warm and somewhat MUGGI tel Aviv Uh huh. I'm Charles max Wood from
Top End Devs. And yeah, this week we have two guests. We
have Satya. I don't see your last name, so my friend, you're
gonna have to tell us who you are. Hi, I'm Satia Gone.
I was just gonna say that you now. Honestly, Uh, Microsoft getting
Tatia is their CEO. It's the best thing that have that has happened to
me, right because I don't confounce my name at least in that our good
deal. We also have Joe Savona. Hey, nice to be great to
be here, Thanks for having us. So yeah, Joe, I went
and looked. I'm pretty sure we haven't had Satian before, but uh,
you were on in twenty fifteen we were talking about Relay and Graphuel, So
welcome back. It's been a while. Yeah, and last year for RC
yeah, yeah, you might need that one. Yeah. Yeah. We
spoke with with Dan Abramov and Joe together about you're right, it just doesn't
have your name in the title because it sucks the room exactly. It doesn't
have dance name in the title either, but that's we'll blame it on Dan
though. Yeah, he's not here. Yeah, all right, So we're
here to talk about the Reaction compiler, and there was a big announcement I
guess within the last week or so. I'm sorry, I'm in and this
time crunch where like time dilates, and so I don't know if it was
two weeks ago or two months ago, but I know it was recent.
So do you want to fill us in on what we're talking about today?
Just kind of set the stage and then we can dive into what it means.
Yeah, Sothia, do you want to As you take a sip of
water, I'll punt it to you. Sure. Yeah, we had React
cong a couple of weeks ago we announced the open sourcing of the React compiler,
which we've been working on for almost doing of yours three years at this
point, so it's been a it's been a while, and yeah, it's
open source, you can fry it. Today there's a bubble plug in that
you can pull on your apps. You'll React app and it gets automatically memoized.
You no longer have to think about use memo and used callback and React
out memo. Oh, the compiler hups remove the malmanimalization. And then there's
also an e slump plug in that helps you catch bugs. So when you
violate the rules of React, the plug in will help you, so you
can write bug free React code. Okay, I'm confused in what sense do
we mean? No, I really am. So, first of all,
I'm not I'm not a front in person. I do mostly server side.
Okay, So when I think of a compiler, I think of like either
compiler or transpiler. Transpiler the way that React currently works, where you do
an amalgamation of HTML and JavaScript and it compiles or transpiles to JavaScript, or
a compiler to something that produces bytecode or machine code. So when you say
compiler it it's at first it sounds like what you're just saying, like what
I already know about React. There's a thing that transpiles some code from one
thing to another. But then you're introducing it, which means that it's not
what I think it is. Yeah, before you guys answer, before you
guys answer, I actually have to interject and say that I got into a
little bit of trouble, I think with some members of your team when I
stated on X yeah that I don't actually consider it to be a compiler because
one, technically, I understand why you're why you're calling a compiler, because
it works like a compiler, and there's you know, a SDS and whatnot.
It's taking JavaScript and translate valid JavaScript and translating it into valid JavaScript,
so uh, you know, usually no, it's not about thees X.
It's about taking support and yeah obviously yeah obviously, and also typescript, I
guess. But but you know, at the most big sick level, it's
taking perfectly valid JavaScript and translating it into perfectly valid JavaScript, which doesn't sound
like what compilers are supposed to be doing. They're supposed to be taking stuff
in language X and trans and transforming it into language Y. So but then,
you know, people told me that I was nitpicking, which is,
you know, probably true because I'm a nitpicker. But be that as it
may. Now, I let you kind of answer a J's question, right,
So generally, like in the fund end ecosystem, there's there's been babble
which we used to do transformations on the estage, right, That's that's where
that's honestly how or like why the dumb transplanter became popular listen to jazz community
is the transformations using bubble. But I think I think in that aspect,
yes, the REAC compiler is a transpiler that is a source source transformation,
but the kind of analysis and the how the compiler, like the compiler actually
works is a more like a traditional compiler, like how we it would work,
which is why we call it the REAC compiler. We do lower it
to not just a st but the like very low level I R, and
then we compile that back to source just because we're want to ship that as
Chaska. So for the benefit of our listeners and myself. What what's I
R and then what's a STU? Right, So generally, in a in
a compiler pipeline, the source code is the first step of the compiler pipeline
is converting the source text, which is j syntax into abstracts and tax three
which is like three of nodes representing which has some semantic information about your input,
and you can do a lot of analysis transformations on this and it is
pretty powerful. But there are some limitations to this data structure because it's a
tree. And then generally compilers lower this to another data structure called intermediate reputation,
which is most generally a control flow graph, so it's more like a
graph rather than a tree of notes, so you can do more advanced optimizations
and analysis on this data structure. So what what's the nuance between tree and
graph? Because when I hear the two, normally they're synonymous. Mm hmm.
One is snick click, one is cyclic, and the other isn't.
Well, okay, yeah, tree, tree is directed. It kind of
goes one way. Ye, tree is a kind of a graph, like
every tree is a graph, but not that a graph is a tree,
right, got it right? So that REAC compiler does lower to this sort
of lower level i R, which is like a graph, which is which
is why we call it a compiler. So you can just add on Yeah,
go ahead, yeah, I would just add so I think you know,
well, first off, transpilers are a subset of compilers, right,
and in the ecosystem. If you look at if you go to babbelsme page,
they say you gotta you gotta, you gotta type script. They call
it a compiler, right, so so part so part of it. So
it's kind of two aspects. One the way it works is a compiler.
The other aspect is naming it in a way that developers actually understand what what
it is, which is, when you look around, similar types of things
are being are you know, in the JS ecosystem known as compilers, and
this is doing you know, some something similar, actually more sophisticated in a
lot of cases than what we've seen before. So I think, like really
to understand why we're calling it a compiler, it helps get into what it's
doing. Right, It's not just about the fact that we're lowing lower into
an IR and a control flowgraph, but it's really about like what is the
compiler doing what, Like, how does understand your code? What transformations is
it applying the right to help you have you know, right, nice clean
job, you know, react code like you're used to and get better performance
at the you know, on the output. I think once one's kind of
understand what it's doing in the full pipeline, then it becomes clear why we're
calling it a compiler. Yeah, I just I want to jump in here
real quick because it feels like, you know, you brought me this the
sweet sweet ride, and you're telling me what makes the pistons go up and
down? And what I care about is how it's going to get me down
the street so that I can go to the groceries. Exactly what matters is
not yeah, exactly. So so I'm going to ask why do I care?
Right? What does this do for me? That's a great question,
yes, Sathya. Well do you mean like the why we why we have
the compiler? Or yeah? Basically, so, you know, I'm writing
this awesome React app, you know, maybe I'm using next JS, or
maybe I'm just you know, hey, look, I do rails, right,
So maybe I have an API and I'm just doing React off of the
API. But at the end of the day, how is it going to
make my app better? How is it going to make my life easier,
How is it going to make my user's life easier? Or does it not
do any of those things? But I care about it for a completely unrelated
reason. Right, So what we've found out is reacting. Sometimes we do
reactive and that it can revender it more than necessary and to fix that and
revending too much can be a performance issue in certain cases. And to fix
that, React gives you APIs like use memo, just called back and React
with memo. But using that is a mental tax for developed because they have
to think about something other than building UIs right, like, you don't want
to be thinking about memorization. You want to be think about solving your user's
problem. So the compiler comes in automatically adds all of this to you to
your app. I like to say, and I would like to interject here
a little bit that First of all, I have to say that even the
term rerender was confusing, at least for me for a while, because you
can think about two levels of rendering or re rendering going on in the context
of React. One level is the generation of the virtual dome when you write,
when your code, the React code that you wrote as a React developer,
runs and builds the virtual dop. And then there is another rendering that
happens when React itself takes the virtual dome and transforms it into updates to the
actual browser dot Now from my perspective from almost day one, or essentially from
day one, you kind of solve the performance issue around the lower level rerendering.
That's what the virtual dome was created for, the whole reconciliation exactly.
You know, there are some interesting things going on with million js. I
know, for example, they're trying a different approach it might which might be
beneficial in some cases. But at the end of the day, it's solved
and very efficiently in most cases by React itself at that lower level. The
place where we still had the problem, turns out, was at the higher
level of creating the virtual dome. Because initially, when React was pitched to
us way back like almost a decade ago, essentially a decade ago, we
were kind of told that, hey, virtual dome is really cheap. It's
just JavaScript objects. You know, they're they're lightweight, there's little low effort
related to it. The browser is really good at managing JavaScript objects. Turns
out that in some cases you guys were lying, well, I'm gonna interject
there just because yeah, yeah, sorry, go for it. Yeah,
I think I think what what what has changed is that like the size and
complexity of applications. Yeah, so you're absolutely right, that like there's kind
of these like two levels of rendering happening. There's the like the JavaScript React
rendering, you know, calling component functions, right, and then the code
that they that they call, and then there's okay that creates a virtual domb,
and then there's React then doing the diffing of the virtual dumb. You're
right, So React has really solved that, you know, actually making the
minimum number of DOMB modifications. Right. That that's like always been like React
strength, But what's happened over time is pure building larger and larger applications with
this more and more product code, right that that that high level rendering,
and so that is where that the time is really coming from. So you
know, like I think the community focuses a lot on like you know,
kind of time spent in the framework, but what we see in practice is
that most time is spent in user code and in the product code. And
so where the React compiler is really helping is in making it so that we
only run the minimal set of product code that we need to when state changes,
right, and then that complements the lower level piece of only making the
necessary DWN modifications. Yeah, and again in this context. First of all,
I have to say that I love React, So you know, if
it comes across as if I'm being critical, it's it's criticism from love.
We appreciate, We appreciate good criticism. Yeah. Actually, yes, I've
been using React since twenty fourteen, so I'm really a long time React user.
I think some of the one of the first actually outside of Meta itself,
and so I'm really appreciative of that. And I was even teaching React
for a while, and when I was when I was teaching React, you
know, one of the strengths of React that that I was trying to convey
was that whole pure approach of transforming state into UI and that in an ideal
world, if it was possible, we would be re rendering everything from scratch
on every change just to make everything like you know, stateless as it were,
like as pure as possible state in UI out. But you know,
reality uh gets in a way and then and that's why we have all the
sophistication behind the reconciliation and the virtual dome to get to avoid the excessive dom
updates. And from my perspective, the React compiler is kind of like the
final step that the filling in the missing link in this process, because almost
from the beginning we've had to deal with all sorts of annoying things like should
component update and then you know, replaced by memo and use memo maybe I'm
forgetting something in the middle, And now ideally, hopefully we can finally forget
about these things. Hint, hint, React forget. That's we couldn't have
said it better. Yeah, so can you now? So the benefit really,
and that goes back to Chuck's question, I think, is the fact
that your app becomes potentially significantly more performant without you needing to change anything.
Yeah, exactly right. It's that it's that UI as a function of state.
That that's something that we've really seen that makes React so approachable to everyone
is that you write your app as if it is going to render. The
entire thing is going to render every single time, right, so that the
whole like as they mentioned it being like too reactive. It's like there's never
a point if, for example, if you kind of forget about use memo
independencies, right, just JSX is never going to forget to update, right
if you just write regular React code without any memoization, right, all the
all the values will correctly propagate into your app. So it's kind of fully
reactive by default, and it's really hard to kind of mess that up.
The only places that you can mess it up are when you start getting into
Okay, let me write it use memo. Oops, I forgot a dependency
and so now something doesn't update, right. So and so it's by having
the compiler do the memoization for you, we can make it that you keep
that same mental model of just writing simple you know, simple functions, pure
functions of mapping state to you why uh, and you get that same mental
model, but under the hood, only the minimal parts of the COULDE are
actually running that need to. So can I clarify a couple of things?
First of all, it's you know, I'm going to back way up and
then kind of come forward. But before I do that, the first thing
that I want to just highlight is you're telling me that basically, you put
a better engine in my car, and I don't have to do anything special
other than upgrade react in order to get the get the more horsepower. Right,
I don't have to turn anything on or jump through some hoops or you
know whatever. Right, Yep, that's the idea. And obviously it's still
experimental, so you know, like maybe maybe keep driving with the current engine
for right now, you know, give us try it out, give us
feedback. But yeah, the idea is that, right, that's that's what
we're going for. That's good to know because then I don't get frustrated by
the oh this it's not doing exactly what I expect. But the other the
other piece of it is is that you talked about kind of the two layers
of what dominipulation or compilation or whatever that the react already did to react to
changes. And it sounded like you were saying that you've optimized the one layer,
but because of the way that it's optimized, right, so you have
the this is the stuff that needs to go on the page, and then
this is how we're going to manipulate the virtual dom to get it on the
page. You optimize this layer with the you know, putting it on the
virtual dom or did I get that wrong? No, you got it reversed.
They got reversed from the get go. The mechanism that got the virtual
dome to the dome was highly optimal. It identified what changed in the virtual
dome right, and then updated only those things in the dome that actually needed
updating. And to be honest, that's the most expensive thing per update,
because the dome is expensive. But what was missing was the optimization to the
user land code that generated the virtual dom itself to you know, the higher
level. Okay, but but it trans because you've optimized I guess I had
one layer here in one layer. Because you optimize this layer, it translates
into better performance here because it doesn't have to do as much work. Yeah.
So, yeah, exactly, so we are so Reactors actually always had
an optimization that most developers don't take advantage of, which is that when we
when you you know, return you know, some js X from your from
your component, we compare you know, the basic idea of what react is
doing this that in order to find the minimal dom updates is reconciling. Okay,
you return this new JSX telling us what the UI should be. We're
going to compare it to the previous JSX what the u I was, and
we're going to figure out the difference. And so one of the you know,
built in optimizations there is that if the if it's the exact same JSX
element. At a particular point, we can say, ah, okay,
that entire subtree. You know, it doesn't have to change unless it had
its own like state updates or something. But we can just kind of skip
that subtree and look at the rest, right, And so what what the
compiler's doing is taking advantage of that and kind of finding all the bits of
the GSX that don't need to update. We're not passing a new prop to
that component. So we'll just reuse that entire JSX element, and now React
can actually skip diffing that element. So it's actually doing less it's like doing
less rendering work, but it's also then creating less work to do in the
diffing process as well. I'll get back to that because that's a really interesting
point that I hadn't thought about and hadn't considered. But I think, in
a sense, a lot of the optimization is actually based around mammoralization. I
think it might be worthwhile to spend a couple of minutes in explaining what mammoralization
actually is and what it means. Yep, yeah, yeah, I can
of it. I think the main problem that we're solving it memorization is davascript's
referential equality is if you create new objects and compy them, they're not equal
even if they have the same values in them. Only primitives can be compared.
That's that's the problem that breaks down with this theffing that Jege is stopped
about. So with memmorization we keep as long as the values don't sematically change,
like the values in them don't change, the objects are the same.
So basically you're saying, if if if I have a function, if I
have a function that's a pure function that to make it simple, it takes
a couple of parameters, does some computation, and returns the result. I
don't need to run this function again if the parameters haven't changed, because there's
a gara and that the result would be the same. And and by remembering
the previous result, not only am I avoiding the computation of running the function
again, I'm also gaining the value of referential equality because I'm using the exact
same output value reference, so I don't need to do a deep comparison on
the result. I can just look at the actual reference. So I benefit
twice, as it were, from from avoiding this recalculation. Yeah, and
there's a there's a cascading aspect to this, right, So if you imagine
that state changes, you know, so you update state and you change like
an account from zero to one, and then you put that count inside of
an array for some reason, right, And now every time you render that,
we're producing a new array. And now you use that array for some
other calculation, and so now you're you're looking at okay, right, so
you started with just a single number changing, Now you've that inside of an
object or an array. Maybe you then capture that inside of a function,
right to log that array. And so without memoization, what's kind of happening
again, like the default and react just every time we render, reproduce a
new new state, new array, new object, capturing that new new function
logging it. With memorization, the idea is to say, okay, if
the input didn't change, we're going to produce the same output. But now
if you kind of only do that at one step, it doesn't really help.
Right If you say, oh, like if the array didn't change,
don't produce the new function, Well, the array changes every time, so
that that didn't really help, right. The idea is that with memoization,
it needs to kind of be every single step of the way, or else
you get a cascade if you forget one step in that process. Now that
that will always produce a new result. Now the next stage that is trying
to memoize will say, oh, well, my input or ray changed.
What am I going to do? I guess I have to recalculate and reproduce
this function or something. And so then you get an entire subtree kind of
on necessarily updating. And so the idea is that with memoization, one way
to think about it is automatic memorization. Another way to think about it is
kind of tuning the amount of reactivity. What we're doing is making it so
that when values semantically change, we're updating, and otherwise we're not. We're
not updating. And so that's that's the thing that got Soathia is trying to
get with. Like, I think that the way you're getting it with referential
quality, right is referential equality is kind of a stand in for did this
meaningfully change, because that's the only kind of way we have to kind of
to check did it meaningfully change? Otherwise you actually got to do a full
diff of the object, and unfortunately, you can't diff functions in JavaScript,
So right, we're kind of just limited by the language there. So just
again to clarify to our listeners, So who might not be familiar with the
terminology. Let's say, you know, when you're looking at the primitive value
like number Boulian or even a string in JavaScript, you're just comparing it,
and JavaScript does it for you. So you know, seven is equal to
seven hello, and zequal to hold on. But when you've got a reference
to an object, there are two types of equality here. One is that
we've got two references to the exact same object, and the other is that
it's there are two objects, but they are equivalent. They have the same
values for all the properties. And again it might be is whether you go
through that object recursively or just one level down it. You know, the
problem obviously isn't that simple. So the easiest thing to do in JavaScript,
because that's built in, is referential equality, which means that both variables are
referencing the exact same object. Then you just use a comparison operator and it
works. But if you want a value comparison, you need to do some
sort of a deep comparison, like the low dash is equal. For those
of us who remember that. And it's expensive because it goes recursively through the
object and it has to safeguard against cyclic links and stuff like that. It's
not cheap. So what you're saying is, when I memoize, then I'm
guaranteed not only to get the result which is the same object in terms of
its values, I'm guaranteed to get the exact same object instance. Hence I
can use the very cheap referential equality that's built into JavaScript exactly. Yep.
Now, one more thing before we move on from there. Again, if
we go back to the existing primitives that are in React, we've got memo
and use memo. Can you briefly explain like what they are and the differences
between them, because I gather that the React compiler effectively replaces both. Yeah,
So react to memo is to wrap your component. It's so that when
as long as the props don't change, the component doesn't re render it.
The default be able to React is if your parent renders, then we re
render the child component even if the props don't change. So that's that's the
React of memo and use memo is if any of the dependencies of the use
memo change then we run a computation. Otherwise we use the cash value of
computation that the use memo is run. And I have to say that again,
as a long time React developer, I've encountered a lot of code where
somebody added use state to a top level component that for some you know,
you know, maybe let's say some button click or something, and then you
know that thing causes a rerender of the effectively the entire application for no good
reason. So the fix against that was to use well and ideally you might
well, you could do two things. You could either move that button into
its own subcomponent, which well, it's easy to do but sometimes felt like,
you know, unnecessary overhead on the developer. The other alternative was to
memorize all the subcomponents. But then people either memoize too much or too little,
and when they memorized too much, they showed the wrong things, and
when they memoized too little, then they you know, they didn't get the
performance benefits. And what I've seen, what I actually often see is that
in many applications, either they don't memorize anything and they often don't even realize
that they have a problem, because you know, it works it's kind of
slow, but it works, or they memorize everything and the whole application is
just a million calls to memo. Yep, that's that's exactly the type of
thing we've seen. And to be clear, like a lot of times for
especially for smaller applications, the fact that there aren't isn't a lot of memization
is fine. Like the amount of revendering that you're doing just can be fine.
We hear, we've actually it's funny like and then we hear a lot
about the places where people run into performance problems, but we don't hear about
the cases that are basically fine. And so you know, one of the
things that the React comp that was was interesting was just going on talking people
and people are saying, like, I love React. It's it's so fast,
you know, I never have performance problems. It's like, oh,
that's so nice to hear, but like you know that we're not content with
that, but it's still great to hear. Right, we want to make
we want to make every React app fast by default, but but yes,
like the need to do this kind of memization that that is like that is
overhead that we can solve, right that that's like that having to kind of
and the worst part is that if you add you know, you could go
through a lot of trouble to add memosation everywhere, but it's still easy to
miss one spot right and then like as I said, like that can then
cause a cascade because you missed one memoization. So that produces a new value,
and then that new value flows into the memoization you have, which then
says, oh about my input change, I have to recalculate, and then
that kind of causes a cascade. And so missing a single memoization right can
kind of defeat all your your optimizations. And that's very easy to have happen
when you're you know, changing the code over time. You had you were
passing one callback and you memoized it. Now somebody adds an extra callback and
they forget to memoize it, and oops, there you go, right,
So am I correct and understanding that? Essentially what the compiler does is it
goes through all of your code, find all the places where you should have
put memo or use memo, and then implicitly inserts them for you. Does
it also do other things or does it do something different? Or what it's
like automatic semi colon insertion except cooler right. Well, that that actually brings
up the point that I wanted to ask, is it seems like this is
the type of magic that we need. But why not put it in the
hands of the user, like you know, a linter. For me,
personally, I prefer explicit over implicit, and I prefer to work with like
with the fewest layers of abstraction, because you can't understand there's too much abstraction
in modern software. You know, Jonathan Blow and Casey Morty and all these
guys are talking about this stuff primagen et cetera. You know, like the
abstraction has become so great that just people just they have no idea what's going
on. But you know, we have a lot of great tools, But
what if we could just surface it at the user level where it is a
linter thing or like an auto formatter thing like automatic semicle insertion, like hey,
you should use memo here, or just like I hit save and then
boom, they use memo appears and I changed the code and I hit save
and boom, the use memo disappears because it's not relevant. Like, if
you've got that information, why not surface it to the developers so that they
can learn and grow and not be like pushed down behind more abstraction on something
that's already like they're crushing under the weight of it. I have my opinion
on that, but I'll let the guys answer first, if they have an
answer. Joe, I'm actually you just yeah, so I think there's a
Okay, I guess uh, I guess I disagree with the with the premise
somewhat that there's too much abstraction. You know, we don't what Yes,
that's not controversial, broke right, So when when you when you start your
next project, you write your own database, you were an operating system,
You implement your own programming language, you write your own text editor, you
write your own graphics engine. You do all those things before you can build
your next blog. Right, Like that was just last thing. I'm just
I know that you're I'm just like for the audience sake of like, like
there's clearly like a certain level of abstraction that's like that's kind of necessary.
So to me, it's really about the value of a particular abstraction, right,
Like, I definitely hear what you're saying, Like there are some abstractions
that don't pay their weight, right, and and in particular, I think
like the bane of our of like software to pulpers existence is like leaky abstractions
right where it's you're like, it almost works, but it doesn't always work.
And that's I think where those are things that kind of can be too
magical and debugging them. So go, ah, let me let me just
to your example, I want to add something clarifying vs code to JavaScript file
perfect like, this is a good abstraction. It's perfectly understandable that it's one
to one. It's a non leaky abstraction, right, okay, Microsoft word
to JavaScript. I mean like now you've got to deal with the smart quotes.
You got to do special pasting, like very bad abstraction, good for
a particular purpose, right, But like so there's a difference between saying oh,
like because the editor you can perfectly understand, there's no confusion about what
happens at vs code when you hit save, like the file you get it
like so, yes, there's a lot of abstraction there and it might take
fifteen minutes to load, but once it's loaded, you hit save, like
you get the thing that you expected and there's not like this burden of hotly
crap. How did this file end up here? Yeah, So so the
other aspect is then so then the question for me is like, is it
a leaky abstraction? Right? Is the abstraction sound? Can you rely on
it? Is there? Can you build up a clear mental model of what
the compiler's doing? And that's what we really exactly, So that's what we've
really focused the model. So the so there's a so there's kind of the
mental model aspect and then the pragmatic aspect of and we kind of have to
balance these two things. So on on the practical side, imagine that we
did, say a providal linter that would add memoization in our analysis we've seen
I don't I don't know if I can share the number. Uh. The
compiler adds a lot more memoization, Like it memoizes things that developers would never
in a million years of thought to memorize, right, like every single individual
JSX expression getting independently memoized and then attempting to be very smart about how it
groups those together, right, because they can figure out, oh, you're
just creating JSX and so like one of the things working in now is kind
of starting to reorder the instructions. We can say, oh, these these
three things all depend upon the same input. Let's recreate them together because you,
as a developer can't observe when that code runs, so it's more efficient
to group them together. Now that like rewriting that like, but that that
transformation might not be the most readable way to actually look at that code.
Right. So that's where on the practical side, you know, if we
were to do this, the things we'd be suggesting to you as like here
go you know, change your code to be like this. That might not
be readable, that might not be very editable. And so instead having letting
the developer not have to worry about that, not to mention, you know,
you go to edit your file and you're like, okay, do I
put can I is it safe to put this over here? Do I have
to put it inside the use memo? Where does this code go? It's
a lot easier to think about just writing your code the way it makes sense.
And j before before you interrupt again, based on my experience and and
and Joe was going exactly where I wanted to go. Is the fact that
memoization for me is a lot of line noise. Even if if the compiler
wasn't doing all the sophisticated things that Joe just described, even if it was
just adding relatively simple use memo and memo codes without moving the code all over
the place. All those memos and use memos don't really add anything to the
business logic. There are a lot of line noise, So if I can
ignore them, if I can remove them out of the code, the code
becomes clearer and more readable. Like I said, in the ideal world,
everything would be just uh stay in. They just sets out. You wouldn't
need to worry and think about all these optimizations. Like I don't have to
think about the reconciled. The reconciliation it happens for me. Likewise, I
don't want to need to think about themmalization now. Certainly, if when you
start moving code around and grouping things and changing the order of things, then
it's totally a new ballgame and you don't want to be working at at that
level. Yeah, well, yeah, I get that. It's I understand
now. It's a very lossy conversion. It is. It is more similar
to a traditional compiler. It is doing the fun roll loops. Yeah.
One thing that it comes to mind, just you know, from my background
with you know this or that, right, is that you know, you
wind up putting a lot of stuff in to your code that is the bookkeeping
stuff and is not the Hey, this section of code has this responsibility,
right, And if in my ideal world, if I'm looking at a class
or you know, a JavaScript function or something like that, or a JavaScript
file, the only things I want to see are actually the business of getting
done what I want to get done. And so to me, the appeal
of this is I don't have to think about the performance management or the memory
management or anything else because that's taken care of for me, and so I
can just focus on I have a component that displays this data, or I
have this business logic behind the scenes that when I get Jason from the server,
it surfaces it in this way because that's my job. My job shouldn't
be oh, I've got to go in and make sure that all the eyes
are dotted in the t easier crossed, because that's no fun anyway, And
to be perfectly honest, the computer probably can do it better. Yeah,
I think memory management is a good is a good analogy, right, like
we you know, writing something like C plus plus or or rust or see
like a lower level language where you have to like malik and free. Right,
Like, that's that's low level details. And there are cases you know
where that like that is critical for performance. And you know there's definitely use
cases for systems languages for sure, when we're writing you know, high level
application with UI logic, that really just starts to get in the way,
especially when we have these very you know, UIs are very dynamic, right,
like the lifetime of a value is it is very hard to think about
because you know, like, okay, that this thing is going to get
shown based on all this parent context, and when does it actually get should
get freed. It's way easier to just say, let let a garbage clutter
deal with that. And I think it's very similar with the with the memorization.
Now, now I have a question like a lot of as we said,
a lot of code bases already use memo and memo inside of them.
Now, ideally I would think that once I moved to React compiler, I
would literally go through all my code and just remove all of them. But
that's a chore, so obviously at least at the beginning. A lot of
code will have memo use memo inside of it. What do you do with
that? Do you just leave it there? Do you effectively remove it then
optimize Like ideally I would think that you would essentially remove it and then optimize
the resulting code. Yeah. We Yeah, that's exactly what we do.
We ignore the use memos, we optimize it as well, it doesn't exist.
But you also check that have we optimized it similar to what the user
has optimized it, like have or our dependency is different or is it less
fine grand than the user. If it doesn't match up, then we build
up. So we make sure we don't change anything and progress and we only
optimize and improve. So yeah, so it's actually once we are are the
experimental experimental phase, I think it'd be more safe to like remove the use
call back for the components that the compiler can safely compile. Oh yeah,
it also takes care of used callback. I forgot about that. Yeah,
yeah, so one of the things that Yeah, but part of one of
the things we kind of want to do during the experimental phase is is get
more you know, data from from you know. This is why we want
to we're starting the working group to get you know, get get more feedback
from users about Okay, where are you know are we is the commander generally
able to preserve existing memization? Are there? Like? Are there patterns where
that where the compiler isn't able to preserve that existing memorization? And we should
you know, tune the compiler to be smarter about those cases, right,
because our goal, our eventual goal is to get to where users don't have
to do manual memorization, hopefully at all, but definitely in the experimental phase,
we're probably not one hundred percent of the way there. Uh, and
so we kind of want to get feedback to kind of tune and and get
and get all the way to that point. Now you mentioned bailing out.
Can you elaborate a little bit about that behavior of the compiler? Sure?
Yeah. The so the combiner resumes that the code follows the rules of React,
right, Like, there are certain rules that we expect, like props
you communate, props you you must use the center function to update state.
Hey a j It's like the the what's it called the rules of Python and
go and and stuff like that. Python, the zen of Python Go proverbs
and of zig. So we know we have the Zenov of React. That's
that's good. I need to update my link of things with the zens because
I think I had What do I have for that? For React? There
is there are two the React was React React ration out. There are two
documents for React that I have in the in the list of the thing is
Now I just feel like going and meditating on my components for a while.
So what are the rules? I'm gonna jump us a little bit to the
side because I have to. You brought it up. What what are the
rules of React? I think the main one is keep components that we already
know, and all of the other rules like just fall out of that,
which is don't your props, don't update the state without the setter function,
don't. And then there are like sudden like implementation rules like don't call hooks
conditionally use have a US prefix for your hooks somewhere. That is, we
have a really read documentation page on all of the rules with examples. We
also have a yes limp plug in that will catch where you while it also
reacting point to the to the documentation. I think okay, So previously there
was thinking and React React design principles, and then there was a YouTube video
uh React Today and Tomorrow that were the kind of philosophical documents for React.
So I will try to find Wait, you've got rules of React published?
Yeah, yeah, I just posted the link to Facebook, YouTube and twitch.
I wish I wish X would do that, but it doesn't. But
it's for those that are watching live and are going on, Okay, how
do I find this or how do I go find the video? It's React
dot dev Slash reference Slash rules. Yeah, okay, yeah, I'm putting
I'm putting it in the list the bailouts. Right, So when the the
componer actually has validation to know and figure out if any of these rules are
being violated, and if it if they are being violated, then it doesn't
compile the component because it could incorrectly compile the component if you don't follow the
rules. So that's that's how we classify. We want to be safe and
we want to only optimize if we know it's correct. That's that's the idea
of beIN having bailouts. Yeah, that's the thing I really love. Sorry,
I apologize, Joe. That's just to have to say that That's the
thing I really love about React compiler and kind of like one of the big
differences if I'm comparing to other React technologies, like for example, reacts to
the components, is the fact that you took an approach of being like very
low resistance, hardly any resistance at all. Basically, you drop it in
your components are compatible with it, you just gain the better in a fit.
If they aren't, nothing bad happens. Again, Obviously, as you
said, it's experimental, but I'm saying once it's released that that's how it
should work. And that to me is just you know, it's just upside
and no downside. You don't need to re architect to change stuff. It's
you just gain immediate value. Yeah, And I think it's the it's more
than like yeah that that's been a really you know, pretty critical piece of
this project is we we don't want to have to change why people write React
code. We want to just have something that that works out, you know,
as much as possible out of the box. That has always been the
goal. You know that to be clear, there are some ways that you
know, you can you can violate the rules of reacting, ways that the
compiler doesn't detect. The canonical one is like put the violation behind a function,
call like write some rite some helper function that like flagrantly violates the rules,
and call that function. And you know, so for example, like
modify state inside of a helper function. We don't know that yet problem,
right, but like as as much as possible, right, we detect that.
You know, you're following the rules, and in general, if you're
if you're breaking the rules, you will often see that pop up as a
bug, right, Like you go to add use memo to something and all
of a sudden, it's not updating as you'd expect. Oh, it's because
you have you know, you have some bugs. So these are things that
you could have run into at any time that we're helping to detect. We're
also working on tooling to kind of there are some things that we can detect
statically. There are others that can only be detected at run time, and
so we're working on some tooling to help kind of at run time, right,
kind of like even even like almost like further than strict mode to help
figure out like, oh, you know, the inputs to this value didn't
change, but the output did change. Why is that, oh, looks
like you might have a bug and we can help to pinpoint. So we're
using these tools internally as we roll out the compiler, and we're hoping to
bring those to open source as well. But the other thing is, you
know, the you know, we call this React compiler for a reason,
and that it's it's not just about automimization. This is really you know,
it's it's really two features, right, It's right now it's automamization and the
linting, but it's also it's really a platform for understanding your code and being
able to change the way it runs, you know, what's happening at run
time, to be more optimal. So we're also looking at like, okay,
how what else can we do? What other APIs can we provide where
we can rely on the compiler, Like do we need a new API for
something or that could the compiler just do that automatically for you? Right?
So, for example, a lot of folks have asked about context selectors,
which the idea there being sometimes you only want to access a small piece of
context, and right now, whenever the context value changes, we have to
render every component that uses that context value. So for example, A common
case is like routing. Right, maybe the one query parameter changes, but
a particular component only cares about like the domain. The domain didn't change,
So why should we render the component that cares about domain when the domain didn't
change. And so a lot of people have asked for a context selector to
say, oh, let's help us target the updates to the components that where
their actual input data changed. Well, okay, we could provide an API
for that and de developers that have to adopt it remember to use it in
all the in all the right places. Or we could say, let's have
the compeler do that for you, right, and so the commander gives us
you know, I kind of it's a it's a powerful lever for making it
so that developers, you know, we can just optimize things out of the
box without developers having to think about it. So I think this kind of
builds on that, like, once you have this this solid foundation, we
can we can kind of level up from there. One thing that I would
love to have, I don't know if it's on your roadmap at all,
would be automatically generating the dependency map array for use effects. Yeah, this
is something we're thinking about actively, but it can be tricky. It's the
there are some valid use cases for not having all of the dependencies in the
area, right, So we're thinking of new APIs and yeah, in general,
we're thinking about it alternatively. If somebody, I think, these days
you have to explicitly specify a dependency at the very least an empty array.
Uh so maybe like in the scenario if no array is provided at all,
instead of treating it, you know, as a runtime bug, you would
transform it into the correct array as it were. You know, I don't
know just as well that that's back to the point I was trying to make
earlier, Right, there's no value to having the dependency empty array. Right,
Well, no it depend it's not there, then you would also assume
it and yeah, then the then you have less clutter in your coat.
Yes, yeah, So so basically I think this really gets let's get let's
get to the question of what water effects four and use effect as kind of
it. Dan wrote a great you know, a series of posts all on
the documentate on the react av doc site about you might not need an effect.
There's a lot of things that people reach for effects for that actually have
other solutions. So part of it is kind of identifying, okay, where
should you just not be using an effect at all. For example, sometimes
people will do an effect where they'll kind of look at the propy, they'll
keep some state, they'll look at the prop and if the prop changes,
they like reset. It's like, well, they're they're basically doing use memo,
but manually with a second render, like okay, just use use memo
there for example, or with with React compiler, you don't even need memo
to do anything at all. There are a couple of like you know,
really really good use cases for effects. One is kind of creating sort of
custom events like on mount right like use effect lets you do and sort of
on mount type of event. And another is synchronizing with synchronizing React state to
some external system. And so what we're looking at is kind of bund is
really understanding these these specific use cases where you really need an effect and then
crafting the I there. But you know, I think, what what's WHATSATIO
is getting at about? Yeah great, yeah, yeah you might not need
an effect. Is that if when you're when you're writing an effect, there's
there's really are like legitimate use cases for not listing all the dependencies. And
the problem today is that because you you know, what you'll do is you'll
you'll add the dependency you array, You'll list out a couple dependencies and then
I want to skip I want to skip that one. So you'll you'll do
an lint suppress you know, disabled rule tell tell tell the react leinner to
stop talking. The problem is now you you mentioned some other value and by
default we don't catch it. And so I think that's in case where we
need a better API to say no, I want to explicitly ignore this one
value, but other values should get automatically captured. So this is the kind
of stuff we're thinking through. It's like, we're definitely working on it because
we understand that we want to do better on effects. So two things about
that. First of all, when you disable the rule, you often disable
it. You usually disabled it for the entire line, which means that now
if you make other mistakes in that line, they actually won't get caught.
Exactly right. So that's the problem, right, Yeah, that's problem number
one. Problem number two is that if you're doing it, you're probably doing
it for the wrong reason. That is another yes, exactly right, but
there are there are legitimate use cases for doing that, and that's but that's
something that we really want to work on a crafted API for it, like
help developers really understand like did you did you mean to do this or did
you mean to do that other thing? Now, you were talking about the
fact that it's not just a compiler, it's also a linter, and whenever
you bail out, there are appropriate linter messages. Even I guess when you
don't bail out, you might provide informative linting messages. To me, that's
almost as valuable as the compiler itself. If I have like a React expert
watching over my shoulder making sure that I'm writing the code according to the rules,
that's that's a lot of benefit, especially for you know, smaller teams,
more junior developers, et cetera. Yep, absolutely, yeah, Well,
and I like the you may cause problems, Right, it's not just
a hey, this is you know we prefer two spaces instead of tabs,
right, it's hey, this this may actually surface bugs. Now, you
mentioned something while back at the beginning of our conversation which kind of picked my
interest, and I wasn't sure if I was understanding it correctly or not.
But there's an interesting potential for passing data as it were, implicitly from the
compiler from that static analysis that compiler does to the reconciler like kind of behind
the developers back, like is that something that you actually do or thinking about?
Is there any potential value in that? Or am I just overcomplicating things?
So can you can you describe a bit more about like what you mean
there? Well, theoretically you could create some sort of you know, associate
some uh, I don't know, some hidden property on to the object that
you create, and that tells the reconciler to behave somewhat differently in certain scenarios.
Yeah, so I think I think what we've we've kind of thought about
a couple of things in that general realm. One is that, well,
you know, we talked about how the comut auto memoizes. But one thing
to note there is that when we are talking about automimization, we actually don't
add use memo calls. So so there's we're actually like producing just like an
if an if else block that's kind of says like if the inputs to this
computation have changed, recompute it otherwise reuse the cached value. And there's other
things that we can do where we can say, okay, the user wrote,
for example, a use effect, but maybe the output of that doesn't
actually have to be a hook call. Maybe it could just be something that
like that does a more targeted update. So these are some of things where
we're looking at around effects. But I think for the most part, it's
what we're exploring is more Okay, we once we have a really you know,
a deep understanding of your code and what you intent, what your component
intends with the intended behavior is, we can start changing how that works at
runtime more dramatic. So that's like, so the compiler is kind of step
one of we have the existing React runtime, we're going to use use a
compiler to understand your code and kind of optimize with the current run time.
Now we have that baseline of compiler and run time, and now we can
start evolving them together to actually change the run time and how the run time
works to be more efficient knowing that we have this compiler to rely on,
right, and maybe it means that like you know, if there will still
obviously you have to support like if you have if you have a component that
that violates the rules that we can't compile. We'll still need a way to
support that, but we can start optimizing for if you do follow the rules,
can we make that even faster? So that's kind of where we go
next. But the first phase is just getting the compilitively stable obviously. Now
another question is currently the input is valid well, React JavaScript or React typescript
by React, I mean that it has jsx in it, but it's still
effectively just JavaScript. Are you thinking of maybe, you know, creating a
React script further down the line? I mean, you know, we kind
of talked about it before the show started. That reacts original creator Jordan Walk
actually also created the Reason programming language and ideally envisioned all the React developers not
only embracing React, but also replacing their JavaScript with Reason and helps hence solving
all the referential equality stuff because the Reason is an you know, function in
language with the mutable data structures. So are you thinking of one day,
maybe you know, somehow instead of in one fell swoop, like you know,
gradually moving us over to a React script. Yeah? So, uh,
we think about we think about React very much as like a programming language.
It has its own kind of semantics. For example, it has concepts
like components and hooks that that obviously don't exist in JavaScript. H We but
we think that the thing that has made reacts so successful is that we embrace
JavaScript. Uh And so you know, while we think about the design of
React from a like a programming language perspective, we we recognize you know,
for example, we we you know, Meta open sourced flow, which is
a really great you know, a type system for for JavaScript. The community
has overwhelmingly you know, really supported type script and typescript is an amazing language.
We love it. We're actually the compiler is written in type script by
the way, so huge fans of typescript as well. Not really nothing,
go, how dare you? I know? I know, uh well we
can get into the rest of the question in a little bit, but but
uh yeah, we really want us to kind of let support developers, you
know, meet developers where they are, just like you know, Tomatino are
the former manager and director of react or used to say, always bet on
JavaScript, and I think that's that's always for us, That's that's always been
a good bet. So yeah, we while we think about React from a
programming language perspective, We I don't really foresee us creating a React script.
We have been on the flow side, been experimenting with some custom syntax for
React. So this is like, you know, specific to flow. You
know, Flow is is is like kind of helping us explore what like a
first class what these first class concepts could be if they if they were in
the language. But that is something that is purely optional. If you use
flow, you can you know, you can opt into these like components or
hook keywords. But really React is always going to be about JavaScript and supporting
and supporting JavaScript from you know that that's that's like, that's a bread and
butter. Another point that I have to bring up, and we actually kind
of answer that without referring to it explicitly is signals. Basically, what I
hear from a lot of developers is, you know, why do I need
the compiler to get these fine grain computations and updates if I can just use
signals instead then get fine grain reactivity. What's your answer to that? Well,
the really simple answer is why rewrite your application to use signals when you
could get find grain reactivity by just adopting a compiler I think, you know,
that's a great answer, but you know the long the long version of
the answer. First off, in case folks are not familiar with what signals
are, right, signals are the idea of basically building up a computation graph.
So you write code that creates, you know, input signals that you
write, you create, you explositly create, you know, with with APIs
like a create memo or computed right, you create, you define functions where
those functions are accessing other signals or other computed values, and then you kind
of have either effects or kind of listeners sort of at the outside that are
saying, okay, whenever one of my inputs changes, I'm going to take
some take some action on the outside world like lug or update the you know,
the text value of a dom element or something like that. So you
have inputs, derived computations and then sort of outputs to the system. That's
like the rough idea of signals, but with with these, with signals as
a first class API, your code is actually a kind of a metaprogram.
You're writing. You're writing code that is constructing a computation graph. That initialization
code runs once and then you have the computation graph that is actually running over
time, and so now you look at your component and there's actually like two
phases going on that you've had to think about. And so you see things
like, oh, you talk about people to talk about Oh like, you
can't destructure props, or you can't do this, you can't do that,
And it's because there are mistakes that are easy mistakes to make where you're accidentally
accessing a value at the wrong phase of the program and now reactivity gets lost.
Right. You also to think about a lot of the a lot of
the kind of signal space frameworks will distinguish between a true memoized like where you
have a derived computation that's an actual signal versus something that's just a lambda that's
kind of passing values through. There's actually a surprising difference there where using an
actual like a proper derived signal might allow you to get to short circuit reevaluation,
but if you just use a lambda, you don't get that short circuiting
effect. So there's a lot of subtletyas you have to actually think about when
you when you're writing a program in this way that you don't have to think
about when you're just writing UI as a function of state, right, So
the like our kind of idea is okay. One of the things that has
made React so, you know, I think so successful and why so many
people, you know, are able to kind of ramp up on React and
be productive. I have a friend who just recently learned a program, and
you know, like one week they're saying, oh, reaction is really complicated
that you know, they just started looking at it, and then a couple
weeks later like, oh, I built a UI, Like it works great,
Like I love it, like I love you state it's so easy,
Like I think there's something very that that it is very approachable and easy to
understand about the kind of UI as a function of state, and then we
can just take that and optimize it. So under the hood with React compiler,
we're getting that same kind of fine grained reactivity. But things like you
just it's normal job ascript values. You can do things like earlier turn,
you can destructure your props. All these things that you expect to work still
just work because it it's the same React, you know, and just under
the hood it's working a bit differently. I think that's really the key.
You've hit the nail on the head that the key difference between the React way
I would call it and the signal way is a different approach of thinking about
UI construction. So if I'm just looking at it from the perspective of which
one is more efficient, which one is more performant, which one is you
know, it results in fewer lines of code. I'm kind of missing the
force for the trees. The key aspect is how do I think about front
end application design and architecture. Some people prefer to think about it one way,
some people like to think about it another way. I really like the
React approach of like I said at the very beginning that in an ideal world,
it's just as you said, Joe, stay in UI out. The
whole UI thing is is just this effectively functional composition, and that kind of
gets lost with the signal approach, which is why when people tell me,
hey, like when is react going to get signals? And even though I
don't work at Meta and so I can't really speak for you guys, I
say, I bet that never, because it's just not the React way from
my perspective. Yeah, I will clarify that, you know just a bit.
I mean, you know, there is a proposal out to add signals
as a TC thirty nine to to to to the language. You know,
obviously, if that becomes a standard, right, just just like we have
we now had used to and you can pass a promise and you know,
use promises with UH. With React, obviously we want to support you know,
built in features of the language, and so we'd certainly provide a way
to consume you know, the value of a signal and read it in a
component of So obviously in that sense, what will support signals, right if
they become part of the language, But in terms of like using them as
a core feature for how to do state management and updates and React. Yet,
as you said, we don't. We don't think that that's you know,
really fits in the React way. And we think that the current React
model of you as a function of state plain JavaScript values, normal Jobascript idioms
like earlier, turn if else loops, things like that, that that's an
easier way to reason about applications. And that's where we expect to continue going
with Reacting. All right, I'm going to jump in here because we're kind
of getting towards the edge of the end of our time and I want to
be respectful of yours, but I guess so Earlier I asked, Hey,
so I don't have to do anything in order to use this, but it
sounds like it's experimental, so I might have to if I want to try
it now there may be some steps to trying it, or maybe it's just
within the working group. So if people want to try it out, how
do they do that? And then when people hate when I asked this question,
when do you think it's going to go to the general public? Right?
And then I get that, don't do me like that, but you
know, and and I don't know if you know it's like, well,
barring any major hiccups, it's this or you know anyway however you want to
answer that, right, So I think, yeah, right now it is
an experndal state. You can NPM install the babble plug in. It's super
easy to add it to the babble conflict just at the compilad and it should
just work. And we have We're still accepting more partners to the working group.
We want really want feedback from the community. We want to understand how
people are using the compilerad, how the compiler works outside of meta and get
feedback and improve the compiler to make it stable. I think it's part of
that. I think it's too early to say when exactly we'll make it stable,
but I think it depends on the feedback we get from the working group.
If the feedback is mostly positive, then it seems like something we'd make
stablesome. Yeah, just to add on, I think a couple some of
the things that we're thinking about our the you know, getting feedback from the
community. As Nathia said, we are working on effects and like that kind
of like ties in a little bit to that work. The other other big
thing that we're looking at is what should libraries do. So for example,
if you're publishing a library and you want that library to be compatible with multiple
versions of React, how should you Should you pre compile the library? Should
you not pre compile it. Our current recommendation is to pre compile libraries,
and then developers don't because the general the general thing is you don't compile your
node modules, right, like I compile my code with like the settings I
want you you know, the packages that I like that I bring in like
those developers know how like you know, can can transform their code based on
how they wrote it right, so you can leave node modules alone. That
also makes builds faster, so it's kind of win win. So rough ideas
libraries should publish pre compiled code. But then one of the things we have
to figure out is, Okay, how does that work with like multiple React
versions, as the compiler changes over time, as the React runtime changes over
time. So that's one of the things we have to kind of figure out
is It've really got a good, really solid strategy in place there so that
everyone can start adopting it across the ecosystem. Super cool. One thing that
I really missed when I missed that I want to give a quick shout out
to is the health check script. So we have a script that will like
if youture from NBM React compiler health check, it will run the compiler against
your code base and I will like to say we were successfully able to compile
x amount of components found these libraries. That doesn't work well with the compilers,
so it will give you like a status of there find that Yeah,
like molpix and definitely uh, you know, the es len plug in also
experimental, but I think you know, but that one because it's not changing
your output code. Uh, you know, definitely recommend just like there's basically
no reason not to install that one and then just give us feedback about it
because that that's something that can really help you improve your code bass, you
know, starting today. So installation is just and b m I basically and
adding it to the babel can fig yep, so mpm I and then add
it to your babel, can fig add it to your link and FIG And
you know, we've kind of ran out of time before we ever got to
Rust and Go, so I guess we will just need to bring you on
some times you want. Yeah, the real quick answer is we know that
people are moving to alternative build systems that are that are based in Rust and
Go, like yes, build is yes, build is awesome, SWC is
great. Oh right, there's ox C biome right, a lot of like
a lot of you know, a lot of explosion in the space, which
is really exciting to see. So, uh, it does make it hard
as a tool author trying to produce something. It's like, okay, how
do we how do we ship this? Like because if we if we write
it and go, then it works in the y S build that doesn't work
in the other one, there's kind of no like one way to write it.
So we've started exploring porting the compiler to Rust, with the idea being
that we can provide a node binding, we can provide a go binding,
we can obviously provide bindings to Rust based tools. That is, we have
a partial port that's in the repo, so you can go check that out
if you're interested. But that is, you know, on maintain, we've
just kind of done an early exploration. Long term, I can imagine us
you know, finishing that migration, but for now it's based on typescript so
it works really easily, you know, drop in with Babbel. Thankfully,
most of the tools, things like next jes for example, Expo, they've
they've already we've already got documentation for how to use it in those tools.
Even you know, even in for example next where the default build is using
Rust, we can we can inject a babble plug in into that process and
it just works. Well. Just just be careful because you know, Rust
is kind of old news and Zig is the new hotness, and you wouldn't
want to spend all that effort just to have to rewrite it again next week.
Yeah, I mean Yeah, So what I want to say about that
is Hi is a really cool language. It's got some really awesome features.
We've we've on our team, We've had some some great like a lot of
success with Rust. We use it internally for a bunch of different a bunch
of different things, especially around build tools. Really compiler, which I worked
on is written is now written in Rust. We rewrote from JavaScript to Rust
a while back, and so we have a lot of familiarity on our team
with Rust as a language. So that's kind of an obvious choice for us,
in addition to the hype in the ecosystem. Cool. All right,
Well, I'm gonna push us into the final segment of the show, which
is our picks, Dan, Why don't you start us off with picks?
Okay, I don't have a lot of picks, since this is the second
episode we're recording this week, and I got you know, I kind of
used some of my picks in our last in our previous recording, So I've
just got the one. I've been really on Netflix as recently, you know,
with the quality of the movies they've been putting out. You know,
I said that the only good thing I could say about Atlas was that it's
better than Rebel Moon, and I can't say anything good about Rebel Moon,
So yeah, but now I actually want I'm in the process of watching Netflix
movie, which I'm finding surprisingly enjoyable and well made, and maybe i'll finish
it today, I don't know, maybe so later in the week. It's
Godzilla minus one. Now it's really surprising to me because I really wasn't expecting
much and I'm not such a big fan of Godzilla movies, but this one
is really good, at least again the first half of the movie. And
interestingly, it's good. The fact that it's good has nothing to do with
Godzilla. The fact that it's good has everything to do with the protagonist,
the hero of the story, which is this kid who was a soldier doing
a Japanese soldier during World War Two. He was actually a kame Kazi pilot
and he kind of chickened out. It was really at the end of the
war, basically like literally the last couple of days, everybody knew that they
were losing, so he literally just didn't want to die, and he's living
with the guilt. And there's the whole thing of Japan after the war and
you know, and the effect of the nuclear bombs and like rebuilding the country
and walking around with the guilt of all your friends and family who have died
in your life and stuff like that. And it's much much more interesting and
engaging to me than the actual monster. And that's why I'm enjoying this movie
so much, and I would highly recommend it again. I'm talking just the
first half of the movie. I haven't watched a second f And those are
my things for today, not cool, AJ, What are your picks?
First pick is motorcycles because my neighbor let me ride his motorcycle and I really
liked it, and so I'm thinking about trying to find some old Beater Cruiser
to to ride around for myself. And if anybody's interested in getting a motorcycle
learners permit, it's it's a lot easier than the driver's license because there's actually
a national standard standard body called MSF, the Motorcycle Foundation I think Safety Motorcycle
Safety Foundation, and they make the handbook that pretty much all fifty states use.
So aside from like I don't know, Utah and Alaska that have a
different BAC level and like Arizona that I don't know you like, aside from
a very few niche things that vary from state to state. Pretty much,
if you do any MSF practice test, you can go into your DMV and
get your Motorcycle Learners Permit, and then the courses are standardized across the nation
called BRC for Basic Rider Course, and then they also have other courses like
the BRC is basically, if you take the BRC, you can get your
license without waiting whatever the time period is for your learner's permit, and without
having to do the state exam because the MSF exam will be done when you
take the course and it's more rigorous than the state exam, so you just
take in your things. So I'm getting my motorcycle license, so you know,
as my wife, family and friends would say, you may never hear
or see from me again. See some quiet chuckles in the background there.
And the other thing that I'll pick a little self promo again. Webby is
on the rise. I was just told recently that it is now an official
install method for the GitHub Cli and we're up to one point seven thousand stars,
so we have hit the inflection point. The the line goes up.
It hit the hockey stick. So after many years of working on it,
it's really cool to see it's arrived. I think the reacting counts stars just
as galaxies. You know the amount of star Yeah. Yeah. But for
those who don't know, it's just a way to install tools that doesn't require
a package manager and his platform independent, so it can work in Docker,
Ubuntu, Alpine, Mac BSD and when many of the tools it's it's a
web installed dot dev. Okay, all right, I am gonna throw out
my picks and then we'll let Satya and Joe put theirs in. So I'm
gonna do a pick. This is a kid's game. It's a Grandpa back
game. I don't know if y'all are familiar. No, it's not.
I thought it was, but it's not because I'm looking at the the artwork
for the box anyway. So every year for Christmas we get the kids,
each of our kids a game, a board gamer, a card game.
And this one's called Sleeping Queens two. So I think I picked Sleeping Queens
in the past. It's one that you know, we got for my daughter
when she was like six, and it's a really simple game. You can
play in like fifteen or twenty minutes. I think you can play it up
to five players, and essentially what you do is you play different cards,
and in Sleeping Queens, what you're doing is your you play the Kings to
rescue the Queens, and in Sleeping Queens, you play the Queens to rescue
the Kings. And then you have different cards to let you steal cards from
other players or play extra cards or draw extra cards and things like that.
So it's it's really really simple game. And yeah, it's published by Game
Rights, so uh, anyway, it's it's a fun game. Our family
loves Sleeping Queens. Yeah, I haven't gotten number two yet, but that's
thanks for the recommendation. Yeah, so board game weight I always throw this
in. I don't know if anybody cares about the board game weights, but
it gives people a flavor of how complicated it is. It has a weight
of one point five, so you know, and it's a kids game,
so it's it's a simple game. It has just enough complexity to make it
interesting without making it overwhelming for a six year old or an eight year old.
So I'm gonna pick that for my board game. I'll post the board
game geek listing here a couple of other things that I'm gonna pick. So
my wife and I are about to finish up Star Trek Discovery. We've enjoyed
the show, I think, and I feel this about a lot of shows,
but the first couple of seasons were better than the last couple of seasons.
But I mean, the show's been good show, So I'm gonna pick
that. And then the other thing that I've picked up, I think I
mentioned that I've been using Finch, which is just a kind of self care
social app. My wife and kids all picked it up, and so yeah,
so then I can send him hugs and I can keep track of my
habits and stuff like that in it. But one of the things that I
picked up about a week and a half ago is Dual Lingo. And a
lot of people know what it is. It's free, right, I mean
it shows me ads periodically, but whatever, but unless you're practice languages.
And initially I picked it up because I've been wanting to learn Japanese, and
so I picked it up for Japanese, and then I can't remember what it
was that inspired me, but I was like, you know, I really
I really kind of want to pick up French again, because I took French
in high school, and so I added it. And then I was talking
to somebody else and I mentioned that I had lived in Italy for two years
and realized that my Italian's gotten fairly rusty. And so I basically do three
lessons a day. I don't do them all at once because I don't want
to like confuse my brain, but you know, I'll do one in the
morning, and then i'll do one sometime during the day, and then i'll
do another one, you know, in the afternoon evening. And yeah,
I'm finding that the Italian's coming back to me. And what's funny is is
that my Italian vocabulary is very strong in a couple of areas and not very
strong in a bunch of other areas. Because when I lived in Italy,
I was a missionary for the church, and so my religious vocabulary is very
fairly broad, right, my day to day living vocabulary is okay, and
then my vocabulary on all kinds of other things is just almost non existent.
And so I've been picking up vocabulary and learning how to talk about things that
I haven't really talked about in Italian. So that's been very fun and I'm
kind of at different levels on each one, but it's easy. It's anyway,
I've been very happy with dual Lingo. You can get a Duolingo Plus
or pro or whatever, and like, if you make a mistake, you
get a penalty and you lose a heart and then you have to wait for
the heart to come back, and if you pay, you don't have to
do that, and it doesn't show you the ads. And I think there
are some other social aspects that it adds. But anyway, I've been pretty
happy with it. I'm happy that it's free. And yeah, so I
can order like four things in Japanese at a restaurant, I can carry on
a very rudimentary conversation with people in French. And then yeah, I'm talking
learning to talk about daily habits like exercise and stuff in Italian right now.
So anyway, I'm gonna I'm gonna pick all of those and throw it over
the fence to Satya. Well, the what's the context for the picks?
So it's just a shout out about anything you like? Right So you know,
Dan picked a movie, I picked a TV show and an app.
You know, AJ picked web install dot dev which is more text just whatever.
Cool. Yeah, I guess I can do like this both themed one.
So there's a right now. I don't know if you've if anyone's familiar
with the can't call it crockette. I don't think it's I don't know if
it's popular and American. I know of it. I know it's a sport
that can last a couple of days, right. There are different versions that
do it. There's there's one that lasts for like five days, there's one
that lasts like the entire day, and then there's one that's like a couple
of hours long, for like four hours long. So there's a World Cup
happening for that for the really shot version. It just started this weekend,
and it's happening in the US. I think they're trying to like make it
more popper in the US, So I'm like excited to see how how that
pans out. I was following the last World Cup, which was the slightly
longer one that happened last year, and I'm from India and I was supporting
India, and India is generally very good at this schem and they went all
the way unto the finals and then they lost, which is very heart breaking,
so I'm hoping that they win this time. So yeah, that's that's
my pick. And then I guess also another sport later one is the Euros
are starting next week. If you're into footballer but now you're speaking my language.
Yeah, well you mean, well not football as long as we're there.
I don't know if it'll come out before the show is there or after.
But the NBA Finals are also happening, right, so I'm in London,
so after support England for the Euros, I'll be waiting for England too.
They are also very good. They are very good. Yeah, so
those are my picks. I mean, I can't talk. I always support
Italy. In the last few years, I've been very very disappointed. But
but England never actually wins, as I recall, that's true. They went
to the finals and well everyone yeah, yeah, all right, all right,
good deal. So, sticking with the theme of the podcast, for
those who are curious about compilers, Robert nischerm Bob Neishrom wrote a great book
called Crafting Interpreters h It is available in you know, dead tree form,
in electronic form. It's also I think there's a reversion on crafting interpreters dot
com. Uh, it's it's it's just a really really great accessible book where
he basically walks through building the same an interpreter for a simple kind of imperative
language marry JavaScript like language, and he kind of walks through building a sort
of ast walk interpreter in I think like Java, and then he does a
bytecode based interpreter in C. And I don't know C at all. I
like just I can just barely read it and know what's going on, and
I was. I found it completely accessible. It's just very very obvious,
like what's what's happening, so highly accessib book to kind of understand that the
basics of what's happening in the compiler and an interpreter. Now we've got to
mention the Dragon Book if you want something that's so inaccessible, right, yeah,
yeah, if you want something inaccessible, I've never bothered reading the Dragon
Book. And then I'll also give a shout out to Sofia has an amazing
blog and he's actually written about some like some of the detail so is recompiled
dot dev right, So check out Soathia's blog for kind of some more details
about how the compiler works on the inside my life is basically the compiler and
then like being a dad, so U plus plus one to sleep in Queens
as a pick. All right, well, I guess one last question is
if people want to learn more about what we talked about with the compiler,
or you know, maybe they're looking for Joe or Satia on the Twitter,
where do they find you? So I'm on Twitter as E E N underscore
js uh And for the compiler, you can go to react dot dev Slash
learn Slash React Dash compiler and I'm underscore Chisatia on x oh. Yeah awesome.
All right, well, thank you both for coming and talking through this
with us. We kind of had to figure our schedules out, but it's
so fascinating, so yeah, zero