In this episode, they dive deep into the latest advancements in React with a special focus on the experimental React Compiler. Our guest speakers, Sathya Gunasekaran and Joe Savona, share their insights on how this cutting-edge tool aims to enhance performance and streamline development without disrupting existing code. They explore the goals of the React Compiler, including auto memoization, linting, and runtime optimizations, and how it plans to minimize unnecessary DOM updates. This is an in-depth discussion on subjects like referential equality, the complexities of memoization, API improvements for useEffect, and the compelling debate about whether React should introduce signals as a TC39 standard. Additionally, they discuss the potential transition for existing projects, the importance of community feedback, and the intriguing differences between React’s approach to UI as a function of state versus the signal-based model.

Stay tuned to learn about the future of React, the practical benefits of the new compiler, and the ongoing experiments that could shape how we write and optimize JavaScript with React.

Socials

Picks

Charles Max Wood [00:00:05]:
Hey, everybody. Welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neil.

AJ O'Neil [00:00:11]:
Yo. Yo. Yo. Coming at you live from an 800 cc engine. Not really though, but I am looking at getting a motorcycle.

Charles Max Wood [00:00:21]:
Alright. Dan Shappir.

Dan Shappir [00:00:23]:
Hi. From a warm and somewhat muggy Tel Aviv.

Charles Max Wood [00:00:27]:
Uh-huh. I'm Charles Max Wood from Top End Devs. And, Yeah. This week, we have 2 guests. We have Satya. I don't see your last name. So my friend, you're gonna have to tell us who you are.

 Sathya Gunasekaran [00:00:40]:
Hi. I'm Satya Gonesigrin. I'm I walked my

Charles Max Wood [00:00:43]:
route. Just

 Sathya Gunasekaran [00:00:46]:
gonna say that. You know, honestly, Microsoft getting Satya as their CEO is the best thing that have that has happened to me. Right. Because now everyone can pronounce my name, at least in tech.

Charles Max Wood [00:01:02]:
Alright. Good deal. We also have Joe Savona.

Joe Savona [00:01:05]:
Hey. Nice to be great to be here. Thanks for having us.

Charles Max Wood [00:01:07]:
So, yeah, Joe, I went and looked. I'm pretty sure we haven't had Satya on before, but, you were on in 2015. We were talking about Relay and GraphQL. So welcome back. It's been a while.

Joe Savona [00:01:20]:
Yeah. And last year for RSC.

Dan Shappir [00:01:22]:
Yeah. Yeah.

 Sathya Gunasekaran [00:01:23]:
I know.

Charles Max Wood [00:01:23]:
I mean,

Dan Shappir [00:01:24]:
my search you might

Charles Max Wood [00:01:25]:
need that one.

Dan Shappir [00:01:27]:
Yeah. Yeah. We we spoke with, with Dan Abramov and Joe together about Oh,

Charles Max Wood [00:01:32]:
you're right. It just doesn't have your name in the title.

Joe Savona [00:01:36]:
Because it's Dan. Sucks Oh,

Dan Shappir [00:01:38]:
Dan. Sucks the gen

Joe Savona [00:01:39]:
out of the room. Yeah. Exactly.

Charles Max Wood [00:01:40]:
It doesn't have Dan's name in the title either, but that that's the reason why.

Joe Savona [00:01:46]:
We'll blame it on Dan, though.

 Sathya Gunasekaran [00:01:48]:
Yeah.

Charles Max Wood [00:01:49]:
He's not here. Yeah. Alright. So we're here to talk about the React compiler, and there was a big announcement, I guess, within the last week or so. I'm sorry. I'm I'm in the this time crunch where, like, time dilates. And so I don't know if it was 2 weeks ago or 2 months ago, but I know it was recent. So do you wanna fill us in on what we're talking about today? Just kinda set the stage, and then we can dive into what it means.

Joe Savona [00:02:16]:
Yeah. Satya, do you wanna Yeah. As you as you take a sip of water, I'll I'll punt it to you.

 Sathya Gunasekaran [00:02:22]:
Sure. Yeah. We had React conf couple of weeks ago where we announced, the open sourcing of the React compiler, which we've been working on for almost two and a half years, 3 years at this point. So it's been a it's been a while. And, yeah, it's it's open source. You can try it today. There's a a babel plug in that you can run on your, apps, your React app, and it gets automatically memoized. So you no longer have to think about, use memo and use callback and react out memo.

 Sathya Gunasekaran [00:03:00]:
The compiler helps remove the malo memoization. And then there's also an ESLint plugin that helps you catch bugs. So when you violate the rules of React, the ESLN plug in will help you so you can write bug free React code.

AJ O'Neil [00:03:19]:
Okay. I'm confused. In what sense do we mean come I no. I really am. So first of all, I'm not I'm not a front end person. I do Okay. Mostly server side. Okay.

AJ O'Neil [00:03:31]:
So when I think of a compiler, I think of, like, either comp 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 is 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.

Dan Shappir [00:04:07]:
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, 1, technically, I understand what you're why you're calling it a a compiler because it works like a compiler, and there's, you know, ASTs and and whatnot. It it's taking JavaScript and translate valid JavaScript and translating it into valid JavaScript. So, you know, usually

AJ O'Neil [00:04:47]:
about JSX?

Dan Shappir [00:04:49]:
No. It's not about the JSX. It's about taking

Joe Savona [00:04:51]:
They also support JSX

Dan Shappir [00:04:53]:
and Yeah. Obviously. Yeah. Obviously. And also TypeScript, I guess. But but, you know, at the most basic 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 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 AJ's question.

 Sathya Gunasekaran [00:05:35]:
Right. So, generally, like, in the front end ecosystem, there's there's been babble, which we use to do transformations on the AST. Right? That's that's where that's honestly, how or, like, why the dump transpiler became popular, at least in the JS community, is the transformations using babble. But I think I think in that aspect, yes, the React 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 is a more like a traditional compiler, like how V eight would work, which is why, we call it the React compiler. We do lower it to not just AST, but to, like, very low level IR. And then we compile that back to source just because we wanna ship that as JavaScript.

AJ O'Neil [00:06:36]:
So for the benefit of our listeners and myself, what what's IR and and then what's AST?

 Sathya Gunasekaran [00:06:43]:
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 JS syntax into, abstract syntax tree, which is like tree 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 representation, which is most generally a control flow graph. So it's more like a graph rather than a tree of nodes. So you can do more advanced optimizations and analysis on this data structure.

AJ O'Neil [00:07:37]:
So what what's the nuance between tree and graph? Because when I hear the 2, normally, they're synonymous.

Dan Shappir [00:07:46]:
Mhmm. 1 is cyclic 1 is cyclic and the other isn't. Both

Charles Max Wood [00:07:52]:
Okay. Yeah. Or a tree a tree is directed. It kinda goes one way.

Dan Shappir [00:07:56]:
Yeah. Tree is a is a tree is a kind of a graph. Like, every tree is a graph, but not every graph is a tree. Right.

 Sathya Gunasekaran [00:08:02]:
Got it. Right. So the React compiler does lower to this sort of lower level IR, which is like a graph, which is which is why we call it a compiler.

Charles Max Wood [00:08:15]:
So Can

Joe Savona [00:08:17]:
I just add on? Maybe

Charles Max Wood [00:08:18]:
Yeah. Go ahead.

Joe Savona [00:08:19]:
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 Babble's homepage, they say compilers.

Charles Max Wood [00:08:29]:
Ticks.net. Very nice.

Joe Savona [00:08:30]:
You go to you go to you go to TypeScript. They call it a compiler. Right? So so part so part of it, so it's kind of 2 aspects. 1, the way it works is is a compiler. The other aspect is, naming it in a way that developers actually understand what it what it is, which is when you look around, similar types of things are being are are, you know, in the JS ecosystem known as compilers. And this is doing, you know, some something similar or actually more sophisticated in 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, like, get into what it's doing. Right? It's not just about the fact that we're lowering lowering to an IR and a control flow graph, but it's really about, like, what is the compiler doing? What like, how does it understand your code? What transformations is it applying in order to help you have you know, write nice clean, you know, React code like you're used to and get better performance at the at the, you know, on the the output.

Joe Savona [00:09:20]:
I think once once you kind of understand, like, what it's doing in the full pipeline, then it becomes clear why we're calling it a compiler.

Charles Max Wood [00:09:26]:
Yeah. I just I wanna jump in here real quick because it feels like, you know, you 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 gonna get me down the street so that I can go to the grocery store.

Joe Savona [00:09:44]:
Exactly. What what matters is not yeah. Exactly.

Charles Max Wood [00:09:46]:
So so I'm gonna ask, why do I care? Right? What does this do for me?

Joe Savona [00:09:52]:
That's a great question. Yes. Satya?

 Sathya Gunasekaran [00:09:57]:
Well, do you mean, like, the why we why we have the compiler? Or

Charles Max Wood [00:10:02]:
Yeah. Basically. So, you know, I'm 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'm I do Rails. Right? So maybe I have an API, and I'm just doing React off of the API.

Charles Max Wood [00:10:16]:
But at the end of the day, how is it going to make my app better? How is it gonna make my life easier? How is it gonna make my users' life easier? Or does it not do any of those things, but I care about it for a completely unrelated reason?

 Sathya Gunasekaran [00:10:31]:
Right. So, what we've found out is React can sometimes be too reactive and that it can rerender it more than necessary and to fix that. And and rerendering too much can be a performance issue Okay. In certain cases. And to fix that, React gives you APIs, like use memo, use callback, and react. Demo. But Mhmm. Using that, is a mental tax for developers, because they have to think about something other than building UIs.

 Sathya Gunasekaran [00:11:04]:
Right? Like, you don't wanna be thinking about memorization. You wanna be thinking about solving your user's problem. So the compiler comes in, automatically adds all of this to you to your app.

Dan Shappir [00:11:15]:
I 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 2 levels of rendering or rerendering going on in the context of React. One level is the generation of the virtual DOM. When you write when your your code, the React code that you wrote as a React developer runs and builds the virtual DOM. And then there's another rendering that happens when React itself takes the virtual DOM and transforms it into updates to the actual browser DOM. Now from my perspective, from almost day 1 or essentially from day 1, you kind of solve the performance issue around the lower level rerendering. That's what the virtual DOM was created for, the whole reconciliation mechanism.

Joe Savona [00:12:15]:
Yep.

Dan Shappir [00:12:16]:
You know, there are some interesting things going on with 1,000,000 JS. I know, for example, they're trying a different approach, which 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 pro the the place where we still had the problem, turns out, was at the higher level of creating the virtual DOM. 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 DOM is really cheap. It's just JavaScript objects. You know, they're they're lightweight. There's little low effort related to it.

Dan Shappir [00:13:03]:
The browser is really good at managing JavaScript objects. Turns out that in some cases, you guys were lying. Well, I'm kidding. I'm kidding.

Joe Savona [00:13:13]:
Oh, I'm kidding. I'm I'm gonna interject there just because I'm kidding. I'm kidding.

Charles Max Wood [00:13:17]:
I'm gonna I'm gonna interject there just because

AJ O'Neil [00:13:17]:
I'm kidding. I'm kidding.

Dan Shappir [00:13:18]:
I'm kidding. Yeah. Yeah. I sorry. Go for it.

Joe Savona [00:13:21]:
Yeah. I think I think what what what has changed is the, like, the size and complexity of applications. Yeah.

Dan Shappir [00:13:27]:
For

Joe Savona [00:13:28]:
sure. So you're absolutely right that, like, there's kinda these, like, two levels of rendering happening. There's the, like, the the JavaScript React rendering, you know, calling component functions. Right? And then the the code that they that they call. And then there's okay. That creates a virtual DOM, and then there's React then doing the diffing of the virtual DOM. You're right. So React has really solved that, you know, actually making the minimum number of DOM modifications.

Joe Savona [00:13:51]:
Right? That that's, like, always been, like, React strength. But what's happened over time is people are building larger and larger applications where there's more and more product code running, right, the that that that high level rendering. And so that is where this the the time is really coming from. So, you know, the like, I think the the the community focuses a lot on, like, kind of, 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 we only run the minimal set of product code that we need to when state changes. Right? And then that complements the the lower level piece of only making the the necessary DOM modifications.

Dan Shappir [00:14:31]:
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.

Joe Savona [00:14:41]:
We we appreciate we appreciate good criticism. No.

Charles Max Wood [00:14:43]:
It's not what

Dan Shappir [00:14:44]:
you told

Charles Max Wood [00:14:44]:
the kids too.

Dan Shappir [00:14:45]:
Yeah. For actually, yes. I've been using React since 2014, so I'm 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 the that whole, pure approach of transforming state into, UI. And that in an ideal world, if it was possible, we would be rerendering everything from scratch on every change just to make everything, like, you know, stateless as it were.

Dan Shappir [00:15:38]:
Like, as pure as possible. State in, UI out. But, you know, reality, gets in the way. And and then and that's why we have all the sophistication behind the reconciliation in the virtual DOM to get to avoid the excessive DOM updates. And from my perspective, the React compiler is kind of like the final step, the 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, replace by memo and use memo. Maybe I'm forgetting something in the middle. And and now, ideally, hopefully, we can finally forget about these things.

Dan Shappir [00:16:33]:
Hint, hint, react, forget.

Joe Savona [00:16:36]:
Yep. That's cool. We couldn't have said it better.

 Sathya Gunasekaran [00:16:39]:
Yeah.

Dan Shappir [00:16:41]:
So can you now so the benefit really 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.

Joe Savona [00:16:59]:
Yeah. Exactly. Right. It's that it's that UI is a function of state. That that is the thing that we've really seen that makes React so approachable to everyone is that you write your app as if it is going to rerender. The entire thing is gonna rerender every single time. Right? So the the whole like, as Satya mentioned it being, like, too reactive, it's like there's never a point if if, you know, for example, if you kind of forget about use memo and dependencies. Right? Just JSX is never gonna, like, forget to update.

Joe Savona [00:17:29]:
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 gonna fully reactive by default and it's really hard to kind of mess that up. The the only places that you can mess it up are when you start getting into okay. Let me write a use memo. Oops. I forgot a dependency. And so now something doesn't update.

Joe Savona [00:17:48]:
Right? So, and so it's by having the compiler do the memoization for you, we can make it so that you keep that same mental model of just writing simple, you know, simple functions, pure functions of mapping state to UI, and you get that same mental model. But under the hood, you only the minimal parts of the code are actually running that need to.

Charles Max Wood [00:18:08]:
So can I clarify a couple of things? First of all, it's you know, I'm I'm gonna back way up and then kinda come forward. But before I do that, the first thing that I wanna just highlight is you're telling me that basically you 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?

Joe Savona [00:18:40]:
Yep. That's the idea. And then 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.

Charles Max Wood [00:18:53]:
That 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 the two layers of, what, DOM manipulation 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 gonna 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?

Dan Shappir [00:19:33]:
No. You got it reversed. They I

Charles Max Wood [00:19:35]:
got it reversed. Okay.

Dan Shappir [00:19:36]:
From the from the get go, the mechanism that got the virtual DOM to the DOM was highly optimal. It identified what changed in the virtual DOM.

Charles Max Wood [00:19:45]:
Oh, right.

Dan Shappir [00:19:45]:
Okay. And then update did only those things in the DOM that actually needed updating. And to be honest, that's the most expensive thing per update because the DOM is expensive. But what was missing was the optimization to the user land code that generated the virtual DOM itself to, you know, the the higher level. Okay.

Charles Max Wood [00:20:12]:
But but it trend it because you've optimized I guess I had one layer here and one layer. Because you optimize this layer, it translates into better performance here because it doesn't have to do as much

Joe Savona [00:20:24]:
work? Yeah. So yeah. Exactly. So, we are so React has 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 JSX from your from your component, We compare, you know the the basic idea of what React is doing this the the 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 gonna compare it to the previous JSX, what the UI was, and we're gonna 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.

Joe Savona [00:21:04]:
That entire subtree, you know, 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 is doing is taking advantage of that and kind of finding all the bits of the JSX that don't need to update. We 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 it's doing less rendering work, but it's also then creating less work to do in the different process as well.

Dan Shappir [00:21:35]:
I'll get I'll get back to that because that's a really interesting point that I hadn't thought about

 Sathya Gunasekaran [00:21:40]:
and hadn't considered. But I think, you know, since a

Dan Shappir [00:21:40]:
lot of the optimization is but spend a couple of minutes of in explaining what memoization actually is and what it means.

Joe Savona [00:21:56]:
Yep. Yeah.

 Sathya Gunasekaran [00:21:59]:
Yeah. I can do that. I think the the main problem that we're solving at memoization is JavaScript's, referential equality is is if you create 2 objects and compare 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 thing that Joe just talked about. So with memoization, we keep as long as the values don't semantically change, like, the values in them don't change. The objects are the same.

Dan Shappir [00:22:38]:
So so, basically, you're saying if if if I have a funk if I have a function, let's say a pure function, not to make it simple, that takes a couple of parameters, does some computation, and returns a result. I don't need to run this function again if the parameters haven't changed because there's a guarantee that the result would be the same.

 Sathya Gunasekaran [00:23:02]:
Yep.

Dan Shappir [00:23:02]:
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. Yep. So I don't need to do a deep comparison on the result. I can just look at the actual reference. So I I benefit twice as it were from from avoiding this recalculation.

Joe Savona [00:23:32]:
Yeah. And there's a there's a cascading aspect to this. Right? So if you imagine that, state changes, you know, you you so you you update state and you change, like a count from 0 to 1. 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.

Joe Savona [00:23:59]:
Now you've put that inside of an object or an array. Maybe you then capture that inside of a function, right, to log log that array. And so without memoization, what's kind of happening again, like, with the default in React, just every time we render, we produce a new with new state, new array, new object capturing that, new new function logging it. With memoization, the idea is to say, okay. If the input didn't change, we're gonna produce the same output. But now if you 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.

Joe Savona [00:24:35]:
So that that didn't really help. Right? The idea is that with memoization, it 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 my input array changed. What am I gonna do? I guess I have to recalculate and reproduce this function or something. And so then you get an entire subtree, kind of unnecessarily updating. And so the idea is that with memoization, one way to think about it is automatic memoization. Another way to think about it is kind of tuning the amount of reactivity.

Joe Savona [00:25:08]:
What we're doing is making it so that when values semantically change, we're updating, and, otherwise, we're not we're we're not updating. So the that's that's the thing that is trying to get with. Like, I think that the point you're getting with referential quality, right, is referential quality 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 to check, did it meaningfully change. Otherwise, you're actually gonna do a full diff of the object. And, unfortunately, you can't diff functions in JavaScript.

Dan Shappir [00:25:36]:
Yeah.

Joe Savona [00:25:37]:
So, right, we're we're kind of just limited by the language there.

Dan Shappir [00:25:40]:
So just again to clarify to our listeners who might might not be familiar with the terminology. Let's say, you know, when you're looking at the primitive value like, number or Boolean or even a string in JavaScript, You're just comparing it and JavaScript does it for you. So, you know, 7 is equal to 7. Hello. M is equal to hello. When you've got the reference to an object, there are 2 types of equality here. 1 is that we've got two references to the exact same object, and the other is that it's there are 2 objects, but they are equivalent. They they have the the same values for all the properties.

Dan Shappir [00:26:22]:
And again, it might be it is whether you go through that object recursively or just one level down, it, you know, it the problem obviously is doesn't 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 lodash 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.

Dan Shappir [00:27:24]:
Hence, I can use the very cheap referentially quality that's built into JavaScript.

Joe Savona [00:27:29]:
Exactly. Yep.

Dan Shappir [00:27:32]:
Now one more thing before we move on from there. Again, if we go back to the existing primitives that 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.

 Sathya Gunasekaran [00:27:54]:
Yeah. So react dot memo is to wrap your component. It's, it's so that when as long as your props don't change, the component doesn't rerender. The default behavior in React is if your parent rerenders, then we rerender the child component. Even if the props don't change. So that's that's the react. Memo. And use memo is if any of the dependencies of the use memo change, then we run a computation.

 Sathya Gunasekaran [00:28:24]:
Otherwise, we use the cached value of computation that the use memo is wrapped in.

Dan Shappir [00:28:30]:
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 2 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 memoize all the subcomponents. But Yep. Then people either memoize too much or too little. And when they memoize too much, they showed wrong things.

Dan Shappir [00:29:35]:
And when they memoize 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 kinda slow, but it works. Or they memoize everything, and the the whole application is just a 1,000,000 calls to memo.

Joe Savona [00:30:06]:
Yep. That's that's exactly the the type of thing we've seen. And to be clear, like, a lot of times for for us, especially for smaller applications, the fact that there aren't isn't a lot of minimalization is fine. Like, the amount of rerendering that you're doing just can be fine. We hear we've actually it's funny. Like, then we hear a lot about the 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 that the React comp that was was interesting was just going around talking to people and and people are saying, like, I love React. It's it's so fast.

Joe Savona [00:30:35]:
You know, I never have performance problems. It's like, oh, that's so nice to hear. But, like, you know, we're that we're not content with that, but it's still great to hear. Right? We wanna make we wanna make every React app fast by default. But but, yes, The the, like, the need to do this kind of memoization that that is, like, that is overhead that we can solve. Right? That that's like, that, having to kind of and and the the the worst part is that if you add you know, you could go through a lot of trouble to add memoization everywhere, but it's still easy to miss, you know, one spot. Right? And then like and as I said, like, that can then cause a cascade because you missed one memoization. So that produces a new value.

Joe Savona [00:31:11]:
And then that new value flows into the memoization you have, which then says, oh, the my input changed. 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 to have happen when you're, you know, changing the code over time. You had you you 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.

Joe Savona [00:31:36]:
Right?

Dan Shappir [00:31:37]:
So am I correct in 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?

Charles Max Wood [00:31:59]:
It's like automatic semicolon incur insertion except cooler. Right?

Dan Shappir [00:32:06]:
Good analogy.

AJ O'Neil [00:32:07]:
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 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 Mortore and all these guys are talking about this stuff. Primagen, etcetera. 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 semicolon insertion. Like, hey. You should use memo here. Or just, like, I hit save, and then boom.

AJ O'Neil [00:33:03]:
The used memo appears. And I change the code, and I hit save, and boom. The used 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?

Dan Shappir [00:33:25]:
I have my opinion on that, but I'll let the guys answer first if they have an answer.

 Sathya Gunasekaran [00:33:30]:
Joe, I'm actually curious to hear your thoughts. So

Joe Savona [00:33:33]:
Yeah. So I think there's a okay. I guess, I I guess I disagree with the with the premise somewhat that there's too much abstraction. You know, we don't, What? Yes.

AJ O'Neil [00:33:49]:
That's not a controversial. You broke me.

Joe Savona [00:33:54]:
Right. So so when when you when you start your next project, you write your own database, your own 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

AJ O'Neil [00:34:07]:
next block. Right?

Joe Savona [00:34:07]:
Like That

Charles Max Wood [00:34:08]:
that was just last week.

AJ O'Neil [00:34:09]:
All the tyrannosaurus.

Charles Max Wood [00:34:10]:
My whole

Joe Savona [00:34:10]:
week. Yeah. That's My whole week. So I I I I know that you're I'm just, like, for for the audience sake of, like like, there there's clearly, like, a certain level of abstraction that's, like, that's kinda necessary. So to me, it's really about the value of a particular abstraction. Right? Like, I I I 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 the the bane of of our of, like, software developers' existence is, like, leaky abstractions, right, where, it's you're like it it it almost works, but it doesn't always work.

Joe Savona [00:34:38]:
And that's, I think, where the those are the things that kind of can be too magical in debugging them. So go ahead.

Dan Shappir [00:34:44]:
Let me

AJ O'Neil [00:34:44]:
let me just to to your example, I wanna add something clarifying. Versus code to JavaScript file. Perfect. Like, this is a good abstraction. It's perfectly understandable that

 Sathya Gunasekaran [00:34:58]:
Right.

AJ O'Neil [00:34:59]:
It's one to 1. The

Joe Savona [00:35:00]:
the It's a non leaky abstraction. Right.

AJ O'Neil [00:35:02]:
Okay. Microsoft Word to JavaScript. Yeah. I mean, like, now you gotta deal with the smart quotes. You gotta 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 in Versus Code when you hit save.

AJ O'Neil [00:35:26]:
Like, the file you get, it like, so, yes, there's a lot of abstraction there, and it might take 15 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, holy crap. How did this file end up here?

Joe Savona [00:35:43]:
Yeah. So so the the other aspect is then so then the the question for me is, like, is it a leaky abstraction? Right? Is the abstraction sound? Can you rely on it? Is there a can you build up a clear mental model of what the compiler is doing? And that's what we've really focused on. Right? So that's what we've really focused on. So the, so there's a there's so there's kind of the the the mental model aspect and then the pragmatic aspect of and we kind of have to balance these two things. So on the on the practical side, imagine that we did say provide a linter that would add memoization. In our analysis, we've seen I don't know if I can share the number. The compiler adds a lot more memoization. Like, it memoizes things that developers would never in a 1000000 years have thought to memoize.

Joe Savona [00:36:28]:
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 we're working on 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.

Joe Savona [00:37:11]:
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 used memo? Where does this code go? It's a lot easier to think about just writing your code the way it makes sense and

Dan Shappir [00:37:29]:
let this allow you to AJ AJ, before before you interrupt, again, based on 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 calls 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, stayed in, JSX out. We would need to worry and think about all these optimizations. Like, I don't have to think about the reconcile the reconciliation.

Dan Shappir [00:38:26]:
It happens for me. Likewise, I don't want to need to think about the. 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 and you don't want to be working at at that level.

AJ O'Neil [00:38:43]:
Yeah. Let yeah. I get that. It's I understand now. It's a very lossy conversion. It it it is it is more similar to a traditional compiler. It is doing the fun roll loops.

Charles Max Wood [00:38:54]:
Yeah. One thing that it comes to mind just, you know, from my background with, you know, rails or this or that, right, is that, you know, you wind up putting a lot of stuff in to your code. This 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 wanna 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 JSON from the server, it it surfaces it in this way because that's my job. My job shouldn't be, oh, I've gotta go in and make sure that all the i's are dotted and the t's are crossed because that's no fun anyway.

Charles Max Wood [00:40:02]:
And to be perfectly honest, the computer probably can do it better.

Joe Savona [00:40:06]:
Yeah. I think memory management is a good ex is a good analogy. Right, like, we you know, writing something like c plus plus or or Rust or c, like, a lower level language Now it's just like, you

 Sathya Gunasekaran [00:40:17]:
know, not

Joe Savona [00:40:18]:
my fault. Malecon 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 the lifetime of a value is is very hard to think about, because, you know, like, okay. The the this thing's gonna get shown based on all this parent context and when does it actually get should get it freed. It's way easier to just say, let let a garbage collector deal with that.

Joe Savona [00:40:51]:
And I think it's very similar with the with memoization.

Dan Shappir [00:40:54]:
Now now I have a question. Like, a lot of as we said, a lot of code bases already have used memo and memo inside of them. Now, ideally, I would think that once I move 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 and use memo inside of it. What do you do with that? Do you just leave 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.

 Sathya Gunasekaran [00:41:32]:
Yeah. That we yeah. That's exactly what we do. We Oh. Ignore the use memos. We optimize it as those doesn't exist. But we also check that have we optimized it similar to what the user has optimized it? Like, have or are dependencies different? Or

Dan Shappir [00:41:49]:
Mhmm.

 Sathya Gunasekaran [00:41:50]:
Is it less fine grade than the user? If it doesn't match up, then we bail out. So we make sure we don't change anything and progress, and we only optimize and improve. Oh, wow. Cool. Yeah. So it's actually once we are out of the experimental phase, I think it'd be more, safe to, like, remove these values callback, for the components that the compiler can safely compile.

Dan Shappir [00:42:22]:
Oh, yeah. It also takes care of used callback. I forgot about that. Yep.

Joe Savona [00:42:26]:
Yeah. Yeah. So one of the things that, yeah. But part of what we one of the things we kinda wanna do during the experimental phase is is get more, you know, data from from, you know, this is why we wanna 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 compiler generally able to preserve existing memoization? Are there, like, are there patterns where that where the compiler isn't able to preserve that existing memoization? And we should, you know, tune the compiler to be be smarter about those cases. Right? Because our our our goal, our eventual goal, is to get to where users don't have to do manual memoization at hopefully at all. But definitely in the experimental phase, we're we're probably not 100% of the way there. And so we kinda wanna get feedback to kinda tune and and get and get

Dan Shappir [00:43:11]:
all the way to that point. Now you mentioned bailing out. Can you elaborate a little bit about that behavior

 Sathya Gunasekaran [00:43:17]:
of the compiler? Sure. Yeah. The so the compiler assumes that the code follows the rules of React. Right? Like, there are certain rules that we, expect like props. You can't mutate props. You you must use the setter function to update state. Things like that.

Dan Shappir [00:43:35]:
AJ, it's like the the what's it called? The rules of, Python and, Go and and stuff like that.

Charles Max Wood [00:43:43]:
Of Python.

Dan Shappir [00:43:45]:
The Zen of Python.

AJ O'Neil [00:43:46]:
Go Proverbs, Zen of Zig.

Dan Shappir [00:43:47]:
So we now we have the Zen of of, React.

AJ O'Neil [00:43:52]:
That's that's good. I need to update my link of things with the the zens because I think I had what do I have for that for React? There is there are 2 the React was React React rationale? There are 2 documents for React that I have in the in the list of the thingies.

Charles Max Wood [00:44:09]:
Now I just feel like going and meditating on my components for a while.

Dan Shappir [00:44:15]:
So what are the rules? I I'm gonna jump us a little bit to the side because you I have to. You brought it up, Satya. What what are the rules of React?

 Sathya Gunasekaran [00:44:24]:
I think the main one is keep components pure that we already know. And all of the other rules, like, just fall out of that, which is don't mute it 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 use prefix for your hooks. Is there a list somewhere?

Dan Shappir [00:44:52]:
I can't.

 Sathya Gunasekaran [00:44:53]:
It is. We have a really great documentation page on all of the roles with examples. We also have a ESLint plugin that will catch, where you while it throws a React endpoint to the the the documentation, I think.

AJ O'Neil [00:45:10]:
Okay. Previously Okay. There was thinking and react, react design principles, and then there was a YouTube video, react today and tomorrow that were the kind of philosophical documents for react. So I I will try to find it wait. Do you you've got rules of React published?

Charles Max Wood [00:45:33]:
Yeah. Yeah. I just posted the link to Oh, you posted the link? Facebook, YouTube, and Twitch. I wish I wish x would do that, but it doesn't. But it's for for those that are watching live and are going, okay. How do I find this, or how do I go find the video? It's react.dev/reference/rules.

 Sathya Gunasekaran [00:45:53]:
Yeah.

Dan Shappir [00:45:54]:
Okay. Yep. I'm putting

AJ O'Neil [00:45:55]:
I'm putting it in the list.

Joe Savona [00:45:57]:
The bailouts?

 Sathya Gunasekaran [00:46:00]:
Should I Right. Yeah. So when the so the compiler 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 wanna be safe, and we wanna only optimize if we know it's correct. Yeah. That's that's the idea behind having bailouts.

Dan Shappir [00:46:31]:
Yeah. That's the thing I really love. Sorry. I I apologize, Joe. That's just I 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, React server 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. If your components are compatible with it, you just gain the benefit. If they aren't, nothing bad happens.

Dan Shappir [00:47:02]:
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 it's just upside and no downside. You don't need to rearchitect to change stuff. It's you just gain immediate value.

Joe Savona [00:47:19]:
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 wanna have to change the way people write React code. We want to just have something that that works out, you know, as as much as possible out of the box. That has always been the goal. You know, the to be clear, there are some ways that, you know, you can you can violate the rules of React in ways that the compiler doesn't detect. The the the canonical one is, like, put the violation behind a function call. Like, write some write some helper function that, like, flagrantly violates the rules and call that function.

Joe Savona [00:47:53]:
And, you know so for example, like, modify state inside of a helper function. We we we we don't know that yet.

Dan Shappir [00:47:59]:
Talk to you.

Joe Savona [00:48:00]:
Right. But, like, as as much as possible, right, we 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 runtime.

Joe Savona [00:48:25]:
And so we're working on some tooling to help kind of at runtime. Right? Kind of like even even like Wow. 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 auto memoization. This is really, you know, it's it's really 2 features. Right? It's for right now, it's auto memoization and the linting.

Joe Savona [00:49:04]:
But this also a it's really a platform for understanding your code and being able to change the way it runs, you know, what what's happening at runtime to be more optimal. So we're 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 could the compiler just do that automatically for you? Right? So for example, a lot of folks have asked about context selectors, which, the the idea there being sometimes you only wanna 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 why should we rerender the component that cares about domain when the domain didn't change? And so, a lot of people have asked for a context selectors to say, oh, let's help us target the updates to the components, that where their actual input data changed.

Joe Savona [00:50:07]:
Well, okay. We could provide an API for that, and the developers would have to adopt it, remember to use it in all the in all the right places. Or we could say, let's have the compiler do that for you. Right? And so the compiler gives us, you know, an an an a kind of a 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 kinda level up from there.

Dan Shappir [00:50:33]:
One thing that I would love to have, I don't know if it's on your road map at all, would be automatically generating the dependency map array for useEffect.

 Sathya Gunasekaran [00:50:44]:
Yeah. This is something we're thinking about actively, but it it can be tricky. It's the there are some valid use cases for not having all of the dependencies in the array. Right? So we're thinking of new APIs. And, yeah, in general, we're thinking about

Dan Shappir [00:51:01]:
Alternatively, if somebody I think these days you have to explicitly specify, a dependency at the very least an empty array. So maybe, like, in this 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 hot.

Charles Max Wood [00:51:27]:
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?

Dan Shappir [00:51:35]:
Well, no. If it's

Charles Max Wood [00:51:37]:
not there, then you would also assume it. And, yeah, then the then you have less clutter in your code.

Joe Savona [00:51:44]:
Yes. Yeah. So so, basically, I think, this really gets this gets this gets to the question of what are effects for. And useEffect is kind of it, Dan wrote a great, you know, a series of posts, that was all on the document date on the the react.dev 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 are should you just not be using an effect at all? For example, sometimes, people will do an effect where they'll kinda look at the prop. They'll keep some state. They'll look at the prop and if the prop changes, they like reset.

Joe Savona [00:52:24]:
It's like, well, 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 at to 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 useEffect lets you do in sort of on mount type of, event. And, another is synchronizing with synchronizing react state to some external system.

Joe Savona [00:52:52]:
And so what we're looking at is kind of under really understanding these these specific use cases where you really need an effect, and then crafting the API there. But, you know, I think what what Satya was 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 there 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 array.

Joe Savona [00:53:22]:
You'll list out a couple dependencies. And then you'll I I wanna skip I wanna skip that one. So you'll you'll do an ESLint, you know, disable, rule. Tell tell her tell the React winner 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 a 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.

Joe Savona [00:53:47]:
It's like we're we're definitely working on it because we we understand that, we we wanna do better on effects.

Dan Shappir [00:53:51]:
So two things about that. First of all, when you disable the rule, you often disable it for you usually disable it for the entire line, which means that now if you make other mistakes in that line, you they actually won't get caught.

Joe Savona [00:54:03]:
Exactly. Right. And so that's problem. Right?

Dan Shappir [00:54:05]:
Yeah. That's problem number 1. And problem number 2 is that if you're doing it, you're probably doing it for the wrong reason.

Joe Savona [00:54:12]:
That is another yes. Exactly. Right. There are there are legitimate use cases for doing that, and that's but that's something that we we really wanna work on, a crafted API for it to, like, help developers really understand. Like, did you did you mean to do this, or did you mean to do that other thing?

Dan Shappir [00:54:28]:
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. And even, I guess, when you don't lend, bailout, you might provide in informative linting messages. To me, that's almost as valuable as the compiler itself. If if 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, etcetera.

Joe Savona [00:55:03]:
Yep. Absolutely.

Charles Max Wood [00:55:04]:
Yep. Well and I like the you may cause problems. Right? It's not just a, hey. This is you know, we we prefer 2 spaces instead of tabs. Right? It's, hey. This this may actually surface bugs.

Dan Shappir [00:55:20]:
Now you mentioned something, while back at the beginning of our conversation, which kinda piqued 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 developer's 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?

Joe Savona [00:55:59]:
Can you can you describe a bit more about, like, what what you mean there?

Dan Shappir [00:56:02]:
Well, theoretically, you could create some sort of, you know, associate some, I don't know, some hidden property to an or to the object that you create, and that tells the reconciler to behave somewhat differently in certain scenarios?

Joe Savona [00:56:19]:
Yeah. So I think I think well, we've we've kinda thought about a couple things in that general realm. One is that well, you know, we talked about how the compiler auto memoizes. But one thing to note there is that when we are talking about auto memoization, we actually don't add use memo calls. So so there's, we're actually, like, producing just, like, an if and if else block that's gonna says, like, if the inputs to this computation have changed, recompute it. Otherwise, reuse the the cached value. And there's other things that we can do where we can say, okay. The user wrote, for example, a useEffect, but maybe the output of that doesn't actually have to be a hook call.

Joe Savona [00:57:02]:
Maybe it could just be something that, like, that does a more targeted update. So these are some of the things we're 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 what the intended behavior is, we can start changing how that works at runtime more dramatically. So it's like, so the compiler is kind of step 1 of we have the existing React runtime. We're gonna use a use a compiler to understand your code and kind of optimize with the current runtime. Now we have that baseline of compiler and runtime, and now we can start evolving them together to actually change the runtime and how the runtime 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 have to support, like, if if if you have a if you have a component that that violates the rules and we can't compile, we'll still still need a way to support that, but we can start optimizing for it.

Joe Savona [00:57:59]:
If you do follow the rules, can we make that even faster? So that's kinda where we go next. But the first phase is just getting the compiler to be stable, obviously.

Dan Shappir [00:58:08]:
Now another question is currently, the input is valid. Well, React JavaScript or React TypeScript. And 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, React's, original creator, Jordan Wolk, actually also created the the reason programming language and ideally envisioned all the React developers, not only embracing React, but also replacing their JavaScript with reason and health hence solving all the referential equality stuff because, reason is an, you know, function language with immutable data structures. So are you thinking of one day me maybe, you know, somehow instead of in one fell swoop, like, you know, gradually moving us over to a React script?

Joe Savona [00:59:15]:
Yeah. So, we think about we think about React very much as like a programming language. It it has its own kind of semantics. For example, it has concepts like components and hooks that that obviously don't exist in in JavaScript. We but we think that the thing that has made React so successful is that we embrace JavaScript. And so, you know, while we think about the design of React from a pro 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, TypeScript, and and TypeScript is an is an amazing language. We love it.

Joe Savona [01:00:02]:
We're actually the compiler is written in TypeScript, by the way. So huge fans of TypeScript as well. Nothing

Dan Shappir [01:00:08]:
we really Rust? Nothing Go? How dare you?

Joe Savona [01:00:12]:
I know. I know. Well, we can get into the Rust question, in a little bit. But, but, yeah, we we really want us to kind of let support developers, you know, meet developers where they are. Like, you know, Tom Tom Latino, our our the former, manager and and director of React Org, 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 I don't really foresee us creating a React script.

Joe Savona [01:00:44]:
We have been on the flow side, been experimenting with some custom syntax for React. So this is like, you know, it's 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 were if they were in the language. But that is something that is is purely optional. If you use Flow, you can, you know, you can opt into these, like, component or or hook keywords. But really React is always gonna be about JavaScript, and supporting and supporting JavaScript from, you know, that that's that's like that's our bread and butter.

Dan Shappir [01:01:19]:
Another point that I have to bring up, and we actually kind of answered 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 than get fine grain reactivity? What's your answer to that?

Joe Savona [01:01:51]:
Well, the really simple answer is, why rewrite your application to use signals when you could get fine grain reactivity by just adopting a compiler? I I think, you know

Dan Shappir [01:02:00]:
That's a great answer.

Joe Savona [01:02:01]:
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. The you write you create you explicitly create, you know, with with APIs like 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 on at the outside that are saying, okay. Whenever one of my inputs changes, I'm gonna take some take some action on the outside world like log 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.

Joe Savona [01:02:46]:
That's the, 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 meta program. 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 2 phases going on that you've had to think about. And so you you see things like, oh, I you talk about people talk about, oh, like, you can't destructure props or you can't do this or you can't do that. And it's because there are there are mistakes. They're easy mistakes to make where you're accidentally accessing a value at the wrong phase of the program and now reactivity gets lost.

Joe Savona [01:03:33]:
Right? You also have to think about a lot of the a lot of the kind of signal space frameworks will distinguish between a true, memoized, like, where 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 the short circuit reevaluation. But if you just use a Lambda, you don't get that short circuiting effect. So there's a lot of subtleties you have to actually think about, when you're 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 our kind of ideas, okay, one of the things that has made React so, you know, I think so successful and why so many people are able to kind of ramp up on React and be productive. I have a friend who just recently learned to program. And and, you know, like, 1 week they're saying, oh, React seems really complicated. They, you know, they just started looking at it.

Joe Savona [01:04:30]:
And then a couple weeks later, like, oh, I built a UI. Like, it it works great. Like, I love it. Like, I love use state. It's so easy. Like, I think there's something very that that 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.

Joe Savona [01:04:50]:
But things like it's just it's normal JavaScript values. You can do things like early return. You can destructure your props. All these things that you expect to work still just work because it's the same React you know, and it's just under the hood. It's working a bit differently.

Dan Shappir [01:05:03]:
I think that's really the key, and you've hit the nail on the head. That's 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, 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 in other way. I really like the React approach, and of like I said at the very beginning, that in an ideal world, it's just, as you said, Joe, state in, UI out. The whole UI, thing is is just this effectively functional composition.

Dan Shappir [01:06:13]:
And that kind of gets lost with the signal approach, which is why when people tell me, hey. Like, when is React gonna get signals? And even though I don't work at Meta, I'm I 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.

Joe Savona [01:06:34]:
Yeah. I will clarify that, you know, just a bit. I mean, you know, there there is a a proposal out, to add signals as a TC 39, you know, to to to to the language. You know, obviously, if that becomes a standard. Right? Just just like we have, we've now have used to and you can pass a promise and you know, use promises with, with re in React. Obviously, we wanna 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 in a component of Playa. So, obviously, in that sense, we'll support signals, right, if they become part of the language.

Joe Savona [01:07:11]:
But in terms of like using them as a core feature for how to do state management and updates in React, yeah, 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 the current React model view as a function of state, plain JavaScript values, normal JavaScript idioms like early return, if else, loops, things like that, that that's an easier way to reason about applications. And that's where we we expect to to con to continue going with React.

Charles Max Wood [01:07:34]:
Alright. I'm gonna jump in here because we're kinda getting toward the edge of end of our time, and I wanna 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 wanna 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 ask this question. When do you think it's gonna go to the general public? Right? Then I get the don't do me like that, Chuck.

Charles Max Wood [01:08:09]:
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 wanna answer that.

 Sathya Gunasekaran [01:08:20]:
Right. So I think, yeah, right now, it it is an experimental state. You can npm install the babel plug in. It's super easy to add it to the babel config. Just add the compiler.

Dan Shappir [01:08:31]:
Okay.

 Sathya Gunasekaran [01:08:31]:
And it should just work. And we we have we're still accepting more partners to the working group. We we want really want feedback from the community. We wanna understand how people are using the compiler, how the compiler works outside of meta and get feedback, and improve the compiler to make it stable. I think as 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 stable soon.

Joe Savona [01:09:10]:
Yeah. Just to add on, think a couple some of the things that we're thinking about are, the you know, getting feedback from the community as Satya said. We are working on effects and like that kind of ties in a little bit to that work. The 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 you know, the packages that I I that I 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 kind of leave node modules alone that also makes builds faster. So it's kind of win win.

Joe Savona [01:10:02]:
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 one of the things we have to kind of figure out is we've really got a good a really solid strategy in place there so that everyone can start adopting it across the ecosystem.

Charles Max Wood [01:10:23]:
Super cool.

 Sathya Gunasekaran [01:10:24]:
One thing that I really missed one I missed that I wanna give a quick shout out to is the health check script. So we have a script that will, like you if you just run NPM, React compiler health check, it will bond the compiler against your code base. And it will, like, say, we were successfully able to compile x mod of components, found these libraries that doesn't work well with the compiler, so it'll give you, like, a status update. Like, what is that. Yeah. Like MobX.

Joe Savona [01:10:57]:
And definitely, you know, the ESLint plug in, also experimental, but I think, you know but that one because it's not changing your output code, 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 bases, you know, starting today.

Dan Shappir [01:11:15]:
So installation is just n b m I, basically?

Joe Savona [01:11:20]:
And adding it to the babel config. Yep. Alright. So NPMI and then add it to your babel config, add it to your link config. Yep.

Dan Shappir [01:11:26]:
And, you know, we kind of ran out of of of time before we ever got to, Rust and Go. So I guess we will just need to bring you on some You have a 2 minute answer

Charles Max Wood [01:11:35]:
if you want.

Joe Savona [01:11:37]:
Yeah. The real quick answer is, we know that people are moving to alternative build systems that are that are based in in Rust and Go. Like, ES build is esbuild is awesome. SWC is great. O there's o x 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, it does make it hard as a tool author trying to produce something. It's like, okay.

Joe Savona [01:11:58]:
How do we how do we ship this? Like because if we if we write it in Go, then it works in the s build, but it doesn't work in the other one. There's kinda 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 a node binding. We can provide a go binding. We can obviously provide bindings to Rust based tools. That is we have a 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.

Joe Savona [01:12:25]:
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 Babel. Thankfully, most of the tools, things like Next. Js, 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 the babel plug in into that process, and it it just works.

AJ O'Neil [01:12:49]:
Well, just just be careful because, you know, Rust is kind of old news, and Zig is the new hotness. And you wouldn't wanna spend all that effort just to have to rewrite it again next week.

Joe Savona [01:13:00]:
Yeah. I mean, yeah. So I what I would just say about that is, Zig is a really cool language. It's got some 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 sort of a bunch of different things, especially around build tools. Relay compiler, which I worked on, is written is now written in Rust. We we rewrote from JavaScript to Rust a while back.

Joe Savona [01:13:25]:
And so we 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 the

 Sathya Gunasekaran [01:13:32]:
hype and the ecosystem.

Charles Max Wood [01:13:34]:
Cool. Alright. 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?

Dan Shappir [01:13:43]:
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's case recently, you know, with the quality of the movies they've been putting out. You know, I I said that, the the only good thing I could say about Atlas was that it's better than Rebel Moon. And I can't I can't say anything good about Rebel Moon. So 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.

Dan Shappir [01:14:29]:
And, maybe I'll finish it today. I don't know. Maybe so later in the week. It's, Godzilla minus 1. Now it's really surprising to me because I 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 was a soldier doing a Japanese soldier during World War 2.

Dan Shappir [01:15:10]:
He was actually a kamikaze pilot, and he kind of chickened out. It was really at the end of the the war. Basically, like, literally the last couple of days, everybody knew they they were losing. So he literally just didn't wanna die. And and he's living with the guilt, and there's a whole thing of Japan after the war. And, and, you know, and the fact of the the, nuclear bombs and, like, rebuilding the country And it's much, much more interesting and engaging to me than the actual monster. And that's why I'm I'm enjoying this movie so much, and I would highly recommend it again. I'm talking about just the first half of the movie.

Dan Shappir [01:16:01]:
I haven't watched the second half. And those are my picks for today.

 Sathya Gunasekaran [01:16:06]:
My

Charles Max Wood [01:16:07]:
Cool. AJ, what are your picks?

AJ O'Neil [01:16:10]:
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 learner's 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 I think, Safety Motorcycle Safety Foundation. And they make the handbook that pretty much all 50 states use. So aside from, like, I don't know, Utah and Alaska that have a different BAC level and, like, Arizona that, I I don't know. You know, 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 learner's 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 it 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 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 your thing.

AJ O'Neil [01:17:44]:
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 1.7000 stars. So we have hit the inflection point. The the the line goes up. It hit the hockey stick.

AJ O'Neil [01:18:24]:
So after many years of of, working on it, it's really cool to see it's arrived.

Dan Shappir [01:18:31]:
So I think the React team counts stars just as galaxies, you know, the amount of stars. Yeah.

 Sathya Gunasekaran [01:18:39]:
Yeah.

AJ O'Neil [01:18:41]:
But it's awesome. For for those who don't know, it's just a way to install, tools that doesn't require a package manager and is platform independent. So it can work in Docker, Ubuntu, Alpine, Mac, BSD, and Windows

Charles Max Wood [01:18:56]:
find it?

AJ O'Neil [01:18:56]:
Many of the tools. It's it's, web install dot dev.

 Sathya Gunasekaran [01:19:00]:
Okay.

Charles Max Wood [01:19:03]:
Alright. 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.

Charles Max Wood [01:19:16]:
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, like, a game, a board game, or a card game. And, this one's called Sleeping Queens 2. 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, 6. And, it's a really simple game. You can play it in, like, 15 or 20 minutes.

Charles Max Wood [01:19:50]:
I think you can play it up to 5 players. And, essentially, what you do is you play different cards. And, in sleeping queens, what you're doing is you're 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 Right. So, anyway, it's it's a fun game.

Joe Savona [01:20:26]:
Our family loves Sleeping Queens.

Charles Max Wood [01:20:28]:
Yeah. Haven't but but it gives people an a flavor of how complicated it is. It has a weight of 1.5. So you know and it's a kid's game. So it's it's a simple game. It has just enough complexity to make it interesting, without making it overwhelming for a 6 year old or an 8

 Sathya Gunasekaran [01:20:55]:
year old. So I'm gonna pick

Charles Max Wood [01:20:57]:
that for my board game. Now I'll post the board game geek, listing here. 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.

Charles Max Wood [01:21:26]:
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 them hugs, and I can keep track of my habits and stuff like that in it. But one of the things that I picked up the about a week and a half ago is Duolingo. And, a lot of people know what it is. It's free. Right? I mean, it shows me ads periodically, but whatever.

Charles Max Wood [01:21:59]:
But it lets you 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 I really kinda wanna 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 2 years years and realized that my Italian's gotten fairly rusty. And so I basically do 3 lessons a day. I don't do them all at once because I don't wanna, 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 or evening.

Charles Max Wood [01:22:41]:
And, Yeah. I'm finding that the Italians coming back to me. And what's funny is, is that, my Italian vocabulary is very strong in a couple of areas, 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 nonexistent. And so I've been picking up vocabulary and learning how to talk about things that I haven't really talked about in Italian.

Charles Max Wood [01:23:14]:
So that's been very fun, and I'm kind of at different levels on each one. But, it's it's easy. It's anyway, I've I've been very happy with Duolingo. 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.

Charles Max Wood [01:23:44]:
I'm happy that it's free. And, yeah. So I I can order, like, 4 things in Japanese at a restaurant. I I can carry on a very rudimentary conversation with people in French. And then, yeah, I'm talk 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.

 Sathya Gunasekaran [01:24:12]:
Well, the what what's the context for the epics?

Charles Max Wood [01:24:15]:
So just 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.

 Sathya Gunasekaran [01:24:29]:
Cool. Yeah. I guess I can do, like, a spot themed one. So there's, right now I don't know if you've if anyone's familiar with the game called cricket. I don't think it's I don't know if it's popular in American.

Dan Shappir [01:24:47]:
I know of it. I know it's a it's a sport that can last a couple of days.

 Sathya Gunasekaran [01:24:53]:
Right. There are different versions that do it. There's there's one that lasts for, like, 5 days. There's one that lasts, like, the entire day, and then there's one that's, like, a couple of hours long or, like, 4 hours long. Right. So there's there's a world cup happening for that, for the the really short version. It just started this weekend, and it's happening in the US. I think they're trying to, like, make it more, proper in the US.

 Sathya Gunasekaran [01:25:22]:
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's generally very good at this scheme. And they went all the way until the finals and then they lost, which is very heartbreaking. So I'm hoping that they win this time. So, yeah, that's that's my pick. And then, I guess, also another sport related one is the Euros are starting next week if you're into football.

Charles Max Wood [01:25:56]:
Now you're speaking my language.

 Sathya Gunasekaran [01:25:58]:
Yep. You

Charles Max Wood [01:25:58]:
mean football, not football.

Dan Shappir [01:26:00]:
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.

 Sathya Gunasekaran [01:26:10]:
Right. So I'm in London, so I have to support England for the Euros. I'll be rooting for England.

Joe Savona [01:26:17]:
Have to.

 Sathya Gunasekaran [01:26:19]:
They are also very good.

Charles Max Wood [01:26:21]:
They are very good.

 Sathya Gunasekaran [01:26:24]:
Yeah. So those are my picks.

Charles Max Wood [01:26:25]:
I mean, I can't talk. I always support Italy in the last few years. I've been very, very disappointed.

Dan Shappir [01:26:31]:
But but England never actually wins as I recall.

 Sathya Gunasekaran [01:26:35]:
That's true. They went to the finals and, well, Italy won. Yeah. Yeah.

Charles Max Wood [01:26:41]:
Alright. Alright. Good deal.

 Sathya Gunasekaran [01:26:43]:
Joe, you're up.

Joe Savona [01:26:45]:
So sticking with the theme of the podcast, for those who are curious about compilers, Robert Nystrom, Bob Nystrom wrote a great book called Crafting Interpreters. It is available in, you know, dead tree form, in electronic form. It's also, I think, there's a free version on crafting interpreters.com. 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, very JavaScript like language. He kind of walks through building a 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 I mean, like, just I can just barely read it and know what's going on.

Joe Savona [01:27:31]:
And I was I found it, like, completely accessible. It's just very very obvious what, like, what what was happening. So highly accessible book to kind of understand that the basics of what's happening in the compiler and the interpreter.

Dan Shappir [01:27:41]:
Well, now we've got to mention the Dragon book if you want something that's totally inaccessible.

Joe Savona [01:27:46]:
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, Safia has an amazing blog, and he's actually written about some, in like, some of the details. So re recompiled dot dev. Right? So check out Satya's blog for kind of some more details about how the compiler works on the inside. My my life is basically the compiler and then, like, being a dad.

Joe Savona [01:28:12]:
So, plus plus one to sleeping queens, as as a pick.

Charles Max Wood [01:28:16]:
Alright. 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 Satya on the Twitter. Where do they find you?

Joe Savona [01:28:29]:
So I'm on Twitter as een_js. And for the compiler, you can go to react.dev/learn

Charles Max Wood [01:28:38]:
/

Joe Savona [01:28:38]:
react dash compiler.

 Sathya Gunasekaran [01:28:40]:
And, I'm underscore jisatyaonnx?

Joe Savona [01:28:44]:
Oh, yeah.

Charles Max Wood [01:28:45]:
Awesome. Alright. Well, thank you both for coming and talking through this with us. We we kinda had to figure our schedules out, but it's so fascinating. So yeah.