How React Compiler is Changing Frontend Development | Lydia Hallie | Beyond Coding Podcast #205

Hi everyone. Thanks for joining us.

We are here at React Summit 2025, joined by Lydia Hallie.

We'll get into some talks with regards to React Compiler*, and we'll end off with a little bit of more ideas and randomized questions.

So let's get into it.

Beyond Coding.

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 memorize stuff and react just because of how its 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 callback every time that there is either an expensive function or an object.

So first you have to identify like, okay, will this part rerun?

Whenever the parent component rerender is or is is like up like memoize will not.

And as I said in my talk, like, it's very easy if you don't have the right like linter 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 the knowledge is pretty error prone and it just requires a lot of like maintenance, especially as your codebase grows.

So react compiler kind of just takes it away from developers.

It's more shifting that responsibility to react itself.

It's like, okay, we know that you often have to like memorize stuff in your components.

Just due to the way that our rendering system works.

And compiler automatically, you know, helps with memorizing the right values in your component 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 reduce callback, an expensive function and so on.

But as I also said in my talk, like where compiler is able to memorize JSX are really tiny variables that normally developers wouldn't really memorize that use memo.

Okay.

So is both easier whereas 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 gets even better performance just because it's able to memorize more than what we normally would if we would use normal.

So I understand it's going to solve it kind of in an automatic way.

Is there still 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 drop out, use callback and just use that callback function set.

Also in a lot of cases you can just enable react compiler.

And if you don't want to memorize 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 memorizing that component and keeping your own manual memoization 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 undoes.

Yeah, because compiler will take care of that automatically.

Interesting.

I like the idea of not having this cognitive load of, like, rendering cycles and then figuring out exactly what to use callback or use memo for it.

You just want to write code. Yeah.

The only additional thing now is like I have to actively say, okay, if I don't want react react compiler to kick in as 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.

Yeah.

But yeah, if you don't want it for certain components that you can use to use no memo directive, and it'll skip that specific component from being memoized like the, but of course, also like if you break any of the rules of react 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 memorize something just to memorize something.

Because if that goes wrong, that would really break her out.

Like if you accidentally have a cache value that should, you know, be recalculated and never render, so it'll always pick the, the safe path in that way.

Yeah, I like the how easy is it to set it up either through an existing code base or when starting something new.

So first you might run npm, recompile a health check that will just tell you, like, okay, 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 ESLint plugin, 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 also, you know, tell you like, oh, maybe don't use this hook in that case and so on.

But yeah, then it's just, turning it on in your bill pipeline. So.

Yeah, in Expo could be in your app Json in Next.js, it could be in your next config file.

And they also have because it's just a battle plugin.

So you essentially just add it like as a babble plugin.

And then it just runs every time that you build your code.

But also on Mars.

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. Yeah.

And then when you use react compiler you don't have to think about it all of a sudden.

Yeah.

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 toolbelt 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 code base.

Yeah, for like so many code base stuff.

And it's not like you can only use compiler if you don't take out all these.

Use memory, use callbacks calls.

You know, eventually will hopefully end up which is really clean react code that is also really performant.

And we don't have to think about all this rerendering 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 like a low end Android device, you'll definitely see a big, big like performance increase in how like in the US in the user experience.

So yeah, it's been a while since I've been frontend development, but rerendering cycles as code bases grow were 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, okay, what is this?

You know, just do be focus on use memory, use callbacks specifically now like okay, but why do we need this dependency.

And if you change anything, you need to end it to add it to the dependency array.

It's just and of course like there are linters for it.

And like in VSCode you can earn cursor.

You can see like, oh yeah, I have to add it.

But still it's just like it's all overhead.

It's like tooling around this problem that we have.

Exactly. Yeah.

So again like it's shift and kind of the responsibility from the developers to react itself like know is this going to solve most then rerendering 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 the code really fast if you're running it on, for example, like Hermes, stuff like that.

Yeah. On mobile devices.

Also just having a 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 like, if you're using those.

So in that sense, it could also help you just to write better react code.

Yeah.

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.

Yeah.

The better it is also for maintainability, for it easier for people to step in specifically with regards to conventions for sure.

Yeah.

If this is a trend that I think is going to hold strong.

Yeah yeah.

But then also everything is going to be kind of solved because you don't see the rewrites, right? That happens.

You know, it all happens.

And you also get to keep the source maps from your original code.

So when you're opening DevTools or anything like that, you won't see that the it changed the code because the original source map.

So the original kind of structure of your components is still there.

Yeah.

So that's super nice that you don't have to.

I mean, everything I presented today, you can just forget about it, like, as no one has 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.

Anna, can you talk 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 compatibility, there's always a challenge in and of its own, for sure.

Well, what do you want me to touch on?

Mainly how they created this thing because it's it's a lot of logic that goes into compilers.

It's tradeoffs with regards to performance.

Yeah.

I mean, I'm not totally sure how I 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 compilers write word and 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

our compiler is is almost like a transpile 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, then that's pretty obvious.

But then they're also using like so like SSA.

So the 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 shows that, you know, the people, the compiler really thought about getting the best performance out of it as well.

Yeah.

I'm not entirely sure how to answer that question.

That was like a vague one.

But yeah, I 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 a production ready? Let's start with that first.

No, it's a release candidate for these candidates.

Yeah. So as of April 2025. Yeah.

It was beta 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 if like, I'm not entirely sure if they're using the exact same versions or if they're using kind of internal modification of that to make that work and that Instagram 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 easy.

But so far, as far as I know, no other like bigger companies have really turned it on to really see to get good metrics on like how much it improved.

I know for like Instagram, I believe they got like a 30% improvement.

Just turning on compiles. Incredible.

That's really good. Yeah.

Yeah.

I'm not sure for any other numbers so far.

So it's like out of stable I guess.

Yeah.

If it really fixes this pain point of rerendering, which I think is just bringing this huge cognitive load, what do you think is still missing then what other 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. Okay.

Because I, I don't even think you have to really use, like, state anymore.

It's because, like, if they can just track reactivity within the variable, then I would just do that automatically for you.

And that's of course also why a lot of people liked so like svelte and stuff.

You could just kind of like declare a variable that was closer to HTML at that point.

Other than that, I kind of honestly wins for react, which in those sounds really like one sided.

Then more people 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 I was like, man, that looks nice.

So yeah, hopefully once compiler stable, we will also get to that point.

It's funny that you mention that because when a lot of new frameworks were introduced, it's like, okay, here's how you would do it in react.

And look how clean it is. Yes, it's there's kind of a newer framework.

Yeah. And that's like yeah, look at us. So

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 question it a lot and it's only growing.

So no I'm confident that react will only get better.

Yeah, yeah. And 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 Meta quest or like all these things.

To me that's just the biggest one in react and also just the community and the information about react.

The, the responses that search activity give are often by default react as well.

So like a lot of times 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.

And I don't really because I learned back in 2015.

So it's difficult for me to know how people would approach it nowadays when they don't have any experience.

But yeah, like what?

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.

No, 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 hooks.

I felt like, yeah, 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.

Do you want to point to one.

And then I'll pick and I'll read it, this one going with my intuition.

But it's never right.

All right.

What's one tech trend you wish, which is go away, tech friend.

Yeah, I generated code vibe coding.

Vibe coding specifically, I don't I feel like a lot of the time, you know, the code still that it produces is just not not great.

I love using these tools like cursor and stuff for to reverse engineer code bases.

And so, you know, when I'm starting something new, I can just get a really quick overview of everything that's happening in the code and where it happens.

But still, the code that I generates often for me is it's just not good.

Like it's really good to prototype.

Yeah, but really production really 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 off 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.

I, 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 code is doing, whatever. Blah. But I

personally, I feel like it's easier for me to get burnt out on a project when it's entirely made, which is I, because I feel less of a connection to it.

And the moment I feel like I'm not really in control of 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 opinions.

Yeah.

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 bad when they're like, oh, I could have described coding this for something much faster, you know, this mirror or whatever.

You know, people are tweeting nowadays 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, you know, 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 over 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 in my box on the street because I can take my job, I guess.

Do you think it's going to make for better engineers or for worse engineers?

Because I feel like you need people go on this autopilot mode.

Yeah, 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 will definitely help you make you open, become a better programmer because that's when you already kind of have this you want to learn.

And then I, I kind of question that so much faster and in 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, okay, how can I make money quick?

And then, you know, yeah, 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 stay as up to date with, you know, new features that are in a 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. Yes.

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 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, so 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, yeah, I'm not sure how companies will hire those people because it's like you're not really needed, but you still need to work experience.

So that's that's another issue, I guess that, it's going to be interesting to see how that turns out now.

And we also talked about, I mean, mainly we are compilers solving this kind of cognitive load.

But with AI you still 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 does decrease.

I feel like you just have to read more and try to understand more, or indeed just blindly accept whatever's there.

Yeah, I feel like that's what most people do anyway.

I was like, sure, I feel like, yeah, very lazy.

And then also.

Yeah, so they're like more disconnected to the product that you're building because I don't know, I still that I don't know, like I, I'm sometimes just almost proud of the coder.

Right.

I almost see it as like my little not like a little baby, but like, this is something, you know, my own creation, I like it, I you can be proud of it.

And I feel like you 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 of me, but it's not like I can take any pride in it. Yes.

And now I do feel completely what you mean.

Sometimes you, or at least for me, an existing code basis.

I develop this feature, and I'm really happy with how it's.

I don't know why.

What is with 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 stuck.

Is my creativity exactly. Yeah.

You can see your own thought patterns on the screen and it's like, yeah, cool.

Thank you so much for joining us.

So we'll see you on the next one.

Beyond Coding