Transforming React Development: The Experimental Compiler’s Approach to Memoization and Performance - JSJ 636

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