All Episodes

January 8, 2026 75 mins
In this episode of JavaScript Jabber, I sat down with Shruti Kapoor, independent content creator and longtime React educator, to dig into what’s actually new — and worth getting excited about — in React 19.2. While it may sound like a “minor” release on paper, this update delivers some genuinely powerful improvements that can change how we build and reason about React apps.

We talked through React Compiler finally becoming stable, how the new Activity component can dramatically simplify state management and UX, what View Transitions mean for animations, and why new tooling like Performance Tracks in Chrome DevTools is such a big deal for debugging. If you care about performance, async React, or writing less code with better results, this one’s for you.

Links & Resources

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Mark as Played
Transcript

Episode Transcript

Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello everybody, and welcome to another exciting episode of JavaScript Jabber.
Today in our show, we've got Shooting Kapoor.

Speaker 2 (00:13):
Hi, Shooty, Hey Dan, how are you.

Speaker 1 (00:16):
I'm kind of on the tail end of a head cold.
Hopefully I won't sound too stuffy today, but that's I'm
back on at work, so that means I guess that
I'm feeling better. The weather here is actually pretty nice.
I'm in Tel Aviv, Israel, and it's not really cold
and it's pretty sunny, but it's you know, it's a

(00:36):
season for the snuffles. So here's what it is. So,
and where are you coming from today?

Speaker 3 (00:44):
So I'm in Seattle and the weather here is cold,
really cold, and rainy and rainy and dark and gloomy.
But I've got some lights up, actually not in the background.
I've got some lights.

Speaker 2 (00:56):
Up at my house, so it makes me feel better.

Speaker 1 (00:59):
Good for you, Good for you, and Shooty, you are
an independent content creator? Correct?

Speaker 2 (01:04):
Yeah? So earlier this year I used to work.

Speaker 3 (01:07):
As slack and I quit my job in April to
start developer education full time. I've actually been doing this
part time for a long time. I made courses on
O'Reilly as well, and I really like that, So I
was like, why do we need stability, Let's just drop
our job and go full time, make no money, and
do all the education stuff.

Speaker 1 (01:30):
So you're now an independent content creator talking about what?

Speaker 3 (01:34):
So I talked about React and AI and web development
and JavaScript and.

Speaker 2 (01:39):
Handstack and next Days and all of the good stuff.

Speaker 3 (01:42):
So everything related to web development specializing in reacting cool.

Speaker 1 (01:45):
And that's what we're going to be talking about today.
We're going to be talking about what's new and exciting
in React nineteen. Correct, yes, And are there things that
are new and exciting in React nineteen.

Speaker 3 (01:56):
There's actually three things in React nineteen update that I'm
super excited about, which I would love to get into
in a bit. But I think this updates specifically. Although
this is like a minor update, it's nineteen point two,
I think it has as a ton of really cool features,
which is really exciting for me because it's going to
help me write less code and for other people as

(02:19):
well who are building client side apps. So I'm pretty
excited about it. This really is actually focuses on client
side developers a lot, not client side developers app developers
a lot, as opposed to like frameworks there are some
framework features, but the main kind of audience is app developers,
which is perfect for me because I'm an app developer.

Speaker 1 (02:38):
When you're saying app development, are you talking about web
apps or you're talking about native apps like React native
or both.

Speaker 3 (02:47):
So I'm not talking about React native. There are updates
and reactnative as well. I just completely ignore Reactnative because
I'm a full web developer, So I'm talking about app
development in web. But there are updates and reacnative as well.

Speaker 1 (03:00):
Interesting, So do we want to talk about both React
nineteen in general and nineteen point two or do we
want to focus just one one or the other.

Speaker 3 (03:09):
Let's focus on point two because there's a lot to
talk about, and then if we have time, we can
talk about nineteen. There's a ton of features that we
can get into with nineteen point two, and this is
the third update this year, so there's a lot to
talk about.

Speaker 1 (03:23):
Cool. So, first of all, if there's so much stuff
in it, and if I recall correctly, React nineteen itself
was released something like almost two years ago, why is
it nineteen point two and not twenty?

Speaker 3 (03:37):
I think the features are kind of incremental to what
nineteen has shared, which is like concurrent rendering, but like
some updates on top of it, it's not a complete
paradigm shift. So eighteen was a big update because concurrent
rendering and automatic patching was introduced. Nineteen introduced some new
features like actions, and then what we have today kind

(03:58):
of builds on top of it. It's it's a lot
of focus on async react, a lot of focus on suspense.
So that's why it's like a small update. It's like
a minor update, not like a whole paradigm.

Speaker 1 (04:10):
Chef, and I assume that it contains no nothing that's
kind of breaking changes or significant API changes or stuff
like that.

Speaker 2 (04:19):
Correct, Yeah, probably the reason, Yeah, exactly.

Speaker 1 (04:23):
Okay, then so what isn't you and exciting about nineteen
point two.

Speaker 3 (04:27):
So there's a bunch of features. Let's talk about like
the feature set I introduced. So first of all, there
is an activity component. I'll list ot all the features
and then we can kind of dive into them one
by one. So we've got the activity component, We've got
a view transition component. We've got performance tracks that come
part of Chrome depv tools, which is awesome because we've

(04:48):
been debugging with profiler and performance tracks is sort of
like a magnified version of what your component is doing,
so it helps in debugging. We've got use effect event
a new hook, and we have React compiler is now stable,
and I know I'm missing one, but I can't remember
with one.

Speaker 1 (05:06):
Well, you'll probably it will probably pop into your head
as we talk about the other stuff. By the way,
as you mentioned react compiler, I do want to mention
to our listeners that we had Joe Savona and Satya
from the Meta react core team, which is no longer
part of Meta, and we had them on the show

(05:28):
talking specifically about react compiler. So if our listeners are
interested in what react compiler is and the details of
what it does and what it doesn't do, I highly
recommend listening to that episode. I'll find them. I'll include
the link in the show notes, but you can pretty
easily find it if you search through the podcast catalog.

(05:51):
But if you you know. Nonetheless, if you want to
remind our listeners what react compiler is and what is
it all about and why we actually wanted to.

Speaker 3 (06:00):
Need it, Yeah, so actually react compiler is extremely exciting
people remember, or like the way to memorize apps currently,
or like the way to kind of improve the performance
of your app, the first thing you would think about is, well,
let me add use memo, use callback, right, That's like
the first hook that comes to mind whenever you think
about improving the performance of your app. Sometimes you blindly

(06:21):
app use memo and use callbacks to all of our
components and all of our functions just because they are
kind of hard to figure out where to add use
memo and use callbyck, you have to use the profile
to figure out which components are slow, which functions are slow,
where it's the expensive calculations, and then memois that and
even then it is a hard thing to do. Now

(06:41):
with the React compiler, memoization is given to you out
of the box, so you don't need to add use
memo and use callback at all. In fact, at React
cons I was leading the panel with the core team
and this is the question that I asked them, that
can you really remove use memo and use callbacks from
your code right now? And the answer is yes, it
is safe to I will use memo and use callback.

(07:01):
So reactin compiler helps to enable auto memorization, which means
that your code is auto memoiz. You don't need to
add UMO use callback to make sure that it is
optimizer performance.

Speaker 1 (07:13):
I would even argue that it's beyond safe. It's even
preferable because if I recall correctly, when React compiler sees
let's say, use memo in a component, it basically bails
out out of optimizing that component. So theoretically, at least

(07:36):
React compiler, if it's you know, working correctly and does
what it's supposed to do, can actually optimize your component
beyond the specific manual optimizations that you implemented using memo
or use memo, So in effect, it can do extra ammorization.

(07:56):
And if you have your own explicit use memo, you're
kind of forcing it to bail out because it says, hey,
you know what you want to do. I'm not going
to get in your way, and then you might actually
lose out on some optimizations.

Speaker 3 (08:10):
Yeah, and the way they both do memorization is a
little bit different. Reacompiler memoris is a different way than
use memos. So yeah, like when you do manual memorization,
reac compilers like you seem to know what you're doing,
so you go ahead and do your thing.

Speaker 1 (08:26):
Yeah, just to remind our listeners in case they forgot
the benefits of memorization is like threefold, as I recall correctly.
First of all, it avoids unnecessary computations. Second it avoids
unnecessary renders, and third it retains referential consistency, which avoids

(08:49):
rerenders down the line. It basically, if you think about
the dependency arrays in use effect and stuff like that,
they are referential identity, not value identity. And if you
get referential identity, you avoid even more rerenders than you

(09:11):
and stuff like that. Then you would otherwise perform. And
I think even the rendering engine itself, when it sees
the referential identity, it knows to cut out and not
totally not traverse certain parts of the v doom tree
because it can immediately identify that nothing has changed. So

(09:32):
you're effectively making the entire system just basically faster and
more efficient.

Speaker 3 (09:37):
Yeah, And the given example of what that means is,
let's say you have a function where let's just say
you're calling console log or fetching an ampair or whatever,
just simple function, and that function has a dependency of
use effect. So what referential identity means is that when
you haven't added any callback or things, every time you
render that is a new function. So when reaclub said it,

(09:58):
it's like, oh, dependency of use if I change, so
I need to run this effect again. So this way
you're running effect multiple times. If you have a function
as a dependency. But if you add a used callback
to that function, now React as memois that and now
it knows that this is the same reference as previous time,
so it won't rerender if nothing changed. So that reduces

(10:18):
the amount of times you you ruan the use effects
and again.

Speaker 1 (10:22):
With React compiler, you basically just remove all your explicit
uses of memo, use memo, and use callback and just
let React compiler do its magic. By the way, another
advantage of React compiler from my perspective, potentially even a
greater advantage from my perspective, is that it's effectively a

(10:42):
React linter. It knows the rules of React with the
best practices of React, and will actually warn you if
you're violating any of these React best practices. Correct.

Speaker 3 (10:58):
I don't know if the compiler that I know there's
the plug in, yeslamp plugin actually wants you when you're
breaking React rules and in fact when the compiler, so
one way to see that you're breaking React rules is
when you look at the compile code, if you see
that your code is intact and hasn't been memoirs, it's
because the compiler bailed because you haven't followed rules of React.

(11:19):
So that way it's easy to kind of see where
you're breaking rules of React.

Speaker 2 (11:23):
So yeah, yeah, it does know when you're.

Speaker 3 (11:25):
Breaking rules of React, and it just like bails out
for those things.

Speaker 1 (11:28):
Cool. And you said that in React version nineteen point two,
compiler is now officially a stable part of the release.

Speaker 3 (11:36):
Yeah, yeah, so the babble plug in, so React compiler
is still available as a babble plug in.

Speaker 2 (11:41):
Now it is stable.

Speaker 3 (11:42):
It was in our C stage for a long time
and the community was wondering when it's going to be stable.

Speaker 2 (11:49):
So if React content was announced that it is stable.

Speaker 3 (11:52):
And what's cool is that it not only works for
React nineteen, but it also works for eighteen and seventeen,
so which is really cool because now you can you
have backwards compatibility, so you can go ahead and remove
use memos.

Speaker 1 (12:04):
Oh that's interesting. I didn't know that. So if you've
got a project that's built on top of React eighteen
and you don't feel like an upgrade you can. Basically
what you're saying is just drop in React compiler and
hope for the best.

Speaker 2 (12:17):
Yeah.

Speaker 3 (12:18):
Yeah, I mean you can install a babble plug in
and your compiler will start memoizing. I've actually added reac
compiler to an app where I didn't change anything else.
I just added reac compiler, just added the plug in,
and I noticed that my renders, like rerenders were reduced
from thirty two to just seven, which is crazy.

Speaker 1 (12:39):
Wow. Yes, definitely it is. That's pretty significant. Yeah, you know,
rerenders are kind of the bane of our existence, is
React developers.

Speaker 3 (12:49):
Yeah, and even for the ones, so even for the
ones that were being re rendered, the amount of time
it took to render that was reduced as well, so
the height of the graph like in React with when
you look at the graph of the components, the height
of the bar itself was lower, so it took lesser
time to vendor by just adding React compiler, which is
crazy interesting.

Speaker 1 (13:10):
We have a React eighteen projects where I work, and
upgrading is not trivial because it's kind of it kind
of shares the React library instance between multiple micro front ends,
so we kind of need to upgrade all of them.
In order to upgrade one of them. That's the way
it's currently implemented for us. And being able to just

(13:30):
you know, drop in maybe React compiler to see some
performance improvements should be pretty interesting something I should definitely
look into.

Speaker 3 (13:38):
Yeah, and the newest plug in So with React nineteen
point two, the es plugin also got an upgrade, so
it's v six now and it also has.

Speaker 2 (13:47):
React compiler rules built in.

Speaker 3 (13:50):
So I haven't actually used the plug in, but my
guess is that it also warned you when you're breaking
rules of reacty.

Speaker 1 (13:55):
That's really that's really useful. So okay, so one great
thing about React versus nineteen point two is the stable
React compiler. What else?

Speaker 3 (14:06):
The other thing that I'm excited about is the activity component.
So this component is really cool because one of the
biggest things that bes app developers have been doing is
storing the state of where we are in the app,
especially a component, and then resuming from it. So an
example would be, let's say you type something in search
and then the user clicks away from search and then
they open it back again.

Speaker 2 (14:26):
You kind of want to show them what they had type, right,
or you.

Speaker 3 (14:29):
Want to kind of keep the results that they were
looking for now. Currently, the way to do that or
pre nineteen point two, is by storing that state and
then when the user pops up again and you check
if the component is open, and you reload from that state.
With nineteen point two, this activity component actually gives it
to you out of the box. So all you got

(14:49):
to do is wrap your component in activity and it
understands to store the state, and it's actually going to
give you that state that you've written in the text
input for free, so when you open and close and
then open again, you'll see what you've stored so far.

Speaker 2 (15:04):
So I built an example component with Netflix where you.

Speaker 3 (15:08):
Know how in Netflix when you are on a or
even YouTube actually, but when you are on a when
you're watching, when you're on the homepage and you're watching
a trailer, like when you have it on an item,
the trailer starts playing and then you move away, and
then you come back and the trailer restarts.

Speaker 2 (15:24):
I hate that. I wanted to continue from where I
was because.

Speaker 1 (15:28):
Actually that's what YouTube does for me, and sometimes I
really hate it, yeah, because it starts playing muted when
you hover on top, and then when you click it,
it starts playing with full audio, but you're already somewhere
inside the video, so now if you want to hear
it from the beginning, you kind of have to rewind
each and every time. It can be annoying, exactly.

Speaker 3 (15:49):
I hate that, and in Netflix specifically because like it
starts like I want to see the trailer, yes, but
it starts off and it's loud and everything, and then
I move away and then it restarts the trailer, so
I kind of want to continue from where.

Speaker 2 (16:01):
It was working.

Speaker 1 (16:02):
Yeah, that I definitely agree with.

Speaker 3 (16:04):
Yeah, And so I added So I made a Netflix
clone and I added activity component to it, and that's
all I did.

Speaker 2 (16:10):
So I had, like a trailer, it would AutoPlay.

Speaker 3 (16:12):
When you have it on it, and then when you
move away, it would stop playing, and then when you
come back, AutoPlay again. And all I did was add
activity to that component. And then when I hovered away
and came back, it remembered my state, so it knew
how much video was played, which was cool.

Speaker 2 (16:26):
Because I had to do nothing else to fix that
and it was so awesome.

Speaker 1 (16:29):
So just to understand correctly, so you kind of wrapped
your component in an activity component, kind of like what
you used to have with higher order components. My understanding,
and what state does it store the props that are
passed into that component.

Speaker 3 (16:46):
It remembers your dom state basically, So like when you're
playing the video.

Speaker 1 (16:50):
It's the DOM state or the v doom state.

Speaker 2 (16:52):
The vdom state.

Speaker 3 (16:53):
So if you have a video, the amount that has
been buffered, the amount that has been played. It remembers
that same with like input, if it knows that you
have put something in, it remembers that same with like
scrolling a feed. So another thing that you could do
is if you have a sidebar and you've got like
ten different items and you've scrolled down to let's say

(17:14):
the fifth or sixth item, and you're on the second
or fourth page, it remembers where in them you are,
like where in the scroll position you are, so it
remembers that. So I think it's beyond props because these
are not props that you would pass to your component.
This is just coming from downstate, right, So it remembers.

Speaker 1 (17:32):
Your state, I understand. So it's kind of like freeze
drawing the component state. I assume stuff like all the
data that's kind of stored in hooks is somehow preserved
between calls or between rerenders in a sense, I would
definitely have to look at it. I understand what you're saying,

(17:52):
but I'm still kind of wondering exactly what it does.
So it's definitely something that I will look into following
our conversation, because it's, like you said, it sounds like
a very useful functionality that you're effectively getting for free,
as it were. Yeah, that's really cool.

Speaker 2 (18:12):
Yeah.

Speaker 1 (18:13):
Are there any gotchas though with this kind of thing
if you run into problems or issues like that can
bite people if they use the activity, Yes, because otherwise
you might just wrap your entire application in this huge
activity at the like at the root of your v
doom tree and hope for the best.

Speaker 2 (18:35):
Yeah.

Speaker 3 (18:35):
So, actually, one of the things that I noticed when
I was implementing this video player component was that when
I hovered away, sometimes a video keeps playing. It's not consistent,
but sometimes the video will keep playing. So one of
the things I had to add was, now, because the
video is in the dom and React doesn't actually have
control on the dorm, it only has control of a

(18:56):
v doom, so sometimes a video keeps playing. So one
of the things that I had to do was make
sure when activity was make sure that in my component
I add a new hook called use layout effect, which
actually stops the video from playing when the component has
been unmounted. So sometimes there might be weird edge cases
when your component has been unmounted.

Speaker 2 (19:18):
In activity, Okay.

Speaker 1 (19:20):
I also assume it has a certain amount of overhead.

Speaker 2 (19:23):
Yeah, I mean I can assume that.

Speaker 3 (19:25):
I can understand that because your components are kind of
in state, so it can definitely have some overhead, especially
if you have like multiple different tabs and you've got
like data loading in each of those tabs. I have
an experimental with that myself to know what the implications are,
but I can totally imagine that could be the case.

Speaker 1 (19:43):
Also, how many levels down does it go? I mean,
like I said, what happens if I put an activity
wrapper around the entire application? Is it like preserving the
entire state of every subcomponent in the v doom tree.

Speaker 2 (20:01):
Wow, I haven't tried that. That would be fun to try.

Speaker 3 (20:03):
I imagine, like your app probably just breaks at that point.
I don't think your state would be restored, but that
would be fun to try. Like have like maybe like
ten different inputs and just put activity on top of everything.

Speaker 1 (20:15):
Interesting anyway, like you said, it sounds really interesting and
potentially very useful. So this is definitely something that I'll
look at and play with after our conversation. Well, probably
not immediately after because it's actually pretty late here in Israel,
but you know, maybe tomorrow. But it does sound really

(20:36):
really interesting and, like I said, potentially very useful. Anything
else about activity before we move on to your next
favorite thing about React nineteen point two.

Speaker 3 (20:47):
So I think activity is really cool because a lot
of the demos that we saw at react on for
showing using activity to kind of freeload data. So one
of the cool things is imagine you have two tabs
you put your opponents something that actually one of the
things that activity is helpful for is replacing conditional rendering.
So what we did initially was we have let's say

(21:09):
through tabs, and in one tab we render if the
tab is let's say home, and in another one we
actually render a list of posts, which would be like
a post tab. So typically what would happen is if
you have conditional rendering, you load the first component the
first tab. Then when you switch to the second component
is when you load that component. Right, So you'll see
like a loading screen when you switch to the second

(21:31):
one with Activity, what you could do is you could
wrap both of those tabs within Activity, and so when
you switch between the two, the second one is already
ready because it has pre rendered your data.

Speaker 2 (21:41):
So that is something that Activity is really helpful for
as well.

Speaker 3 (21:44):
One caveat though, is that if you have data rendering
in user effect, it will not work because Activity doesn't
actually mount your effects or it doesn't actually run your
effects until the component gets mounted. But if you have
like a suspense powered component, like for example, if you're
using use or if you have next yest data fetching,

(22:05):
then that will work, and suspect like that will work
in Activity sort of preload your data before you even
move to that component.

Speaker 2 (22:11):
So that's really cool.

Speaker 1 (22:12):
I assume that well, certainly, if you put it in suspense,
then it functions asynchronously to the rest of the application.
But because otherwise I don't know if Activity is like
a synchronous by default or if it needs suspense for that,
because if it's not a synchronous, then you might be
getting in the way of your primary content.

Speaker 3 (22:35):
No, so you don't need suspense for it, and anything
that is rendered in activity is actually a lower priority
than everything else. I think you mentioned adding suspense, and
one of the differences between adding suspense and activity is
that when you do add a suspense, you would actually
see a fallback as the data is loading right while
when you add actually activity, that component is loaded and

(22:56):
then the other component actually gets loaded in the background
on lower priority. So your current component still has like
the component that is visible still has higher priority as
opposed to the component that is in the hidden state.
So activity actually gives you like two moods, a hidden
state and an active state, a visible state and a
hidden state, so the visible state components have higher priority

(23:18):
than the hidden state components.

Speaker 1 (23:20):
Yes, I'm looking at the React documentation right now and
I'm seeing it. So basically a mode attribute that can
be set to either the string visible or the string hidden,
and like you're saying, when it's hidden, it's lower priority.
Essentially a synchronous I assume, and lower priority than visible content.

(23:40):
Not surprising. Interesting, Yeah, I guess that's another one of
the benefits that we get from the whole refactoring of
React to use fibers instead of the previous surrendering engine
is that now they can really control to a fine
grained degree what gets read when. Yeah, and that provides

(24:02):
a whole lot of opportunities for optimizations such as these.

Speaker 3 (24:06):
And you can pause and restart and like pause and
resume your rendering when you need it to be. I
think one question that people often have, so basically the
way activity works is that it actually adds a display
none to the component. So one question that people usually
have is it any different than just adding display none.
One advantage is that it actually restores your state. Second

(24:27):
is like it pre renders your data. But another example,
another advantage that I noticed is that when I add
display none, just display nan through CSS versus if I
add activity. There's a difference in LCP as well, so
display none takes longer to load as compared to activity,
which was very interesting.

Speaker 1 (24:48):
I assume, Well, it's interesting to look at what actually
gets rendered into the dome itself when activity is used.
Are you saying that when a is hidden, it renders
into the dome with display none, or it achieves the
same effect as a display none but without using display none, So.

Speaker 3 (25:11):
It actually uses display none. So let's say that you
have two tabs home and post. If you add activity
and you move from home to post in the dom,
what you would see is that it adds a display
nune to the component that is hidden, and then when
you move back and removes display none. So it's literally
adding that display nne style to the component. But the

(25:33):
question also arises, like, well, is it the same if
I just add display nne and not add activity. So
what I've noticed is it's different.

Speaker 1 (25:42):
Yeah, well, I'm not surprised that it's different because well,
at the dome level it might be effectively the same,
but at the v dome level it's different because if
you just add or remove display none, the v dome
does the same thing that it would do either way.
The vedome does not know or care about display none,
whereas with activity, you know that you're going to be

(26:05):
putting display none, but you also know that you can
avoid certain amount of work and comparisons and stuff like
that at the vetom level because you know that this
stuff is not going to be visible anyway exactly. So
I assume, again I'm guessing because I've not actually played
with this mechanism yet myself, but I assume or I'm

(26:26):
guessing that this is what actually what's actually happening really
really interesting. Definitely something that I should play with.

Speaker 3 (26:35):
Yeah, I'm actually very excited about it. I've added to
like a bunch of my apps and oh my god,
it's so nice to like not have to think about
adding this UX state and storing them and then refetching
from them. It makes it makes life as a app
develop much easier to focus a lot on like UX improvements, which.

Speaker 2 (26:55):
Is really cool.

Speaker 1 (26:55):
Yeah, it's it's about the whole. It's about two things really,
if I'm saying thinking about it this way. First of all,
it's about that declarative aspect of React, about you know,
in telling React what you want done, rather than explaining
how to do it. So rather than using all sorts
of hooks and whatnot in imperative code, you just you know,

(27:18):
like with suspense, you drop it into your vdome tree
and your your componentry actually would be the better term
to be use in this context, and then just reap
the benefits. I do see from looking at the documentation
that activity is kind of related to view transition or

(27:39):
impacted by it. So maybe it's worthwhile to transition unintended
to view transition. Yeah, so what can you tell us
about view transition?

Speaker 2 (27:49):
Yes?

Speaker 3 (27:49):
So view transition is actually really interesting. It is still
part of the experimental part release of React. It's not
stable in nineteen point two, but view transition was one
of them main features that were shown and React on,
so I think it's worth talking about it, especially because
activity and new.

Speaker 2 (28:06):
Transition kind of go hand in hand.

Speaker 3 (28:08):
So the thing that you transition does is it adds
the CSS animating effect to any component that you wrap
it in. So, for example, you've got view transition on
a component where let's see, you've got the same video player.

Speaker 2 (28:22):
Kind of component. You're watching trailers.

Speaker 3 (28:24):
When you click on it, you want to show like
a nice zoom out effect. So you can add view
transition and then you can give it what kind of
animation effect you wanted to do, or you can just
leave it as default and you get like a nice
fading effect.

Speaker 1 (28:39):
And I think it's if I might interrupt you for
a second, it's first of all, I seem to recall it.
We discussed this in a previous episode of JavaScript Jabber.
I need to look and see when and then add
the appropriate link to the show notes. But it's kind
of important to understand or to note that few transitions

(29:00):
or a browser dom feature. They're not a React feature,
They're implemented by the browser itself. So the browser these
days is able to animate your dome from a certain
state to a different sort of state. And the example
that you gave is the kind of the canonical example

(29:20):
of like the Netflix type user interface where when you
click on a particular video, that video expands to cover
the entire display because you're going into that particular movie
or TV show, whatever, and hopefully my dog is barking
is not creating too much background noise, And like you said,

(29:43):
it can animate from one state to the another, something
that in the past people would need to jump through
a lot of hoops in order to be able to
achieve something like that. Now it's basically built into the browser. Now,
remember we actually had Normozentae who actually took over the
spec in the W three C for this functionality. I

(30:05):
think it was originally done by Jake Archibald, and then
I think Noah Mozenthal took it over, and as a recall,
we actually had him on the show to talk about
it again in the context of the browser itself rather
than in the context of a particular framework. React is
not the only framework that has support for it. I

(30:25):
think there is also support for it in Swelt. It's
a recall and solid I think. So it's not uniquely
for React, but it's really nice to see that React
is now as built in support for it with a
view transition component that you can just wrap your components in.
So can you elaborate on what exactly that view transition

(30:48):
component does?

Speaker 2 (30:49):
Yeah, so you explained it perfectly.

Speaker 3 (30:51):
It is basically used for animating from one state to another.
So an example that we have been talking about is
the Netflix app. So when you actually open the trailer
and you see like this nice like effect like fade
in effect into the next page or the next component,
that's what.

Speaker 2 (31:10):
View transition can help you do.

Speaker 3 (31:12):
So now instead of having to manually add an animation,
you can wrap it with the new transition.

Speaker 2 (31:17):
It ass the classes.

Speaker 3 (31:18):
I think it's a view transition all and new which
actually adds the slide in and slide out or like
fade in and fade out effect, so it gives you
animation out of the box.

Speaker 2 (31:28):
Yeah. I think that's probably the best example.

Speaker 1 (31:31):
So you would have certain you would have components wrapped
in the view transition component, and then when you want
to create that animation, what do you do? Do you
replace the components that are contained within the view transition,
do you do something else? What exactly do you do
in order to trigger the animation?

Speaker 3 (31:53):
Yeah, so now to trigger the animation, that's a great question. Basically,
what you want to do is let React know when
you want to start transitioning to the next component. So
what you do is, let's say that you have a
button that actually initiates so like when you click on
the trailer, the button actually navigates to the next element.
That's when you want to wrap that button or that
on click handler into a start transition and that will

(32:15):
React know that at this point I need to start
the transition of actually adding the like removing the old
V transition and adding the new view transition effect, and
that's where the next animation comes in. So you need
to actually trigger the view transition by using a start
transition function and that you wrap around whichever element should

(32:35):
trigger the next component. So, for example, if you have
a button that actually opens a new component, that's where
you were added.

Speaker 1 (32:42):
Understood makes sense, So React has to know when you're
actually instigating that transition, when what you're actually transitioning on.

Speaker 2 (32:54):
Yeah, exactly, very very cool.

Speaker 1 (32:56):
So what is the relation between activity and view transfer?

Speaker 3 (33:01):
So I'm trying to remember, Like, let me look at
the doc to see what it actually talks about.

Speaker 1 (33:05):
It's not that important if you don't remember off the
top of your head, but I seem to recall that
there is some sort of a connection there.

Speaker 2 (33:13):
Yeah, I know that the coherent hand.

Speaker 3 (33:14):
I'm trying to remember, like, what was the example that
was showed in the conference and.

Speaker 1 (33:19):
It says, oh, it's actually under caveats. It says, if
inactivity is rendered inside of you transition and becomes visible
as a result of an update caused by start transition,
it will activate the view transitions and to animation. If
it's it becomes hidden, it will activate its exit animation.

Speaker 2 (33:37):
Yeah.

Speaker 3 (33:37):
Actually, like activity works as the start transition effect. So
when you have that component come in and it's been
wrapped in new transition, that's when it starts animating in
so the view transition has started the transition when activity
is visible.

Speaker 1 (33:51):
Makes sense, makes sense because effectively, that's probably what you want. Yeah, okay, okay,
then obviously our listeners, you know, one of the downsides
of a podcast is that it's an audio medium, we
can't actually show you stuff. I think Shreuty is doing
an amazing job of explaining just verbally. But if you

(34:13):
want to see then the React website has a lot
of actual examples. Or alternatively, if you use something like
a cursor, you can tell it write an example for
me of some code that uses this or that feature React,
and then you can look at what it created.

Speaker 3 (34:33):
Yeah, if you do that, the only thing I would
do is give it the documentation and then tell it
to create an example with the source of the documentation,
because I've noticed that when I give it create especially
with this newest updates, when I tell I haven't tried
this with cursor, but I've tried this with plot, but
when I tell it to create an example, it actually
doesn't give the accurate results.

Speaker 2 (34:53):
So give it the documentation.

Speaker 1 (34:55):
Yeah, but it gives inaccurate results with complete confidence.

Speaker 2 (34:59):
Yes, I wouldn't know.

Speaker 3 (35:00):
One thing I wanted to say is the Netflix example
that I'm talking about that is also on my YouTube channels.
So if you're looking to see how like what the
code behind that is, it's also on my YouTube channel.

Speaker 2 (35:10):
I'll leave link to that.

Speaker 1 (35:11):
Excellent that that will be awesome. Yeah, so show some
love and support for shooting in a new end of
way exactly. So we talked about the REAC compiler, we
talked about activity, we talked about fut transition. What do
we want to talk about next?

Speaker 3 (35:30):
So there's two more things that I want to talk about,
and let's talk about use effect event, which is the
only hook that comes in this.

Speaker 1 (35:36):
Really.

Speaker 3 (35:37):
Use effect event is a hope that I am super
excited about because it helps to clean up user effects.
And I have seen so many places where this could
be useful and so many mistakes that happened with the
use effects. So I think generally use effect could use
some love, and use effect event comes at the right time.

Speaker 2 (35:54):
So what use.

Speaker 3 (35:55):
Effect event does is it helps to remove reactive and
non reactive vas use out of use effect. So we
were talking about this earlier where if we have a
dependency and use effect, anytime that dependency changes, we rerun
the use effect that causes a lot of rerenders. But
imagine if you have a perfect example for this is
imagine if you have a page where you just want

(36:17):
to lock the impression of when the user landed on
this page, and then you want to lock some other
aspects of the page as well, like what is the
user's name, what time is it?

Speaker 2 (36:27):
Things like that, right.

Speaker 3 (36:28):
So additional things that you want to log as soon
as the user lands on the page. So in that case,
when you add a use effect and you log analytics
on that use effect, what you would be doing is
you would be adding like name and time. Maybe not
time because times so dynamic, but name and like page
and route and things like that.

Speaker 1 (36:46):
Basically funderstill correctly. And I looked at some examples. Unlike
the previous two which I haven't looked at, I did
look at this one for some reason. And when you're
using a certain value in user effect, React kind of
requires you to include that value in the dependency ray.

(37:07):
If you don't, you will actually get squigly lines for
it and React with complain again not at run time,
but it build time, React could actually complain about it.
And therefore, if you have a certain value, if you
use a certain value within your use effect, you're kind

(37:27):
of forced to include it in the dependencray. Problem is
that if you include it in the dependencray, every time
that it changes, it forces that use effect to be reevaluated. Yeah,
which is may not be what you want, like you said,
if I'm only using that particular value. Let's say is

(37:49):
an example that you gave to write to the console,
I don't I want to when I write to the console,
I want to use the current value. But if that
value changes, I don't want to rerun users effect just
because there's a different output to the console. So is
that correct?

Speaker 2 (38:08):
Yeah, and that's that's exactly correct.

Speaker 3 (38:10):
And like you would want to, for example, log impression
only once when the user has landed, and even if
the path changes or something else changes or prop changes,
you don't necessarily want to lock the same impression again.
It could be a false impression as well, like you
are adding data that you don't need. So in that case,
like you said, if you add that in the dependency
or a which react will actually force you to, you

(38:33):
will be causing that function to run again and again,
that effect to run and again again. So what use
effect event does is you can move the non reactive values.
And non reactive value basically mean things and dependencies that
you don't want to rerun your effect for you don't
want to react to that value, So you can move
a non reactive value outside in a use effect event.

(38:55):
That's why it's called use effect event because it's used
to move event logic, which is like items that change
that items that you just want to read.

Speaker 2 (39:03):
The value out of you don't want to react to it.

Speaker 3 (39:06):
So you can move those values, for example, in this case,
maybe the past name or maybe the user name, things
like that into a use effect event, and then you
use that use effect event within the use effect So
it's actually like a helper hook for use effect and
that actually prevents you from reading the dependency or like
reading the reactive values or reading the non reactive values,

(39:29):
and prevents you from adding that to your dependence, which
reduces the amounts of time you read, render your component,
and rerun your effects.

Speaker 1 (39:37):
I remember or that in the past, when I prior
to this ertion of react, when I wanted to achieve
similar effect again pun intended, I would use AF for it.
I would generate references to values and then even if
I put I have to force to put the reference

(39:59):
inside the dependency or a reference itself doesn't change the
value that the references does change. So this is kind
of a way to circumvent the problem, but it's it's
kind of it almost felt like kind of a dirty
trick or a cheap trick, like essentially using refs for

(40:21):
values that shouldn't impact that can change but shouldn't cause
a rerender is doable, but kind of felt dirty in
a sense, like this is not what refs were originally
intended for exactly, and now we can be much more
explicit about it and not use a hack. Yeah, precisely cool,

(40:42):
So that's really nice, it seems though, to be honest,
it seems like something that is really helpful when you
actually need it, but not something that you might be
using all the time. Like almost all the examples that
I'm hearing about end up talking about console.

Speaker 2 (41:01):
Logs, So yeah, I think you're right.

Speaker 3 (41:04):
Like, the biggest example that comes to my mind is
about analytics and passions, because that's the one where you
don't really want to react to a dependency that you've added. Yeah,
it's kind of anything like when you need that effect,
like when you need that hook that is the right hook,
but otherwise that hook is not very commonly used.

Speaker 1 (41:26):
So anything related to observability, as it were. That way,
you want to observe current values, up to date values,
but you don't want to have to impact the actual
behavior of the application because you're just observing it. Correct interesting.
That's that's I think. I think that's a good point
of view on that on that particular topic. I think

(41:48):
that's that sounds like potentially the primary use case really
very interesting. Okay, then we are I think we are. Well,
we still have some time. So do we have more items? Now?

Speaker 2 (42:02):
One one you can talk about that I'm super excited about.

Speaker 1 (42:05):
Okay, go for it.

Speaker 3 (42:07):
Probably the most exciting thing in this release is the
performance tracks in Chrome death Tools. So if you've been
debugging React apps, you know that you need to install
an external extension called React death Tools, which gives you
profiler and I think it gives you components as well
as part.

Speaker 1 (42:25):
Of Yes, it does. It provides you a component view
that's kind of similar to the built in Elements panel.
So you've got a built in component spanel which you
can you're you're basically seeing components and their and their
state and their properties, which is really useful for understanding

(42:46):
what the vedom actually looks like at any point in time.
And like you said, you have something that's kind of
similar to the death Tools performance tab, only it looks
at component re renders, so you can use it to
identify excessive rerenders. I've used it on multiple occasions to
identify excessive rerenders and try to mitigate them.

Speaker 3 (43:09):
Yeah, so those tools that really help perfectly just a
flame chart, yeahs. And that profile tool is very helpful,
especially for figuring out how many times your component re rendered,
and that is the tool that I was using when
I was working with reac compiler to figure out when
the compiler has had it just how many times it
reduced the rerenders. So that tools are still really helpful.

(43:31):
But there is a now default tool that comes with
Chrome Deaf tools if you have React nineteen point two install,
which is the performance tracks and that is part of
the performance tab within Chrome, so you don't need to
install anything else, which is really cool. But what this
does is when you inspect a component, Actually what you
have to do to enable this, this is a little

(43:52):
bit of gatcha, which not that easy to understand, not
that easy to see, is you actually have to record
the performance. So there's like a recording tab you have
to record, and then you can like go through your
app and do what you need to do, see like
which clicks and whatever.

Speaker 2 (44:07):
You need to record.

Speaker 3 (44:08):
When you stop the recording, that's when you'll start seeing
the performance tabs. So in the performance tab of Chrome
Depth Tools, now you'll see two new tracks. They're called
and they're called Components, and then they're called Scheduler.

Speaker 2 (44:20):
If I remember the name correctly.

Speaker 3 (44:21):
But they have a little React logo, so that shows
you that this is coming from React nineteen point two.
But what they actually show you is, let's say you
clicked on an element and then you're fetching the data
in the background, and then you're waiting for You're like
you have got a loader coming in and then you're
waiting for data to fill in, and then you have
got some like changes in the DOM that's happening, changes
on the UI that's happening. Now that performance track will

(44:44):
actually log and show you all of that on the
track itself, so you can actually see at one point
you clicked, how long did that take? How much layout
shift did that cause? What is the blocking part of
this process? So when you're actually fetching data, that could
be part of blocking. So now if you add suspense,
it will show you like this is where suspense boundaries
came in. So this is a really cool way to

(45:07):
see what is your component doing when you've made an interaction,
when you're doing something with it. And it's really helpful
to see exactly in which phases your component is blocked,
in which phases the React vidowm is actually committing. And
it is a really cool way of debugging the React apps,
so much better than profiler.

Speaker 1 (45:26):
Interesting. I assume it's only active or only shows the
sexual information when React is in the development mode. That's
probably FLUE because otherwise I assume that there would just
be too much overhead.

Speaker 3 (45:41):
Yeah, it'd be weird to show that in for production apps.
I haven't tested in production, so I'm not sure, but
I assume.

Speaker 2 (45:47):
That's the case.

Speaker 1 (45:48):
I'll definitely take a look at that one. You may
or may not know I'm something of a performance junkie.
My current My current role is more let's call it
a general I'm a principle engineer at a SI sense,
so I deal with a lot of stuff, nothing not
specifically having to do with performance. But my previous two

(46:08):
roles was a performance tech lead, so i'm and i'm
still on the doctor. Three CEE were performance working group,
so so where performance is kind of my jam, So
if there's this new functionality in the performance tab and
dev tools, I definitely want to check it out and
thank you for pointing it out. It's really exciting. It's

(46:30):
something I'll definitely look into.

Speaker 3 (46:31):
Yeah, you might really appreciate it. So it's available in
nineteen point two. You don't have to do anything, only
kind of I spend a lot of time like figuring
out where these tracks are. The only kind of gotcha
there is you have to record performance and then see it,
and then you'll see it.

Speaker 1 (46:47):
Now, have you done a video on this?

Speaker 2 (46:50):
Yeah?

Speaker 3 (46:50):
So in the React nineteen video I launched, I do
show how to inspect an element with performance tracks.

Speaker 1 (46:56):
And do you also provide like a guitub example application
that you can actually play with with this stuff?

Speaker 2 (47:04):
Yeah?

Speaker 3 (47:04):
So actually in the video link there is a example
as well.

Speaker 2 (47:07):
Have we put up the video so it's easier.

Speaker 1 (47:10):
No, you know, we can put the link for our listeners,
but I really don't want to show the video because
then our listeners are kind of missing out. I think
it's sufficient to say that we will definitely put a
link to to shooties content, and you're definitely encouraged to
go out and check it out and what you know,

(47:32):
like and subscribe right, subscribe. Yeah, you need to get
into that game.

Speaker 2 (47:37):
Like subscribe and comment and hit that bal.

Speaker 1 (47:39):
Icon so you never miss do you know?

Speaker 2 (47:41):
It's a notification from shut Kapur.

Speaker 1 (47:43):
Excellent, excellent. We do have something like ten more minutes,
I think maybe even fifteen. So is there anything else
we want to talk about either about nineteen point two
or nineteen in general?

Speaker 3 (47:55):
I think one of the big kind of themes about nineteen,
especially as you'll see in the content stocks, is async React,
which is something that I want to dive deeper into,
which is we have been using use effects to call
our APIs if we don't have any other frameworks or
data catching libraries, which has just been the general way, right.
But React nineteen introduces use hook, which is used to

(48:18):
resolve promises. So with nineteen point two and the conference
talks that we've seen nineteen point two's React conference, a
big focus has been how to move away from data
fetching and use effect to actually using React the ACYNC way,
which is by fetching data through the use hook, wrapping
it with suspense, and then perhaps adding animations to view

(48:40):
transitions and activity like showing in and out through activity.
So I think with React nineteens released, the way we're
going to be fetching data is changing. So I am
very excited to try that out. That's going to be
another video that I'll do on my channel in January.
But I think the main focus is that we're going
to be be changing the way we've been fetching data

(49:00):
in React nineteen.

Speaker 1 (49:02):
I totally agree, and interestingly it's going to be one
of my picks. But I'm actually giving a talk at
the upcoming React next conference in Israel.

Speaker 2 (49:12):
Oh cool.

Speaker 1 (49:13):
It's yeah, it's Israel's largest front end conference. It originally
was just React specific, but it has even though it's
retained its name of React next, it's effectively become kind
of a general purpose front end conference, not just about
the React ecosystem. I think we're going to have something

(49:36):
like somewhere between one thousand and twelve hundred attendees. It
was like so sold out within a week or something
like that. Wow, I'm actually, if I you know, I
might brag, I'm actually beyond giving a talk. I'm actually
giving the keynote. That's awesome, Yeah, which is kind of
amusing because I'm not talking about AI. But you would

(49:58):
think that any talk, any key note that front end
conference these days is going to be somehow about AI
not mine nice. But the reason that I'm bringing it
up is that the topic of my talk is actually
about our PC if our listeners are interested. It's kind
of reminiscent of the conversation that we had with Ryan
Carneato and Tennor Lindsley a couple of episodes ago about

(50:22):
RPC and how it's kind of making this significant comeback
in modern front end frameworks or full stack frameworks to
be more accurate. And the reason that I'm bringing up
is that one of the things that I'm showing is
using ORPC, an RPC library within a React component to

(50:45):
talk from the front end to some EPI on the
back end. And RPC makes access to back end services
look like function calls, kind of similar to what next
js does with the server actions and React server components.
So it's kind of similar in that respect. So you're
calling a back end function and rather than getting a value,

(51:07):
not surprisingly, what you get back as a promise, and
now you can just use it inside use and it
makes it look exactly like a function called you just
wrap it in use effectively. You might say that in
this regard, use is kind of reacts replacement for a
weight in client side components. In React server components, you

(51:30):
can actually use a weight because they're running on the
back end and there's no problem with that. But on
the front end, because of the way that React works,
you cannot actually use a weight in the component itself.
You have to kind of wrap it in use affect
or something. And now you can just use use instead

(51:52):
of effectively as and a weight inside client side components.
So that's really cool. The demo that I'm showing is
effectively just calling this function on the back end in
order to get a value and using that value in
the render to in the rendered component, and I use use,

(52:14):
so this way I get and it's wrapped inside suspense.
So this way it makes the call to the back end.
While it's waiting for the content to arrive. From the
back end, it shows the fallback and or the placeholder
or the loader or whatever. And once that value arrives
and it immediately rerenders using that that value that was

(52:36):
received from back end. It's really cool and it sounds
it's one of those things that's much easier to show
than to explain verbally, all I can say is it's
it's very readable code, much more readable than if I
had to use use effect instead.

Speaker 2 (52:52):
Yeah, that's that's a cool example.

Speaker 3 (52:54):
Like, so you're returning data through an RPC call and
because it's a promise, you can.

Speaker 1 (52:59):
Use use it exactly.

Speaker 2 (53:03):
Oh, that's cool.

Speaker 3 (53:04):
That's kind of like how tanstax start does so actions
as well. So so actions are just RBC call and
typically you put that in your loader, but you could
totally put that as a user as well within your reaction.

Speaker 1 (53:16):
Yeah. It actually is a little bit tricky because if
you're not careful with it, you can get into kind
of this rerender loop because every time the component renders,
you get a new promise, so you kind of need
to be careful about it. And one of the great
things about something a library like ten stack query is

(53:38):
that it does the automatic dedoping or cashing for you
and make sure you get the same promise each and
every time, so you're not getting into these kind of
rerender loops if you're using use So it can be
a little bit tricky if you're using use directly, which
is why i'd probably recommend using something like ten stack

(54:02):
query in these types of scenarios. And and by the way,
going back to my example of r PC, there's actually
I think a ten stack query wrapper for for r PC,
so you can use them together really really nicely, or
just use ten stack start if you want to have

(54:24):
an RPC capabilities in your full stack framework. Cool. Yeah,
it's it's one. It's something that I discussed at links
with our common friend. We found out that he's a
friend of both of us. Jack Harrington. Great guy. Yes, yeah,
I love this guy and he makes amazing content as well.

Speaker 2 (54:41):
He makes amazing content.

Speaker 1 (54:42):
Yeah. Anyway, so yeah, I really like YOUSE. I think
it will definitely change the way that people write client
side components in React, although they're like I said, there
are few gutchas there and people will need to get

(55:03):
used to it and learn how to properly use it
again pun intended.

Speaker 2 (55:08):
Yeah, the suspense is building up exactly.

Speaker 1 (55:11):
Yeah.

Speaker 3 (55:12):
I think news with suspense and new transition and activity
is kind of the future of React and I'm very
excited to see it in action.

Speaker 1 (55:20):
Yeah, I totally agree. I think that Suspense when it landed,
opened up a huge amount of possibilities that this whole
thing about asynchronous reactivity in React is the sea change,
and we're still experiencing the outcomes and the benefits of

(55:40):
these changes, and also the added complexities associated with them.
It's definitely a different model to learn and to understand
with regard to how React actually works and what happens.
When Okay, we're close to finishing our time going to picks,

(56:01):
you know what I'll give us. I'll give us ten
or ten more minutes to talk about React stuff before
we go to picks. Is there anything else you think
we should be talking about in the context of React nineteen.

Speaker 3 (56:12):
I think those are the biggest things that comes to
my mind. I'm super excited about React compiler being stable.
I can't wait for removing I can't wait to remove
all the use numbers and use callbacks. That's the one
that I'm most excited about. Activity is a component that
I am specifically excited about because I've routed a lot
of apps where I've had to actually store the state
so I can wait the refactor my apps, do you.

Speaker 1 (56:34):
Consider Okay, so per my understanding, who's client and use
server even though they need a full stack framework in
order to work, which means that they need either next
JS or ten stack. You would consider them to be
part of React though, right, so they are part of React.

Speaker 3 (56:56):
They are directives, but they I don't think they were
tan stack not.

Speaker 1 (57:01):
Oh yeah, ten stack has its own alternative, I think.

Speaker 3 (57:04):
Yeah, so tanstyle just has like creates so a functional
with just the same as youth server. And then you
don't need to use used client because everything is client first.
I think the only work.

Speaker 1 (57:13):
In next year understood and use cash. That's a next
GS thing. That's not even a reacting.

Speaker 3 (57:21):
Right, I can't remember. I know it's a next gest thing.
I don't know if it's like a React things use cash.
And then there's a new one which creed a lot
of controversy in trying.

Speaker 1 (57:30):
To or use workflow. But that's not even the next
GS thing. That's a verse cell thing. Right.

Speaker 3 (57:35):
So there's so many use hooks, use directives, and the
only place that I've been I've seen them being used
is next year.

Speaker 1 (57:43):
Do you remember the original one? Though? You strict that's
that's where that's that's where they all come from.

Speaker 2 (57:50):
Oh yeah, that's true. Now that's a standard.

Speaker 1 (57:54):
Yeah, well that's part of JavaScript. Even that's not even React.
That's the JavaScript itself.

Speaker 2 (57:59):
I guess that's where it comes from.

Speaker 1 (58:00):
You're right, yeah, that's that's that's the original, that's the
OG exactly. Now we've got all but it's getting to
the point where, if this keeps on going, we'll probably
need some standardization body to ensure that we don't get
conflicts on their various uses.

Speaker 3 (58:18):
Yeah, and that's the thing, right, Like, these are not standards,
they're not type safe, so you have to remember to
add the directors to the files.

Speaker 2 (58:25):
It's a lot of mental overhead.

Speaker 1 (58:27):
On the other hand, they're declarative, which I can appreciate.
Know that originally they were actually if you I don't
know if if you know this or remember this, but
originally they sought to use the file names, so instead
of having used server and use clients, they thought about
having a client dot tx and server dot tsx in

(58:51):
the actual file name. And then they decided that they
needed greater granularity and have it more declared narrative in
the code itself rather than an external place like the
fine name. I think that Swelt, on the other hand,
does intentionally use file names for these sort of distinctions,

(59:13):
so it's a different take on the same approach, but
On the one hand, I really like the declarative approach,
basically saying what you want rather than how to actually
do it. I am concerned about, like you said, all
these users because they're kind of outside the scope of

(59:33):
the language. The fact that it's a string intentionally forces
the language to kind of ignore it and being an
inline string, and there's no standardization around it, and it's
and it's an interesting question. I assume that the linters
will be updated and modified to take this into account

(59:54):
when they're parsing the code. I see no reason why not.
But I have to say that I was thinking at
one point or another that if decorators would have already
been standardized as part of JavaScript and not just as
part of Typescript, then maybe we should have used decorators
instead for these sort of things. That's true, although decorators

(01:00:17):
require classes and React now is mostly class less, right,
so you know, so it's a problem, yeah, Lie Stard, Okay,
we are more or less at the end of our
content part. Is there really anything else we should be
mentioning in the context of React that we haven't Maybe

(01:00:39):
things that you're excited in the in upcoming versions that
you're hoping for the reacting to introduce.

Speaker 3 (01:00:46):
Yeah, so React, like I said, is going to move
into this like ACYNC React version, which is going to
be the future of React. I'm pretty excited about it
because so far we've had to depend on frameworks to
fetch our data. Now it starts to kind of come
back and to React and we don't have to actually
need a framework to use things like use, which I'm
super excited about. So that's something to keep an eye

(01:01:08):
out on. How data fetching is going to change and
how loading components and reading from these promises is going
to change with the future of React.

Speaker 1 (01:01:19):
Interesting. I would like to see some sort of built
in We are kind of we kind of have it
in with React server components, but I would like to
see more explicit support for streaming built into the framework.

(01:01:43):
It actually has to go with another one of the
examples that I have in my talk, which is actually
using a generator on the server if you're familiar with
generator functions, So you can actually wrap a generator as
kind of a server function, and then you create a
stream of data coming into the client and you can,

(01:02:04):
let's say, re render a React component whenever you get
an update from the server, which is really really cool.

Speaker 2 (01:02:12):
Yeah, I need to be going through the next sofait.

Speaker 1 (01:02:15):
Yeah, now right now I need to do something. I
need to use a use effect in order to achieve it. It
would be great if it would somehow be better integrated.
I guess that React the core team would say something
that you effectively can get it using reacts server components already,
but I would like to see something nicer, a real

(01:02:38):
stream type implementation.

Speaker 2 (01:02:41):
Have you tried rendered to pypable stream?

Speaker 1 (01:02:44):
I say, I have to say that the O RPC
implementation is just so nice. I can show it to
you after we finish our conversation. It's just so clean
that I'm happy with it. But if there are alternatives.
After a show, you you can tell me if there
are potentially nicer built in alternatives and React itself okay. Then,

(01:03:07):
So to finish up our show, we have our picks section,
and in our picks we just shout out what'sever interesting
for us or to us. It can be technical, it
can be non technical, any topic that we want. So
I'm going to start, because that's what we do. We
let our guests go last. Oh. The first pick I
had is one that I already mentioned is the fact

(01:03:28):
that I'm the keynote speaker the upcoming React Next conference.
It's actually scheduled to take place on December fifteenth. I
don't know if this episode will air before then or
after then. If you're listening to the live stream, well
it hasn't happened yet. I'm really excited about it. I
think I've got some really really cool demos. It's an

(01:03:49):
interesting topic, one that's really near and dear to my heart,
think that the comeback of o RPC is really really interesting.
Interestingly enough, the very next day, I'm giving a talk,
not a keynote, a regular talk at yet another conference
here in Tel Aviv called no TLV. It's a conference
for no developers, and this is the first time that

(01:04:13):
talk of mine. The title of the talk was actually
kind of censored, i would say, by the conference organizers,
which is really amusing. And when I asked them why
they did it, they basically looked at me and told me,
are you serious. So the title of my talk, the

(01:04:33):
current title, is using heap dumps to find and fix
no JS memory and CPU problems. So I'm basically talking
about how to take heap dumps both programmatically and using
dev tools and whatever other mechanism, and then how to
analyze them in order to find and fix memory and

(01:04:54):
CPU issues. Now, why did they censor the talk title?
Because the original title was taking a dump colon using
heap dumps to find and fix no Jazz memorane CPU problems.
So yeah, I think that was like too much for them.

Speaker 2 (01:05:11):
Oh that's the interesting title.

Speaker 1 (01:05:15):
You should you should see the slides that I'm using.
I didn't censor the slides.

Speaker 2 (01:05:19):
Yeah, I would like to check it out. That sounds
really fun.

Speaker 1 (01:05:23):
Yeah, I think it's going to be good talk. So
I'm giving these two talks, so that would be my
first pick. My second pick is a bit of news
that dropped today or yesterday is the fact that the
Anthropic is purchasing bun. Have you heard about that?

Speaker 2 (01:05:37):
I have not. Oh wow, that's amazing.

Speaker 1 (01:05:40):
Yeah, so bun has been Soldanthropic. It's becoming part of Entropics.
The bun core team including everybody, is going to become
Tropic employees, and they're going to continue working on the
project and the project will continue as an open source project,
so effectively for people who are using bun, it continues
as is in fact the great news because, for those

(01:06:02):
of you who don't know, Bonn was a VC backed
open source company, which means that they got their money
which funded their development efforts from vcs. But vcs like
to see return on investment. In the case of companies
such as Versailles or maintaining nextgs, they were selling hosting
services the same for by the way, Fortino, but bon

(01:06:24):
had no such things. So there was an obvious question
about how bon are going to be able to continue
as a VC funded open source organization without an actual
revenue stream. And the LVIUS answer is they're going to
be sold, and they were sold to Anthropic, and Nentropic
is committed to continue to support them and continue to

(01:06:46):
support this open source project. So it's I think it's
good news for the open source community and for the
future of bon. By the way, we had I forget
the name of Bun's fund. You remember's name. We had
him as a guest on our show as well. I remember, yeah, exactly,

(01:07:09):
Jared Sumner, and we actually had him in a guest
quite a while when Bunn was really really new. We
brought them on to talk about why he built it
and what are is, what's his philosophy and his goal
with his project. It's a really good episode. Even though
it's it's I think it was like something like two
years ago something like that. I think it's still very

(01:07:30):
pertinent and I recommend to our listeners to listen to it.
So those would actually be my picks for today, all
of them technical, I guess. So, Shooty, do you have
any picks for us?

Speaker 2 (01:07:43):
Yes?

Speaker 3 (01:07:43):
I will shamelessly plugged my YouTube channel. You can find
REAC content more of what we talked about, all of
the code examples with It's.

Speaker 1 (01:07:51):
The name of the channel, it's called.

Speaker 3 (01:07:53):
Shuti Kapoor, just my first name and my last name.
You can just YouTube me up Shouty Kapur and you'll
find myna I have like what two fifty videos at this.

Speaker 1 (01:08:02):
Point, Like, wow, that's a lot a lot. Yeah. Do
you prefer the long form or the short form videos?

Speaker 3 (01:08:11):
I like long form because short form is very ephemeral.
Maybe it hits some people and then it just gets lost.
Short long form is more watchable. I feel you can
deliver a lot more content in it, and you can
deliver a lot more value, and you can actually show
like cold demos probably in long form. In short form,
it just gets like weirdly cropped out. I don't like short.

Speaker 1 (01:08:33):
Form, so you're not the TikTok.

Speaker 3 (01:08:35):
Generation, too old for that, But I do like short
form for like quick tips. So in the month of December,
I'm doing the full month of AMA ask me anything serious.
So I have picked questions that people have left in comments,
and I'm making a short form video out of each
of them.

Speaker 1 (01:08:54):
Wow.

Speaker 3 (01:08:55):
So every day I'm answering one question that the audience
has left me in my YouTube comments or in the shorts.
If the audience who's listening to this podcast has a question,
you can also put that in the chat and I
will pick it up and make a video.

Speaker 1 (01:09:07):
Out of it. So of that's awesome.

Speaker 2 (01:09:10):
Yeah.

Speaker 3 (01:09:10):
So, like, especially like when I've made AI videos, people
have asked questions like do you still need to learn
fun end in this age of AI? Or is fun
and going to die because everybody's going to become a
full stack developer. So there's real concerns that people have
and they've left that in comments, and I'm interested.

Speaker 1 (01:09:28):
So primate Gen made a video about the bond purchase
Bianthropic and one of the things he said that here,
here's this company who was into who was basically building
AI development tool, and they purchased a project that's been
developed by programmers by developers. So that goes to answer

(01:09:51):
your question about do developers still have a role in
our world.

Speaker 3 (01:09:55):
Exactly, Like the answer to that question is, like, we're
going to need people who are going to build these systems.
So even if you're writing AI code, we're going to
need people who understand what that front end code should
look like. Like I was saying earlier, like if you
use clod to generate activity code like React nineteen activity code,
it is all garbage, So you need to know what
is the right thing.

Speaker 2 (01:10:13):
Knowing your AI, like knowing.

Speaker 3 (01:10:15):
Your front and fundamentals is very important even if you're
using AI to write code and build complete apps in
the future.

Speaker 1 (01:10:22):
I totally agree, right, So.

Speaker 3 (01:10:23):
Yeah, shamelessly plugging my YouTube channel, go check it out, like, subscribe, comment,
and hit THATLL icon so you get notified at the
new videos. I also want to shout out code Rabbit,
which is a AI code reviewer against. Speaking of AI
code tools, one of the tools that actually helps and
I have been using a lot this year for reviewing

(01:10:44):
my code is code Rabbit. Like I said earlier in
this episode, I have quit my nine to five job,
which means that all of the code I write I
am the only owner, but it gets read by so
many people, so I want to make sure that my code.

Speaker 2 (01:10:57):
Is well written, it is performing.

Speaker 3 (01:11:01):
But also it catches things like it's reviewed properly, and
I'm also catching things like breaking as breaking responses and
error cases. So code rapid has been really helpful in
helping me see those errors, especially things that I may miss,
things that I'm like writing super fast and we forget.

Speaker 2 (01:11:20):
So great code review tool, completely free for open source tools.
Check that out.

Speaker 1 (01:11:24):
It's called code rap I totally agree. We actually use
code rabbit at size Sense, so every every pr undergoes
review by code rabbit in addition to manual review, and
I have to say that it's it's really a great tool.

(01:11:45):
Very often I find and fix most issues before they
even get to be to the point where you know
the manual review is required. So we still require man
your review, but by the time we get there, code
rabbit is probably I probably fixed like five or six

(01:12:07):
different things that code rabbit has found for me. Two
things that I really liked about code rabbit is first
of all, the way they kind of use emojis to
indicate what they're doing, like the eyes emojis like that
I'm looking at it or stuff like that, or like
the thumbs up emoji. And basically they make very effective
use of emojis to indicate what's going on and even

(01:12:31):
allow you to respond to their comments. Like say, if
you want to basically say yes, I'm handling I've handled something,
or i'm handling something, or i'm intentionally or I hear you,
but I've decided to ignore this recommendation, you can kind
of indicate those things your intentionality using emojis, which is

(01:12:52):
really cool. So that's one thing I really liked about it.
And another thing that I really liked about it is
that it also kind of diagrams you code, so even
if you're getting a person to review your code in
additional to code Rabbit, it can make it very much
easier for them to actually understand what they're looking at,
what the changes are then stuff like that, Like you said,

(01:13:15):
I really like and appreciate that tool.

Speaker 3 (01:13:17):
Yeah, And on top of that, it also adds to
the summary of the pr itself. So let's say if
you're somebody like me who hates writing PR descriptions. It
can actually improve it for you by looking at what
code you're adding, so it'll add an I summary of
this was what was added these other features.

Speaker 2 (01:13:34):
This is a code chain, so it's.

Speaker 3 (01:13:35):
Really helpful in making a like the code view process
much smoother.

Speaker 1 (01:13:40):
Totally agree with you, So you kind of gave it already,
but let's give it yet again. If people want to
get in touch with you, contact you, maybe send you
a questions so that you can create videos about them.
What's the best way to get in touch with you?

Speaker 3 (01:13:55):
Yeah, so the best way to get in touch with
me is to actually comment on my video. I obsessed
watch my videos comments and read all of them. Oh no,
I know people have told me not too, but I
can't stop. That will be a new Year's resolution. But yeah,
you can actually leave a comment on any of my
video to let me know what video you want to
see next.

Speaker 2 (01:14:15):
But you can also send me a DM on Twitter.

Speaker 3 (01:14:17):
I'm at schutikapour zero eight my first name, last name,
and zero eight, which is my birthday. I'm obsessed with
my birthday just coming up in five days.

Speaker 1 (01:14:27):
Oh you're you were born in December. I was yes,
so good for you mine as well. So I was
talking about the fact that I have these two conferences
on the fifteenth and the sixteenth. Actually, my wife's birthday
is on the fourteenth, and my own birthday is on
the seventeenth, so we have my wife's birthday, then one

(01:14:48):
conference and another conference, and then my birthday. So it
an interesting week.

Speaker 2 (01:14:52):
It's like sandwich between conferences.

Speaker 3 (01:14:54):
They can celebrate and then go enjoy the conferences and
then celebrate your amazing talks exactly.

Speaker 1 (01:15:02):
So first, so happy birthday to you, thank you, and
to you, thank you very much. And I guess that
with that will will wrap up right.

Speaker 2 (01:15:12):
Nothing more to add, nothing more to add.

Speaker 1 (01:15:14):
So thank you very much to all our listeners. It's
been a great episode. Thank you Shouty for coming on
our show to talk about REACT nineteen or actually, more
accurately nineteen point two, even though we also talked about
REACT nineteen in general. And to all our listeners, thank
you very much for joining us and see you again
next time. Bye.

Speaker 2 (01:15:32):
Thanks for having me
Advertise With Us

Popular Podcasts

Stuff You Should Know
Crime Junkie

Crime Junkie

Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by Audiochuck Media Company.

NFL Daily with Gregg Rosenthal

NFL Daily with Gregg Rosenthal

Gregg Rosenthal and a rotating crew of elite NFL Media co-hosts, including Patrick Claybon, Colleen Wolfe, Steve Wyche, Nick Shook and Jourdan Rodrigue of The Athletic get you caught up daily on all the NFL news and analysis you need to be smarter and funnier than your friends.

Music, radio and podcasts, all free. Listen online or download the iHeart App.

Connect

© 2026 iHeartMedia, Inc.