Hi everyone, Thanks for joining us. We are here at React Summit 2025, joined by Lydia Halley. We'll get into some talks with regards to React Summit and we'll end off with a little bit of more ideas and randomized questions. So let's get into it. Let's talk about React Compiler. You just had your talk. I'm wondering why does React Compiler exist in the first
place? We often have to like memoize stuff and React just because of how it's rendering system works and that's just how React is designed. But for a lot of developers that's definitely a burden having to use, you know, use memo, use call back every time there is either an expensive function or an object. So first you have to identify like OK, will this part rerun whenever the parent component re renders? Or is this like like memoizable enough?
And as I said in my talk, like it's very easy if you don't have the right like Linder plugins to accidentally forget to add stuff to your dependency array and a use memo, which then breaks the entire memoization chain. Or what I have sometimes had is that I add a value to the dependency array, but it's like an always changing value. So then you're breaking your entire memoization that you had for that component.
So All in all, it's just pretty error prone and it just requires a lot of like maintenance, especially as your code base grows. So rec compiler kind of just takes it away from developers. It's more shifting that responsibility to React itself. It's like, OK, we know that you often have to like memoize stuff in your rec components just due to the way that our rendering system works. And rec compiler automatically, you know, helps with memoizing the right values in your components.
So developers don't have the burden of that anymore. And the nice thing with compiler is that it can get really granular. So with use memo, of course, we could sometimes maybe memoize like an expensive well computation or with use callback and expensive function and so on. But as I also said in my talk, like where compiler is able to memorize JSX or really tiny variables that normally developers wouldn't really
memorize with news memo. So it's both easier with compiler because we don't have to think about anything. We can just write clean code. But then also in a lot of cases it's it gets even better performance just because it's able to memorize more than what we normally would if we would use Memo. So I understand it's going to solve it kind of in an automatic way. Is there still a room for like using use callback or use memo then from a developer side? Yeah, you can still use it if
it's still in your code base. React compiler would either automatically strip it out and then you know, because we have a use memo, or use callback and then the callback function, it would just strip out use callback and just use that callback function instead. Also, in a lot of cases you can just enable rec compiler and if you don't want to memoize the specific component, you can use the use no memo directive on top
of that component. So in that case, you're kind of opting out of, you know, just memoizing that component and keeping your own manual memoizations in anyways. But yeah, generally if you want to move over to compiler, I would say keep all the use memo, use callbacks in there in case you do want to turn it off eventually so you don't have to like undo all your previous undos. Yeah, because compiler will take care of that automatically.
Interesting. I I like the idea of not having this cognitive load of like rendering cycles and then figuring out what to use callback or use memo for. You just want to write code. Yeah. The only additional thing now is like I have to actively say, OK, if I don't want React pirate React compiler to kick in.
Is that additional? I mean, you enable React compiler, so if you don't want it at all, then of course you don't have to enable it. But yeah, if you don't want it for certain components that you can use the use no memo directive and it'll skip that specific component from being memoized like. But of course, also like if you break any of the rules of Reacts or like I said, like more, you know, complex patterns and it's not sure how to optimize it, compiler will always choose the safe side.
It won't try to, you know, just like memoize something just to memoize something. Because if that goes wrong, that would really break her out. Like if you accidentally have a cash value that should, you know, be recalculated in every render. So it'll always pick the the safe path in that way, yeah. I like that. How easy is it to set it up either through an existing code base or when starting something new?
So first you might run NPX rec compiler health check that will just tell you like, OK, is this code base compatible with compiler or does it have any, you know, dependencies in there or any breaking, breaking the rules of React that it won't
work. Then there's also the Islin plug in, and this is what most developers will use in their code base to work with compiler because this will automatically tell you, you know, if what you're doing in the current code base might break what compiler would optimize. It'll also, you know, tell you like, oh, maybe don't use this hook in that case and so on. But yeah, then then it's just turning it on in your build pipeline.
So yeah, in Expo could be in your app Jason in next GS, it could be in your next config file in Veet. They also have because it's just a Babble plug in. So you essentially just add it like as a Babble plug in and then it just runs every time that you build your code, but also on HMR. So if you do want to update it just in development, it will also run there. For me, it's interesting how this is going to move and kind of migrate because right now people have this cognitive load.
They have to think about it. And then when you use React compiler, you don't have to think about it. All of a sudden, will people still like use it, you think? Or will they use it more consciously? Or it's just going to be out of the tool belt because you don't
have to think about? It I mean I feel like eventually people won't have to use it anymore, but like it is definitely like backwards compatible because of course you cannot like a lot of COVID yeah for like so many COVID stuff use memo and it's not like you can only use compiler if you don't take out all these use memo use call back calls Viano eventually will hopefully end up with just really clean React code that is also really performant and we don't have to think about all
this re rendering stuff and especially on low end devices, it will definitely make a big difference compiler because I feel like you know, if you're running it on a really fast MacBook or really fast iPhone, having those couple extra milliseconds on the website is like whatever, but of course if you're running it on like a low end Android device, you'll definitely see a big big like performance increase in how like in UX and user experience so. Yeah, it's been a while since
I've been front end development, but re rendering cycles as code bases grow, we're always a pain. Yeah, like a huge pain. Exactly, especially as it grows in with like new members on your team and they have to really identify like, OK, what is this, you know, just to be focused on use memory use copy specifically now like, OK, but why do we need this dependency? And if you change anything, you need to add it to add it to the
dependency rate. It's just and of course like there are linters for it and like in VS Code you can or in cursor you can see like Oh yeah I have to add it but still it's just like. It's like tooling around this problem that we have. Exactly. Yeah. So again, like it's shifting kind of the responsibility from the developers to wrecked itself I. Like that a lot. Is this going to solve most than re rendering problems or what remains after you've incorporated react compiler?
I mean, I feel like eventually they might integrate it with other it. It could be optimized for other kind of rendering engines as well, JavaScript engines. So in that case, you can run re echoed really fast if you're running it on, for example, like Hermes, stuff like that on
mobile devices. Also, just having compiler in general, of course, it makes sure that you're not breaking any other rules of React that might be kind of forgiven now, but compiler just won't work if you're not like if you're using those. So in that sense it could also help you just to write better React code. I feel like that's a trend in the industry. Like we come from frameworks and a lot of cognitive load.
And now we see that the simpler it is for developers to execute and kind of use code as a means to an end to achieve something, the better. It is also for maintainability, for easier for people to step in, specifically with regards to conventions. If this is a trend that I think is going to hold strong, yeah, But then also everything is going to be kind of solved because you don't see the rewrites, right? That happens. No, it all happens and you also get to keep the source maps from
your original code. So when you're opening dev tools or anything like that, you won't see that it changed the code because the original source map. So the original kind of structure of your components is still there. So that's super nice that you don't have to.
I mean, everything I presented today, you can just forget about it. Like it's no one has to ever think about it. But just the fact that it happens and also kind of the engineering that went like to to build compiler, I find really impressive and a lot of respect to the people of Meta. Can you touch a little bit about that? Because I mean building this thing and then keeping in mind all the existing code that is
there. With regards to backwards compilability, that is always a challenge in and of its own. For sure. Oh, what do you want me to touch on specifically? Mainly how they created this thing because it's it's a lot of logic that goes into compilers. It's trade-offs with regards to performance.
Yeah, I mean, I'm of course not entirely sure how they like how they start it and where it is now, but compiler itself, I mean, if you know, like, I guess the basics of compiler theory, it's just like, I mean, I'm not even sure if it's like if compiler is the right word. I know there's a whole discussion around it because it's not like we're compiling it to a, you know, lower end language, which is normally what compiler is. It's almost like we're transpiling it back to JavaScript.
But yeah, no, the whole process, I mean the fact that they're using, you know, first the high intermediate or high level intermediate representation, that's pretty obvious. But then they're also using like stuff like SSA. So there's a single static assignment to just make sure that it really understands the data flow within a single component. And that's pretty complex.
Like it it shows that, you know, the people I compiler really thought about getting the best performance out of it as well. Yeah, I'm not entirely sure how to answer that question is like a big one, but. Yeah, they get that. With regards to kind of working with React, this was always a pain point. Now that it's kind of solved already, so is it production ready? Let's start with that first. No, it's a release candidate.
Release candidate? Yeah. So as of April 2025, yeah, it was baited before that. So people can use it in their apps and see if it works. I mean, Meta has been using it internally and a lot of their products. And of course, I'm not entirely sure if they're using the exact same versions of if they're using kind of internal modifications of that to make that work and that Instagram and stuff like that.
So people can like incrementally move over and see if it does anything for the apps because like it's so easy to just opt out, but just not enabling it anymore. So it's it's easy. But so far, as far as I know, no other like bigger companies have really turned it on to really see to get with metrics on like how much it improved. I know for like Instagram, I believe they got like a 30% improvement just turning on compiler. That's really good. Yeah, yeah.
I'm not sure for any other numbers so far till it's like out of stable I guess. Yeah, if it really fixes this pain point of re rendering which I think is is bringing this huge cognitive load, what do you think is still missing then? What are the frameworks offer with regards to developer experience or people creating code within React? Do you still see any pain points?
It's a good question. Oh, I feel like because I, I don't even think you have to really use like state anymore at some because like if it can just track reactivity within the variable, then it would just do that automatically for you. And that's of course also why a lot of people liked stuff like spells and stuff. You could just kind of like declare A variable. It was closer to HTML at that
point. Other than that, I kind of only see wins for React, which I know sounds really like 1 sided, but more people are moving over to React. You know, the community is growing, the tooling is getting easier and better, the code base is getting easier to maintain.
I don't really see any big like downsides to React anymore at this point because that was definitely, you know, having all these hooks and then having to memorize that was for me the biggest pain point is seeing how other frameworks solved. It was definitely was like, man, that looks nice. Say. Hopefully once compiler is stable, we'll also get to that point.
It's funny that you mention that because when a lot of new frameworks were introduced, it's like, OK, here's how you would do it and react and look how clean it is. Yes, exactly in this kind of newer framework. Yeah. And that's like, look at us. We can also do it, yeah. Yeah, I mean, I feel like a lot of frameworks, they come and go. Some stick a little bit but React still stands tall I feel like. Yeah. And people have questioned it a
lot and it's only growing. So no, I'm confident that React will only get better, Yeah. Yeah, nice. So would you recommend then for people to whenever they start a new project, to pick up React comparing to other frameworks? Or is there still a use case for the other frameworks? There's always use cases, but I feel like having React and then also, you know, it works also on React Native. Like you kind of have the entire spectrum.
You know, you have like web, you've got native, you've got like other integrated devices, you know, like like the metaquest or like all these things. To me, that's just the biggest win in React and it's just the community and the information around React, the, the responses that cursor and ITT give are often by default React as well. So like a lot of LLMS are trained on React as well.
So it's just the easiest one. Of course, now with hooks there was like, I guess a steeper learning curve. A lot of time in React I don't really because like I learned it back in 2015. So it's difficult for me to know how people would approach it nowadays when they don't have any experience. Yeah, like when you don't have to think about hooks anymore or like memoization, it makes it easier for for everyone else, for beginners to get into it.
So that's very exciting. Yeah, I think that's important, especially for languages that have this level of maturity to still be accessible for new learners is incredibly important. Exactly. And that's that was definitely difficult with folks, I felt like. Cool, Awesome. I have a few random questions on the table. They're not about React, they're not about React Compiler. They're more so about you and your opinion. I'm going to let you draw one. All right?
Do you want to point to 1? And then I'll pick it and I'll read it. This one. Going with my intuition here, but it's never right all. Right. What's one tech trend you wish, which is go away? Yeah, AI generated code vibe coding. Vibe coding specifically. I don't. I feel like a lot of the time the code still that it produces, it's just not great.
I love using these tools like cursor and stuff to reverse engineer code bases and when I'm starting something new, I could just get a really quick overview of everything that's happening in the code and where it happens. But still the code that AI generates often for me is it's just not good. Like it's really good to prototype, but really production ready code. It's just not there yet. I'm sure it will be there pretty soon faster than we all expect, but at the moment it isn't.
And you know, I'm happy that people can get out the ground, I guess with their ideas using vibe coding and stuff like that. But I have yet to see a product that actually lasts longer than a couple months that was completely built with just AI. Also, I feel like it, yeah. It just gets of course, like the normal was like difficult to maintain because you don't really know what your cut is doing, blah, blah, blah.
But I personally, I feel like it's easier for me to get burnt out on a project when it's entirely made with just AI because I feel that's of a connection to it. And the moment I feel like I'm not really in control for what like I'm working with or that I don't really understand what it's doing, I'm also just less interested in it. And that's just of course, my very personal opinion.
People are of course very different, but I feel like people should still see not necessarily pride but also necessity in writing your own code. Because a lot of time, I guess some people it might make you feel the bad when they're like, oh, I could have just vibe coded this, push something out much faster, hit all this MRR, whatever, you know, people are tweeting nowadays. So like, oh man, I could have been a millionaire by now. It's like, well, not, not really.
Like, yeah, I mean, maybe if you had like a good idea and you actually also, you know, change the generated code yourself, then for sure. But you cannot just rely at the moment on the entire output of a generated code. So I mean, I'm not wishing it would go away. I'm just saying it's not quite there yet, so people shouldn't think that it's, you know, the AI is going to take all of our software engineering just yet. But this will age terribly.
I'm sure that like I will look at this in five years and pour it and like box on the street because like it took my job, I guess. Do you think it's going to make for better engineers or for worse engineers? Because I feel like indeed people go on this autopilot mode. It's just code that is generated and you just accept or you have to consistently read and you don't think anymore. I think it depends on your
initial motivation. Like if you were interested in computer science and really building the project, it would definitely help can make like hope you become a better programmer because that's when you already kind of have this you want to learn. And then I can of course do that so much faster. And it's such a more kind of gratifying way where you don't have to just go to Stack Overflow with like 15 year old, you know, answers that are no longer applicable, stuff like that.
But if your goal is more to like, OK, how can I make money quick? And then, you know, yeah, how how would I code it? Then? Yeah, of course. Like even if you had some coding experience, I still feel like it would definitely make you worse because you're not really thinking about the patterns. You might not stays up to date with the, you know, new features that are in the framework, which is fine if you're just relying on AI, but still like, yeah, you're working with code that's
not yours. I find that too risky, I guess. But I feel like you could say that in general about just AI
now. You know, people are kind of just like moving their thinking over to Jet GPT or everything else is like, I feel like in a couple of years from now, critical thinking will be the most valuable asset if people are still willing to put the effort into just thinking critically, their own thoughts, not just, you know, like kind of pushing it to AI. So yeah, it'll be interesting to see what the, yeah, what the junior developer will look like
in five years from now. I have no idea if they will still exist because I feel like a lot of junior tasks are pretty much just AI tasks. Like, that's pretty doable, but people still have to learn. So yeah, it's going to be interesting. Yeah, the learning curve is going to be different, right? Because if a lot of the easier tasks that help you get up and running are solved, then there's
nothing left. Yeah. And like how, yeah, I'm not sure how companies would hire those people because it's like you're not really needed, but you still need the work experience. So that's that's another issue. I guess that it's going to be interesting to see how that turns out. Yeah. And we also talked about, I mean, mainly React compilers solving this kind of cognitive load. But with AI, you still have have the same cognitive load because it spits out code that is for humans, right?
It's not machine code. It's what we've created to kind of make better abstractions for ourselves to be able to create code so the cognitive load doesn't decrease. I feel like you just have to read more and trying to understand more, or indeed just blindly accept whatever's there. Yeah, I feel like that's what most people do anyway. There's like shirt works. I feel like, yeah, very lazy.
And then also, yeah, it's just, I like more disconnected to the product that you're building because I don't know. I still, yeah, I don't know, like I I'm sometimes just almost proud of the code I write. I almost see it as like my little, not like little baby, but like just something, you know, my own creation. I like it and you can be proud of it and I feel like you just don't have that or I don't not, I don't want to generalize, but I don't have that with AI.
I'm just like, you know, like people expected this with me, but it's not like I can take any pride in it. That's the sense. No, I do feel completely what you mean. Sometimes you or at least for me, an existing code basis. I developed this feature and I'm really happy with how it's, I don't know why, what what intricacies there are, but I'm really happy with what I created. Yeah, yeah, yeah.
And I did that. It's not like I used something to generate something and then it's is my creativity. Exactly. Yeah, you can see your own thought patterns on the screen. That's. Cool. Thank you so much, Olivia, for joining us. We'll see you on the next one.