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.