February 13, 2025 • 67 mins
In this episode of JavaScript Jabber, panelist Dan Shappir sits down with guest Aden Bai to delve into the nuances of React performance. Broadcasting from Tel Aviv, Dan welcomes Aden, who is based in San Francisco, for an insightful discussion on optimizing React apps. Aden, known for his projects Million JS and ReactScan, shares his journey into coding and his focus on enhancing web performance. Together, they explore the intricacies of the virtual DOM, React rendering processes, and the common pitfalls that developers face in managing performance. Aden introduces ReactScan, a tool designed to visualize and troubleshoot performance issues in React applications, making complex profiling accessible to a broader range of developers. The conversation also touches on broader performance metrics like Core Web Vitals and the challenges of maintaining efficiency across various devices and browsers. Whether you're a seasoned developer or new to React, this episode offers valuable insights into creating faster and more efficient web applications. Tune in to learn how you can improve your React project's performance and user experience with tools and techniques from top industry experts.
Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
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,
I'm all on my lonesome Dan Shapier coming to you
from Tel Aviv in Israel, and I'll be interviewing Aidan
by Hi. Aidan, Hi, how are you? I'm doing well overall?
How about yourself doing well?
Speaker 2 (00:27):
It's a not so hot, not too cold day in
San Francisco.
Speaker 1 (00:31):
So that's lovely. It's kind of same over here in
Tel Aviv, so please we're sharing good weather, and we
are here today to talk about React performance. But before
we start, Aidan, maybe you can tell us a little
bit about yourself and your very lengthy career in tech.
Speaker 2 (00:53):
Yeah. I gotta started hooting in middle school. But like
you might know me for a million, Jess, it's like
I tried to make a compiler for React and then
more recently React scan, which is all like the purple
flashing boxes on all these popular websites. I U see
it on Twitter. I've mainly mainly focused on performance most
(01:16):
of my life because I think it's an interesting problem.
Not many people focus on it, and it's also very hard.
Speaker 1 (01:23):
Yeah, tell me about it. It's been one of my
main focuses for the last couple of years. For those
of you don't know, I also happen to be an
invited expert on the W three C where Performance working Group.
Maybe you should join us there as well. We talk
about things not so much related to React, more about
the relevant web standards, things like core vitals and stuff
(01:46):
like that, and the APIs in the browser that can
be used to retrieve them, to measure them, et cetera.
I know that it's not our topic, but I do
want to talk a little bit about million js because
it seems so interesting. So so as I recall it,
it's kind of a drop in replacement for the mechanism
(02:07):
in React that transforms the virtual dome into the actual dome.
Is that a more or less correct description.
Speaker 2 (02:16):
Yeah, that's correct. Like basically how React works under the
hood is it takes like two versions of the view,
so like the old version and the new version, and
then it reconciles it, like it figures out the differences
between those and then it applied it to the actual dome.
But like this is like an an operation or some large,
big old notation that's over one. And the problem with
(02:41):
that is if when the versions get really big, like
the trees get really big, you're doing a lot of computation.
So I was like, okay, wouldn't be cool if you
could pre compile this, Like okay, based on the JSX
you provide. There's like obvious points where it actually changes,
like when you have those JSX container expressions, like the
(03:02):
when you passing some data in, So I pre compile
that and then found like the specific code paths that
matter to make the dom changes. So every time you
render a component, instead of doing that whole reconciliation process,
it just changes the dom like like pinpoint processes, basically.
Speaker 1 (03:21):
Kind of implementing fine grain reactivity in a sense over
on top of React.
Speaker 2 (03:27):
I guess, yeah, like benef it's a fine grain reactivity,
but without using fine grain reactivity.
Speaker 1 (03:33):
Yeah. I think you kind of mentioned several things that
are kind of important in the context of React performance
as you were describing this. I think that first and
foremost is this whole thing about virtual dom and the reconciliation.
We actually had a couple of chapters in JavaScript jabber
(03:56):
talking about the virtual dom, what it is, why it exists,
et cetera. But I still think it might be worthwhile
to talk a little bit about what it is because
it's so central to everything we'll be talking about today.
So can you tell us a little bit about you
the virtual dorm from your perspective.
Speaker 2 (04:14):
Yeah, virtual dom is basically it's kind of an overloaded term.
It's basically taking two like versions of the UI and
figuring out the princess between them and then actually changing
the UI. React doesn't actually hold the dom tree inside
of itself. I mean it kind of does, but like
(04:34):
when it does when it figures out what to change,
it doesn't actually store the dominodes as the whole tree
and then dip the dominance. It difts like a virtual
version of it. This can lead to some problems. So
for example, like for Facebook, it might be somewhat okay,
like when you were switching pages, but like if you
(04:54):
are creating like a stock trading app, like a stock
treating dashboard, where like there needs to be like updates
every several like some amount of milliseconds, or you're making
like significant dom mutations every single second, or if your
website targets it targets like very low end devices, then
(05:15):
that sort of mechanism can lead to some performance problems.
Speaker 1 (05:20):
I think the key aspect here is that React took
what I considered to be kind of an idealized approach
to UI generation, which is, let's in an ideal world,
I would say react. The React approach is, let's take
the entire application state and apply like a function to it,
(05:45):
a pure function even that generates the UI that the
user sees, and that every change in the state would
ideally again regenerate the entire UI. So you know, you
check or uncheck a small checkbox in the UI, and
(06:06):
theoretically the entire user interface of the application gets re
rendered because then you don't need to think about state
changes in the user interface. It's just everything again and
again from scratch. But the problem with this approach is
that a naive implementation would obviously be just way too slow.
(06:30):
It's kind of taking, by the way, the approach that
we had in the old days of the multipage applications
and kind of applying it to the client side rendering
mechanism that we have in JavaScript code that updates the
don in that in the old days you would go
to the back end and then you would get the
(06:51):
entire page back each and every time. So it's kind
of like doing that, but again but doing everything on
the client side and doing it for every state logical change.
And the virtual dom was like the first thing that
they implemented in order to make it viable the from
the perspective of performance, that is the virtual dom. By
(07:11):
the way, it's a fancy term, but really really all
it means is JavaScript objects. Really, that's all the virtual
dom is. So instead of having actual dom elements, which
are rather heavy because of all the functionality that they encapsulate,
you just use JavaScript objects simple JavaScript objects as stand ins.
(07:34):
And like you said, when the state changes and the
new virtual dom is created, React then takes the new
virtual dome the old virtual dome, does a comparison, finds
the differences, and then calculates the minimal amount of actual
dom changes to transition from the first state to the
(07:55):
second state. And that's the reconciliation process. And for a
long time it was thought that it was that approach
was good enough in terms of performance. But like you said,
when user interfaces started becoming more complex, complicated or more complex,
and as we needed to support lower end devices like
(08:18):
more mobile devices for example, and as we needed more
frequent updates, even this type of optimization started to break
down because doing all this reconciliation work still has overhead,
and this is when million js, I guess came in
(08:38):
to start to try to reduce that. But like you said,
being able to be smart about pinpointing the exact locations
of the differences and not having to do the entire
comparison of the entire virtual dom tree, right, yeah, exactly.
Speaker 2 (08:55):
I view like virginal dom is more of in historical context,
like it's more of getting things correct. Like before people
use like Backbone or they roll their own JavaScript libraries
and this would literally results in like like there were
literally so many frameworks like bugs and these frameworks. Virtial
dom is like a very exhaustive approach to the problem.
(09:17):
But it's more likely to get things correct than that.
Speaker 1 (09:21):
Yeah, because when you're essentially building the entire UI from
scratch from the current state, you don't have to worry
about an incorrect UI transition or state transition messing up
your display. I think, uh, Facebook had they had this
story about one of the motivations for creating React in
(09:43):
the first place, is that they had a counter in
their user interface about the number of messages that you
had pending or something like that. And any change to
that mechanism was always buggy because they always had to
somehow sync with everything else that was changing on the page,
(10:04):
and because so many things were changing more or less
concurrently in the UI, all of them as synchronous to
each other, they would always get into age cases and
age situations. And being able to just re render the
entire UI from scratch virtually solve that problem very neatly.
(10:26):
But again, so we had a couple of performance issues.
One performance issue is the one that you addressed with
the mini and JS, which is the fact that even
that sophisticated reconciliation could be too slow, especially if the
virtual dome was really large, especially if the device was
(10:47):
low end, and especially if you did it very frequently.
The other problem, I think is that even building the
virtual dome, which is mostly just running your code that
generates the JAX from the state, can be heavy and
performance intensive if done too often, or if if it's
(11:12):
just too complicated. And I think that this is where
reacts can comes in, because it's that's your new project,
the one that we're going to talk about, because it
strives to, if I understand, correctly, minimize the amount of
redundant helps you help you to minimize the amount of
redundant rerenders that you perform. Correct.
Speaker 2 (11:36):
Yeah, exactly. I can give a brief introduct. Basically, react
scan is a tool that helps you find like re
rendering performance problems and you react ap today. You can
just drop it in your app as a script tag
and it basically highlights the components that render and potentially
slow down your app. I spent like maybe three years
(11:57):
optimizing websites, everything from like webar you see, like virtual
camera websites to e commerce websites. There's like static sites,
and when I try to debug these performance problems on
these sites, it's really hard. Like it's either like I
do console that time and time end, or I use
Lighthouse scores, which is like at skill level zero to
(12:19):
profiling tools and Chrum dept tools. React to have tools
at like skill level one hundred, and so there's like
nothing in between those those two types of tools. And
this made me really frustrate, right, I Like I spent
so long just trying to understand how these level one
hundred tools work that that I realized that most people
don't have the time or ability to figure it out
(12:44):
exactly so react Skain helps bridge the gap. Today we
do renders, but soon we'll support more stuff. More stuff
in that like I n p cls LCP which are
like the lighthouse Google Lighthouse scores, as well as stuff
like lung tasks. F he has all of this, like
(13:04):
metrics and stuff that take They are decently like, not
like decently hard like recently not easy to measure correctly
and interpret.
Speaker 1 (13:15):
Basically, so you threw out a bunch of metrics and then,
as I mentioned, metrics are near and dear to my heart.
They're part of what I do on the W three
C Web Performance Working Group, which I'm an invited expert on.
I think the three main ones referred to as unsurprisingly
(13:39):
as core web vitals because they are the core ones.
We talked about them on the show on several occasions.
I think we even had specific episodes dedicated to them.
But still again, it might be worthwhile to mention what
they are and what they measured. Do you want to
do that or should I?
Speaker 2 (13:57):
I can explain like ten seconds like I'm he is
basically interacting in a page and getting the result back visually.
LCP is basically the largest like content fil basically any
elements with text or some big text in it. In
it is the like however, time it loads and then
(14:17):
CLS is basically how much your page layout shifts. You
want your IMP to be as low as possible, you
want your LCP to be low as possible, and CLS
to be low as well.
Speaker 1 (14:29):
Yeah, exactly. And it's interesting because there they are not
trivial in the context of React especially. Yeah, and it's
interesting because different facets of React address different these different metrics. So,
for example, if we're talking about the largest content for paint,
(14:51):
which like you said, is the amount of time from
when the page starts loading until the largest piece of
content is actually rendered on the browser screen, if we
think about what React does to try to optimize it.
So initially React, for those who who may not recall,
was just client side rendered, and that kind of guarantees
(15:12):
slow LCP by definition, because nothing is shown until all
the JavaScript is downloaded, including React, and then the client
side javascripts need to do the ajax calls to get
the data and then render the UI based on the
data and the code, and only then do you actually
(15:33):
see anything on the screen. So that's when React introduced
service side rendering, or SSR and static side generation or
SSG with meta frameworks like next JS or remix. So
(15:53):
it's by the way, it's interesting in this context that
still many organizations that I ounter don't really care that
much about LCP in the context of React applications, because
a lot of the web applications that are built using
React are things like dashboard or internal enterprise applications, and
(16:16):
there the approach is that it's loaded once and then
used all day long, and therefore the loading time is
less important. I actually think that in many cases this
is a misguided view because, for example, let's say you're
commuting to work on a train. You want to use
(16:36):
that time you're connecting via VPN into your internal network,
you're loading your internal application, and it takes your entire
train ride to actually load, which isn't fun. But be
that as it may. So that's LCP. There's the IP
which you mentioned, which is how responsive the pages to
(16:59):
interac actions, how long it takes the page from when
you actually click on a button to actually render the
result of clicking on that button. And again, React can
be really problematic there because if it's doing very lengthy
rendering operations or re rendering operations and you click in
(17:22):
the middle of one of these operations, then it won't
actually respond or do anything until all that JavaScript finish
is running. And CLS, I think, is the one that
is least directly related to React itself, because it's more
it has more to do I think with how you
(17:42):
start your CSS stuff like that. I would say though,
that for people who are using what's it called React suspense,
they need to watch out for CLS because if they're
(18:02):
loading code doesn't match the size of the actual finally
rendered component, then things will shift after the after the
load the loader is done, So so you do need
to watch out for that if you're using suspense in
the context of React, I think would you agree with that? Yeah?
Speaker 2 (18:23):
Also for images, right.
Speaker 1 (18:25):
Yeah, but images are there, you know that's a universal
issue that's not reacts butific Yeah, so million js kind
of addressed I guess both LCP because you were running
the rendering code faster, and also it kind of addressed
(18:47):
I n P because it blocks the rendering time for
a shorter period of time. What I understand that you're
addressing with reacts scan is most about figuring out how
to do less rendering and also generally make the rendering
(19:08):
itself faster, which again will would primarily benefit I n P.
I guess.
Speaker 2 (19:16):
I see it as like rendering is always somehow related
to some performance problem on the page if you use
it reacts site like I'll give a couple examples, like
for example with with with CLS, right, it could be
a styling issue, but as a user, I want to
know like where that specific uh specific like layout ship
(19:42):
is occurring with i MP. I want to click a
button and I want and there's like maybe a bunch
of renders. I don't know why it's slow. A rendering
is somehow always somehow related to that, even LCP, as
you said, right, like like if there's a lot of
rendering on the page that doesn't need to render, like
maybe below the folder outside the viewpoort, then it's not good, right,
(20:05):
even like other performance issues like when FPS drops or
like I'm trying to think of other examples, but like
whenever the page feels sluggish, it's always rendering is always
somehow related to the problem.
Speaker 1 (20:19):
So FPS, can you elaborate on what that is?
Speaker 2 (20:22):
FPS is frames per second? Basically this is important for
movement or animation tasks, so like when you scroll the
page or something is animating like rainbow gradient. For some reason,
that FS is important. You want to usually keep it
over sixty fps.
Speaker 1 (20:42):
It is the standard. And again JavaScript gets in the
way because the main thread, well the browser is kind
of not exactly but mostly single threaded, so whenever you're
running JavaScript, it kind of blocks everything. And if you're
blocking everything too much, then you get jank or jitter
(21:02):
because you're not able, like you said, to hit that
sixty fps. I totally agree with what you said about
identifying things that render needlessly. My own experience is that
a lot of React teams don't even ever get there. Basically,
when they see that something that the UI renders correctly,
(21:26):
that's good enough for them, and they don't care about
the fact that it's rendering correctly over and over and
over again, effectively doing a lot of work at the
virtual dome level without actually ever updating the actual dome,
because the reconciliation basically notices that they're just recreating the
(21:47):
exact same virtual dome over and over again. But even that,
even though it's cheaper than updating the dome, still you know,
accumulates if you concer doing that you're literally just running
an infinite loop of JavaScript that's doing nothing. Is that
has that been also your experience that it happens in
(22:08):
a lot of organizations and a lot of websites.
Speaker 2 (22:11):
Yeah, that's definitely one of the problems. It's also I
don't think it's necessarily engineer's fault, right, it's really hard
to care about these things because they're not visible. Just
like if the page UI is not correct, it's very visible.
You have to fix it. If there's an error, you
have to fix it, right, It's not like you can
avoid these things. The performance you can really easily avoid
because most developers use like a really high end MacBook
(22:34):
or high end PC where you can like any performance
problem you can blaze through and like basically hit with
no problem. And also developers are so used to slow
build tools and slow like development startups that like one
hundred three or real seconds it feels like nothing. So
the problem is performance is not visible, and developers are
really out of touch in touch with users for performance,
(23:00):
like even even if even for like performance experts who
like think about performance every day, they're also not super
in tune with like the actual products performance Like maybe
they go to data Dog and they see the metrics
and they're like, okay, how can I improve this today?
Or they see a regression in performance after a specific
git commit, But then it's like, okay, what do I do?
(23:22):
Like how do I reproduce this? It's kind of hard
to do those things. Reacts again is our attempt to
try to fix some of this, right, Like how how
do we make performance visible? Like how can we show
developers that there's problems on the side without like having
them loaded up on a Moto G four or something.
Speaker 1 (23:42):
Moto G four, by the way, for those of you
are too young to know, is an old Motorola phone
that Google still uses virtually for simulating performance of websites
on low end devices. If you're using Lighthouse, that's what
they there. Okay, then so you want to visualize the
(24:06):
performance issues, how do you go about it? What do
you actually show? How do I see that I have
a performance issue in my React website? By the way,
the tool is for React, right It's not you know,
for websites that aren't React based.
Speaker 2 (24:21):
Correct, Yeah, React for now? Right now? We highlight renders
and if there is some sort of long task or
FPS drop or imp that's really high. We turn the
color of the renders to like from purple to like
red or something. In the future, we wanted to have
more visualizations, like when I click a button, what is
the IMP or like the local tested imp we have
(24:46):
like or like what is the like long animation frame?
Like when a long animation frame happens. I want to
see that the long animation frame happens. I want to understand,
like when jink happens, or when jink happens, what is
the cause of that. Jink renders is like our base
abstraction basically, like usually it's always related to It's like
always somewhere within the problem, and so we show it
(25:11):
via renders basically.
Speaker 1 (25:13):
So basically, if I understand correctly, you're adding rectangles around
the React components that get rendered. And these components and
these borders kind of highlight whenever the component renders. So
if it's constantly highlighted, you know that this component is
(25:36):
for some reason being constantly re rendered. Right and and
by the way, again, re rendering is at the virtual
dome level, so even a component might be re rendered
even if nothing actually is changed for it in the
actual browser dom. Correct, yes, yes, So it's it's your
(25:58):
code and React code doing work for that component, whether
or not anything actually gets updated in the actual display. Yep.
And usually the border would have one color what is it,
Like you said, purple or something like that. But if
it's resulting, if it's causing the browser itself to actually
(26:23):
experience delays, then it will actually change color and become red.
Speaker 2 (26:28):
Exactly.
Speaker 1 (26:28):
Yeah, very cool. So I assume you've tested it on
various websites and saw them flashing rectangles all over the place.
It gives like interesting examples.
Speaker 2 (26:43):
A month ago, I founded this performance problem on the
GitHub site when you would scroll on the code every
line of coder Revender. So I tweeted it, got a
lot of likes, a lot of views, and then I
don't remember their name, but someone from the VP of
the roll GitHub was like, hey, one day later, hey,
we fixed this issue. When I tested it, the fs increased.
(27:05):
Now it was like, holy crap, like's it was really cool.
How just this random package we made and then just
tweeting it out and just showing a video of it
actually made a real performance change on the site.
Speaker 1 (27:18):
Yeah, yeah, that's really cool. And my experience is that
it's exactly that that it's very difficult to notice that
the problems exist, especially like you said, when developers have
really high end max and stuff like that. But once
(27:39):
you understand where the problem is in a lot of cases,
not all cases, but in a lot of cases, the
fix is fairly straightforward. You've got let's say, some use
effect that's updating a state, which is retriggering the use effect,
which is again updating the state and over and over
and over again in this kind of an infinite rendering loop,
(28:02):
something along these lines. Yeah.
Speaker 2 (28:04):
Yeah, the main hard part of performance isn't the solution.
The solution space is actually really small. It's usually like
one to five solutions for every problem, But finding the
problem is the hard part. It's almost ninety nine percent
of the work.
Speaker 1 (28:25):
Yeah, I totally, I totally agree with that. By the way,
I'm just there are a whole bunch of sirens in
the background, so I apologize for being a bit distracted. Yeah,
that totally matches my own experience that it's sometimes that
being able to pinpoint the cause of a performance issue
(28:45):
is the hardest problem. But you know what, in that regard,
it's not that different from a lot of bugs. You know,
the famous Heisen bugs that happen occasionally are very difficult
to reproduce and figure out, and then you know, you
smack your head when you realize what the problem is
because the fix is often very very straightforward. My question
(29:10):
then is how were you able to get this information
out of React? I mean, you know, React doesn't exactly
tell you that, hey, you've got a performance issue. It
just does this whole rerendering thing kind of automatically behind
your back. So how did you figure this out?
Speaker 2 (29:30):
Yeah? Most simply so, React dept Tools has information about
componentry and renders. Well how does it do this? Well,
React internally has it attaches like a property on the
window object called React depth tools Global hook, and it
has much of information about the fiber tree, and so
(29:51):
reacts can internally uses that to get information about fibers
just for context. A fiber is basically like the virtual
do on how React internally represents the user interface. We
can use the fibers to detect renders, and then we
show those renders using a canvas on the screen.
Speaker 1 (30:12):
So base, ah, you're using You're not modifying the CSS,
You're actually using canvas in order to draw the stuff
on the screen.
Speaker 2 (30:22):
Yes, if we modify the CSS, there would be like
some overhead on that, so any performance score you would
see is going to be noticeably like it's going to
be artificially inflated. So what we did was we put
the canvas on a worker thread, so it doesn't have
as much performance impact as if you actually modify the CSS.
Speaker 1 (30:42):
Ah cool, So what you're saying is you kind of
put an invisible canvas on top of the entire rendered screen.
I guess, and you're and canvas can be updated from
a worker thread off of the main thread, which is
(31:03):
not something you can do with the regular browser dome.
So you're able to draw into this wholly separate user
interface GPU layer without impacting the rendering time of the
actual browser at all. That's very very cool.
Speaker 2 (31:27):
There's a little bit overhead because we have to still
send the data over to the worker thread, but from
our testing it's pretty minimal. It doesn't affect like the
standard metrics as much.
Speaker 1 (31:40):
I understand, but for example, you still need to for example,
get the rectangle the actual rectangles on the display of
the dome elements, and if they there scroll, you kind
of need to move the rectangle along with them. Or
something or things along that line. Correct, So that does
(32:03):
still take a little bit of overhead in terms of
work on the main thread. But basically you're just firing
that throwing that over into that worker and it does
the heavy lifting exactly. Yeah, have you measured the impact
the performance impact that having reacts can on the site
(32:24):
actually has, because that's that's indeed a real problem that
you know, it's kind of like quantum physics, where you're
measuring things can actually impact the behavior of the application.
Like I recently saw a tweet about somebody saying that
he had a bug in there in his code. He
(32:44):
added the log, the bug went away, he removed the log,
the bug came back. So sometimes even the act of
measuring can really impact the performance and behavior of the
of an application. So how how did you actually verify
that you have hardly any impact on the run time
of the application itself?
Speaker 2 (33:06):
Measuring here, Like it's like not really a good way
to figure out the overhead. Like, basically we run on dev,
which means they're using development builds, which is not the
same as a production build. So development bills will likely
be slower than production builds on a basic app. It's around,
it's like less than one percent. At more heavy apps
(33:28):
still less than one percent. But like in reality, we
like you can you have to like measure on like
a large scale applications and actually on the correct build
of the app to understand the overhead. Right now, it
doesn't matter too much, but like as I said, like
it maybe for some edge case it might be much
more question.
Speaker 1 (33:53):
As you said, you're using the same APIs that React
dev tools uses internally, in fact, by the way undocumented APIs.
As I understand, what is the advantage then of using
React scan over just using the React's own developer tools
(34:16):
for essentially the same purpose because they also have a
performance view in there. If you install the Chrome extension
for the React Developer tools, for example, you get a
performance tab, a React performance tab in the developer tools.
So what's the advantage of using a React scan over
that capability that React provides themselves out of the box.
Speaker 2 (34:41):
Yeah, Like I view React Depth tools as like the
endgame of debt tools. Like it's it's a great version.
There's obviously improvements that can be made, but it's like
the best React depth tools React.
Speaker 1 (34:54):
Right.
Speaker 2 (34:56):
The problem is, like you need kind of like a there,
there's there's like a very low like you have to
be decently skilled at using React deaf tools or crumb
debt tools in order to use those depth tools, and
most people don't really know how to do it. React
scin is a more accessible version of it, specifically for
(35:16):
rendering and performance app performance issues inside your React app.
React deptols is more general, more advanced depth tools for
interacting with your app. Uh yeah, I use React and
React depth tools. Uh for my use case.
Speaker 1 (35:36):
Oh okay, cool. So when I used React scan is
it Does it even require the depv tools to be open?
Or do I just see everything on the browsers display.
Speaker 2 (35:48):
Itself undevelopment in development, you just drop a script tag
into your like head tags and then it should.
Speaker 1 (35:55):
Work and you don't need to open depth tools at all.
Speaker 2 (35:58):
No, no, yeah, you just have it. It just runs
you know where.
Speaker 1 (36:02):
That's potentially a very significant advantage on mobile devices. The
fact that I can just drop in a script tag
and see the issues on the browser screen itself is
a big advantage in terms of identifying such issues versus
(36:25):
having to attach the phone a physical phone via a
physical wire to a mac or PC in order to
open a remote debugger and then debug everything that way.
It's a much more convoluted process. If I can just
see all the problems directly on my mobile screen, that's
(36:45):
a huge advantage from my perspective.
Speaker 2 (36:48):
Yeah, that seems like a really good use case.
Speaker 1 (36:51):
Now do you only show the squares with the colors
or do you sew additional information there?
Speaker 2 (36:58):
So induce us shows some additional information on the screen itself.
So each rectangle will have a little label on it
showing the component name and also how many times renders
and how much time it took. You can also there's
like a in browser toolbar. You can inspect any component
or render to see when it renders. You can replay them.
(37:19):
You can see what props change, what state changed, where
context changed, and you can just figure out exactly what
are the props or attributes or information about the React
component that are causing the problematic performance.
Speaker 1 (37:33):
Wow, that's really really cool. By the way, when I
drop in that script tag, does it automatically enable this
you AI, or do I also need to do something
in the browser itself to enable it, Because I'm thinking
that in some cases people will want to have that
(37:57):
script tag be present, you know, all the way is
but not have all the users seeing those rectangles.
Speaker 2 (38:05):
Yeah, by default it only runs in developments. We do
offer like programmatic off and on APIs. So like companies
like Notion or Shopify, what they do is they are sorry, yeah,
Shopify Notion, they have an internal to bar and basically
you can click like turn React scan on and it
(38:25):
turns the and opens the React skan overlay and two bar.
Speaker 1 (38:30):
What you might want to do as well is maybe
add the support for a special URL parameter m HM,
so that you could turn it on or off using
a URL parameter that you know doesn't hopefully doesn't conflict
with anybody's URL parameter, but that would make it especially easy,
(38:52):
especially on mobile. I thinking that that would be very useful.
We did similar things at Wix where we added special
debugging capabilities into Wix websites, but they were only enabled
with a very specialized, well not document not externally documented
(39:13):
URL parameter, obviously nothing that could actually break a website.
You know, you need to be careful because their potential
security issues around that. You know, somebody could send the
link with that URL parameter to somebody and then they
would see the red lines and then they would get
(39:33):
all freaked out because they would think something is wrong
or something along these lines. But in general, I think
that this can be a useful feature.
Speaker 2 (39:45):
Yeah, that's awesome.
Speaker 1 (39:46):
Right after this podcast, I'm glad that I can help
make the product better. I also saw various demos that
you were showing about all sorts of ways to graph
the component hierarchies in the React application. Is that also
part of the same thing.
Speaker 2 (40:06):
We haven't shipped that, but we're just playing around with
what visualizations would work. So, like for context, I was
working in this really large enterprise e commerce app and
they had a bunch of components depending on the same context.
But it was really commolluted, right because they were like
nested hooks. There was nested components, Like a bunch of
(40:26):
stuff was re rendering. I didn't know why. So I
spent like ten hours just on tl draw graphing out
the entire code base from the route that.
Speaker 1 (40:36):
Was re rendering.
Speaker 2 (40:38):
And I was like, why the why the heck am
I doing this? Like like this is like so much
work just to figure out why all these components are rendering.
One thing we want to do this, dude, try is
doing this automatically? Like, can we graph out the component
tree and also the hooks tree and show where the
source of the problem is most like re rendering issues,
(40:59):
like they can be caused by a higher component or
a context, but usually they're systemic, right, Like, it's usually
like one context causing all these components to rerender, and
all these components have faulty implementations that cause this performance issue.
So we're trying it. We're trying some visualizations to help exces.
Speaker 1 (41:19):
So we have a user from LinkedIn to asked, what
is the business model for the react scan project? Is
there a cost to using react scan? I'll fill in
the blank. Is it open source? Is it free? What's
what's your business model around this tool? Are is it
already released? Is it beta? Where are we at?
Speaker 2 (41:40):
Yes, it's it's not one point oh, but you can
it's stable, you can try in your app. It's free,
open source, you can copy the code, you can fork it,
you can do anything with it. If your company requires
it's a host on our internal package. You can do
whatever you want. The way we make money is through
monitoring and observability. So we have a different product that
uses is React scan on in like et or staging environments,
(42:06):
so you can run your playwright test. We figure out
the performance scores of these playwright test and tell you
whether the performance increase or decreased. This is a This
is a real problem because like most observability tools like
Century data DOT, they're really confusing, right, you have to
like read profiles, the graphs are somewhat like we'd like,
(42:27):
and it doesn't really tell me like what is the
root cause of the problem. We're trying to solve this.
We're trying to do this specifically solve this for React.
Speaker 1 (42:34):
So it's it's essentially a performance budget tool for React applications.
Speaker 2 (42:40):
Yeah, exactly.
Speaker 1 (42:41):
By the way, for again, performance budget is something that
we mentioned in previous episodes for those of you don't
remember or don't know what it is. A performance budget
is a way to say, like, specify how much how
performance I expect my application to be, and then during
the testing process in your CICD flow, you can measure
(43:07):
the performance of the latest build, compare it to your
budget limits, and if you exceed your budget limits, you
essentially break the build like you would for any other bug.
And then the only way in which you can release
it is either fix the performance issue that you're under
budget again, or unfortunately, in some cases, you might need
(43:31):
to increase the budget because maybe you just made the
UI more complicated and sophisticated, and therefore it's a legitimate
decision to make. But you're doing it with full awareness
of what you're changing. It's not just something that happens
and you're not even aware that it's going on, that
your application is becoming slower. So you're building a performance
(43:53):
budgeting tool that's focused on React application. It's not just
working at the co word vital is level. It's focused
on React and it helps you understand how you React
application is actually working in terms of performance, and if
you exceed your budget, not only does it break your build,
but it also tells you where the problem is likely act.
Speaker 2 (44:17):
We do also do quero vital So basically, the data
hierarchy is interactions. So if interaction becomes slower or your
playwright test that's a problem, then we go a little
bit deeper out like if an interaction is slow, what
components may have caused that? Or what components underwhere may
have caused that? And then potentially like down to the render,
(44:38):
like what props, context or state may have changed.
Speaker 1 (44:43):
Now, what I'm thinking that might be really useful in
this context is something although off the top, I'm not
exactly it's more of a vague idea that I have
rather than a plan. But you know, one way in
which REACT performance is improved in at least in perceived performance,
(45:04):
if not actual performance, is using suspense by deferring rendering
of certain non urgent UI components. Maybe they are maybe
they're outside the visual display area, or maybe they show
lower important information or stuff like that. How do you
(45:31):
handle those? Can you recommend to me that this thing
should be should use suspense or stuff like that? Is
that something that you're thinking about or looking at?
Speaker 2 (45:41):
Yeah, of course that's all on scope basically.
Speaker 1 (45:46):
Cool, and so any like hints about what you're thinking
about doing in this.
Speaker 2 (45:54):
Context specifically, For so, there's a couple applications like things
outside the viewport well and it if it renders, we
mark that as like an unnecessary render. M hmm, like there,
I mean, like obviously there are different solutions here, like first,
maybe don't render it, or maybe there are some like
(46:14):
hacky solutions for like partial hydration, like don't hydrate unless
it's viewed, or like suspense as you're saying, we don't
do recommendations yet, but we do detect the problems itself
right now.
Speaker 1 (46:29):
Okay, So when you're doing when you're doing the that
rectangle highlight, if the rectangle is wholly outside the visual
the visual viewport, then it gets kind of flagged and
logged that, hey, this was an unnecessary render. You should
(46:50):
be doing something about avoiding avoiding.
Speaker 2 (46:52):
That exactly, Yeah.
Speaker 1 (46:55):
Or postponing that or so something along these lines. That's
very very nice. So you said that you're using both
React scan together with uh the with the React dev tools.
What where do you focus? What information do you get where?
(47:19):
Like what's the benefit of using them both together? Yeah?
Speaker 2 (47:22):
Anywhere from like skill level zero to skill level maybe
seventy or eighty percent, which is basically like looking at
the renders where they occur inspecting components with props change
or components change. I use React scan for for React
deb tools, I use the profiler component so like it
shows like a timeline of like what functions ran. I
also use the Chrome dev tools profiler, and then sometimes
(47:45):
I use the componentry provided within React obt tools. Like obviously,
if React debt tools works for you, you should use it.
I recommend giving reactscan a try. If it works better
for certain use cases, you should use it for use case.
If it doesn't, then then don't.
Speaker 1 (47:59):
One more thing that you might try to do, assuming
it's not too complicated or doesn't have too high over
it in and of itself, is that if the user
hovers on top of one of those tooltips then that
you render on the canvas, then you can could display
additional information like what caused the latest surrender or stuff
(48:21):
like that, things that wouldn't fit inside the tooltip of itself. Again,
anything that can save me the need to have to
open Chrome dev tools and go back in history would
be very beneficial. Obviously a problem with hovering is that
it doesn't actually work on mobile devices, or maybe a
(48:41):
click on those you know, tapping on the tooltip or
something along these lines that could be that could be useful. Again,
especially because on mobile devices, accessing DEPV tools becomes a
lot more challenging. So anything you can show on the
mobile display itself is very ben official.
Speaker 2 (49:01):
That's an amazing idea. Yeah, perfect, I'm just getting this
is like a user interview.
Speaker 1 (49:08):
Well, you know, performance is my jam, so you know
I've been doing this for a long time, longer I
wouldn't say longer than you've been alive, but starting to
come on that. So, yeah, anything else you want to
tell us about your tools or things that you're looking
at doing, or things that you want the listeners to
(49:30):
know about.
Speaker 2 (49:32):
Yeah, I mean, if there's one thing you should listen
do is performance matters a lot, like probably more than
you expect. And even if it I mean, like even
if it doesn't matter your company, like people leadership doesn't
really care, you should try at least see if it
maybe will improve some metric for users or improve your sales.
(49:53):
If you're just an individual user, try learning how performance works,
upskill yourself performance. Like my experience, there are not that
many performance experts, and there's a lot of need for
performance experts, and so from a job opportunity perspective, there's
also there's an opportunity there, So learned performance har we
(50:17):
x scan if you want to. And yeah, in this context.
Speaker 1 (50:23):
By the way, there's the actual excellent web dot dev
website which is actually run by the Google Chrome DevRel
team I think, and they have a section there called
case studies Case Studies on Web dot Dev, which basically
is just this huge list of case studies of companies
(50:47):
that improve their performance and got a huge boost to
their sales or bottom line or whatever as a result.
So if your company doesn't care about performance and you
need to convince management that performance is actually important, then
web dot dev Slash case studies is a great resource
to use in this context. And I totally agree with
(51:10):
you that having good performance is a game changer in
many cases. It's the whole difference between an application that's
pleasant to use, that's engaging, versus one that you hate
using because it's janky and unresponsive.
Speaker 2 (51:29):
For sure.
Speaker 1 (51:29):
Yeah, and it's also an accessibility thing, and it's about
enabling people who might otherwise not be able to use
your application to actually use it and benefit from it.
Because again, like you said, if your application was written
(51:50):
by people with really high end devices fast max fast iPhones,
and they never bother to check on lower end device
is or they just don't care about performance because it's
good enough on their own devices, they not may not
be aware that people on lower end devices just found
find their application wholly unusable.
Speaker 2 (52:12):
Yeah, exactly. And you'd be surprised the amount of e
commerce companies where performance actually matters to sales that don't monitor,
monitor performance or care that much, and so what happens
is they are literally losing out on like seven to
eight figures sales every year.
Speaker 1 (52:30):
By the way, again speaking about React, we had Rick
Wickskomi from Google on our show or a few years back,
and he runs this great service. I don't know if
you're familiar with it. It's h it's a Chrome User Experience
Report or CRUs. Yes, uh. And they have this website
(52:50):
where you can actually see the performance graphs by technology.
So Google literally grabs performance in information from your browser
unless you opt out from your Chrome browser, and they
upload it into their database anonymously of course at least
so they say. And then they and there they run
(53:12):
all sorts of analyzes on it, including which technologies it uses.
And that makes it possible, for example, to see how
good REACT websites in general are in terms of performance.
So we mentioned the three co ed vitals. A A
site is considered to have good performance if it has
(53:35):
if it's good for all three cowed vitals. That means
that it's fast enough at the seventy fifth percentile for LCP,
for CLS, and for IMP for example, LCP needs to
be faster than two and a half seconds at the
seventy fifth percentile. As I recall, and it turns out
that if you look at React websites, can you guess
(54:00):
what percentage of React websites in the totality of all
React websites actually get good COVID vitals.
Speaker 2 (54:10):
If I were to guess, maybe like ten, No.
Speaker 1 (54:14):
You're being overly harsh. It turns out, well, it used
to be that way, but it turns out that the
browser makers have been doing a phenomenal job of improving
the performance of the platform itself. So even though React
websites in and of themselves may not have improved that much,
(54:35):
just because the browsers have been getting better and faster
and more sophisticated, then the React scores have gone up.
In fact, all websites scores have gone up amazing. So
if I look, so, we were at twenty percent on
React websites back in twenty twenty one. So in April
(55:01):
twenty twenty one we cross the twenty percent threshold. Now
React websites are forty one percent have good coed vitals.
That's phenomenal. That means that almost well fifty nine percent don't,
which is the majority of React websites, which is truly unfortunate.
(55:23):
By the way, if we compare to other technologies, WordPress
slightly ahead of React. So people building WordPress websites, they
are at forty three percent, so they are two percent
better than React. So you're thinking you're a hot shot
React developer, and I'm talking to our listeners, there's a
(55:44):
good chance that the WordPress website built by some web
designer has better performance than your sophisticated React website. And
if I'm looking at other technologies like you mentioned Shopify,
Shopify is at seventy six percent and wis for example,
is at sixty five percent. So seventy six percent of
(56:09):
all shops of all the Shopify websites have good coed
vitals and that's almost double React. That's pretty that's pretty
unfortunate from my perspective. Yeah, and hopefully with hopefully, with
tools like React scan, people can make their React websites
(56:33):
more like load faster, be more responsive, and generally be
more pleasant and more accessible to use. By the way,
have you also thought about doing things related to accessibility
in your application or you for now focusing only on performance?
Speaker 2 (56:51):
For now on performance, but that'd be a cool extension
if there if there is enough of a need for.
Speaker 1 (56:57):
That, I think there there should be. But you know,
it's your business. So if people want to try out
react scan, like you said, it's open source, it's free
to use, how can they go about it? And if
they want to try out your more sophisticated tools for
(57:17):
the c I c D pipeline, how should they go
about it?
Speaker 2 (57:21):
Yeah, you can just got to react scan dot com.
Let's react scan dot com or just look up react
scan and google there there's research. It tells you how
to install the basic react scan and we have another
page called monitoring, which should be on the website. You
can click on and then try the demo and then
add your website yourself. It should. React scan takes lesson
(57:41):
a minute to set up. Our minoring service takes also
probably less than five minutes.
Speaker 1 (57:49):
Is it also possible to add it to a page
using NPM or is it just via script tag?
Speaker 2 (57:55):
NPM script tag you can run to be your cl I.
There's there's like four ways to do it.
Speaker 1 (58:01):
Anything else that you want to mention and talk about
in this context, not at all.
Speaker 2 (58:07):
I'm just really really grateful to be a on this
podcast and good to talk to you again, Dan.
Speaker 1 (58:12):
Yeah, same here. I love talking about performance and I
love seeing somebody so young, so into it and making
such an impact in this context. You know, bringing anything
we can do to improve the situation with React is
great in my book. I mean, at the very least
we need to be above fifty percent. I mean, at
(58:34):
the very least more than half React websites should have
good performance. By the way, what is also surprising to
me and even more unfortunate. Can you guess what the
situation is with next js?
Speaker 2 (58:49):
Is it lower than React?
Speaker 1 (58:52):
Surprisingly? It is. You would expect it to be higher
because it provides SSR and SSG, which are great for LCP,
but it isn't. I actually have a talk that I
give on this topic trying to kind of analyze why
that is. But the bottom line is that, as I said,
(59:13):
with React, it's forty one percent of React websites. Our
websites using React would be a better way of phrasing
it have good core vitals. With NEXTGS it's only twenty
eight percent.
Speaker 2 (59:27):
Yeah, I'll be curious why. That's interesting.
Speaker 1 (59:29):
Yeah, I'll be curious why as well. I'm guessing part
of it is maybe having to do with the long
tail of old NEXTGS versions, maybe not installed on VERSELL,
maybe installed on AWS and not properly optimized. But it's
a good but it's a good question of why that is.
And like I said, I have several theories and I've
(59:52):
even given talks on this topic. So if you're running
a conference and you want to hear my opinion about
why some frameworks are faster than others, then invite me
to speak at your conference. Anyway, Okay, I think with that,
I'll be pushing us to that final part of our episode,
(01:00:15):
which is the picks part. I didn't give your heads
up for it. I hope that you can't prepare. Nonetheless,
I'll go first, so you have time to choose. Basically,
picks is where we shout out whatever. It can be
technical things, it can be non technical things. It can
be your favorite movie, TV show, band, whatever book you
(01:00:41):
still read books and and you know, or technical things
that you want to just you know, shout out about,
including your own. So I'll start with mine. I don't
have a lot in the way of picks. I have
just one. So I'm from Israel, from television Israel, obviously,
(01:01:07):
the situation here has been really unfortunate over the past year,
the over a year, almost a year and a half,
with the war going on and a lot of suffering
and loss of life. At least we got some really
great news as yesterdays of the time of this recording,
(01:01:28):
where a cease fire has gone into effect, and in particular,
three Israeli hostages were released. They were held in captivity
by Hamas for four hundred and seventy one days. Just
imagine being held in a tunnel underground with the threat
(01:01:51):
of death constantly hovering over your head, with hardly any
food and no ability to move. And some of them
were all so victims of abuse, even sexual abuse. It's
very distressing. So three of the hostages were released yesterday
as part of this agreement between Israel and Hamas. Their
(01:02:14):
names are Doron Steinbacher, Emily Damari and I should have
come better prepared and Romy gone. Two of them were
actually abducted from their own homes. So on October seventh,
(01:02:35):
twenty twenty three Hamas terrorists broke into their home kidnapped
them literally out of their beds. One of them was shot,
she lost some fingers in her hand, and they were
taken into Gaza and literally in their pajamas. The third
one was kidnapped from the Nova Music festival. Again. She
(01:02:58):
was also shot wounded and they never got medical attention
for that. And I'm really happy that they've been finally
being released and reunited with their families. Hopefully they'll be
able to make a full recovery from this ordeal. Obviously
it's not simple, but and that still leaves ninety four
(01:03:23):
hostages Israeli hostages in Hamasa's hands. I really hope that
the ceasefire can persist and these hostages will be released
eventually as well, hopefully as soon as possible, And that
would be my pick for today. It really brought joy
to my heart yesterday when these hostages were finally released,
(01:03:45):
and that's my pick for today. Do you have any
picks for us? Aidan?
Speaker 2 (01:03:52):
I have one thing I am much less, much less important,
but yeah, I really, I mean I need this since Algol,
but I really like the proxy API and JavaScript. So
basically you can wrap any object in this like proxy keyword,
and then you can spy on any property. So if
(01:04:13):
you access like object dot name, you know when that
you can like programmatically know when that property is accessed.
Speaker 1 (01:04:20):
Oh yeah, proxy is really cool. Yeah. Basically, you take
you do a new proxy, and you pass in the
object you want to what to be the instrument or
track and like you said, any access to either reader
property from that object, write a property to that object
can be tracked, can also be modified, by the way,
(01:04:43):
so you can kind of it. The one thing to
be careful with, by the way, in this context is
that it can be used, and it was in fact
created for that purpose to kind of break JavaScript semantics
in a sense, because you can override the standard JavaScript
object behavior with proxy. I've actually done exactly what you described.
(01:05:06):
I had a problem in an application, a legacy application
that I was trying to refactor. Some code was modifying
a global object and I was unable to locate where
that modification was happening. So I literally created a proxy
around that global and put a debugger statement in the
(01:05:26):
property set, and that way, I when the brake happened
in the developer tools, I had the call stack and
I could find where that operation actually happened. That was
I felt like having a superpower when I was able
to do that. Yeah, proxies are very powerful, by the way.
(01:05:48):
In other use of proxies. I don't know if you
know this, but View I think uses proxies at least
in the development mode to implement their reactivity.
Speaker 2 (01:05:59):
Yeah, I think Vaultier and some other estate management too.
Or you can use it to like for if you
want to get fired. You can use it to prank
or coworkers.
Speaker 1 (01:06:12):
Okay, now you have to tell me what did you do?
Speaker 2 (01:06:15):
I haven't done it, but I was thinking of replacing
like like we have an internal library, like returning a
proxy and having all the properties return undefined or something. Yeah,
something super stupid.
Speaker 1 (01:06:29):
Yeah, okay, you know, well, boys will be boys or
depths will be depths, I guess. Yeah. Anyway, Aiden, it's
been really fun having you on the show. I'm really
excited about the stuff that you're doing. I'm really happy
whenever something comes along which makes it possible to improve
performance on the web. We definitely need more of that,
(01:06:53):
and it's it's amazing to see somebody so young making
such an impact. And I hope to be hearing more
great things from you and having you on the show
again to talk about more stuff that you're doing. Yep.
Now and now if people want to contact you about
you know your existing projects, more ideas for what can
(01:07:15):
be done and improved with these or maybe ideas for
future projects. What's the best way to reach out to you.
Speaker 2 (01:07:21):
I'm on Twitter, Blue Skuy YouTube. Just look at my
name and then you can just DM me and I'll
answer you.
Speaker 1 (01:07:27):
So it's aid and buy on all those platforms.
Speaker 2 (01:07:30):
Aiden, Why Bye?
Speaker 1 (01:07:31):
Yeah? Aiden? Whyby? Okay? Great? So again, Aiden, thank you
for coming on our show and to all our listeners,
thank you for joining us. And that's it for today. Bye,
Hello everybody, and welcome to another exciting episode of JavaScript Jabber. Today,
I'm all on my lonesome Dan Shapier coming to you
from Tel Aviv in Israel, and I'll be interviewing Aidan
by Hi. Aidan, Hi, how are you? I'm doing well overall?
How about yourself doing well?
Speaker 2 (00:27):
It's a not so hot, not too cold day in
San Francisco.
Speaker 1 (00:31):
So that's lovely. It's kind of same over here in
Tel Aviv, so please we're sharing good weather, and we
are here today to talk about React performance. But before
we start, Aidan, maybe you can tell us a little
bit about yourself and your very lengthy career in tech.
Speaker 2 (00:53):
Yeah. I gotta started hooting in middle school. But like
you might know me for a million, Jess, it's like
I tried to make a compiler for React and then
more recently React scan, which is all like the purple
flashing boxes on all these popular websites. I U see
it on Twitter. I've mainly mainly focused on performance most
(01:16):
of my life because I think it's an interesting problem.
Not many people focus on it, and it's also very hard.
Speaker 1 (01:23):
Yeah, tell me about it. It's been one of my
main focuses for the last couple of years. For those
of you don't know, I also happen to be an
invited expert on the W three C where Performance working Group.
Maybe you should join us there as well. We talk
about things not so much related to React, more about
the relevant web standards, things like core vitals and stuff
(01:46):
like that, and the APIs in the browser that can
be used to retrieve them, to measure them, et cetera.
I know that it's not our topic, but I do
want to talk a little bit about million js because
it seems so interesting. So so as I recall it,
it's kind of a drop in replacement for the mechanism
(02:07):
in React that transforms the virtual dome into the actual dome.
Is that a more or less correct description.
Speaker 2 (02:16):
Yeah, that's correct. Like basically how React works under the
hood is it takes like two versions of the view,
so like the old version and the new version, and
then it reconciles it, like it figures out the differences
between those and then it applied it to the actual dome.
But like this is like an an operation or some large,
big old notation that's over one. And the problem with
(02:41):
that is if when the versions get really big, like
the trees get really big, you're doing a lot of computation.
So I was like, okay, wouldn't be cool if you
could pre compile this, Like okay, based on the JSX
you provide. There's like obvious points where it actually changes,
like when you have those JSX container expressions, like the
(03:02):
when you passing some data in, So I pre compile
that and then found like the specific code paths that
matter to make the dom changes. So every time you
render a component, instead of doing that whole reconciliation process,
it just changes the dom like like pinpoint processes, basically.
Speaker 1 (03:21):
Kind of implementing fine grain reactivity in a sense over
on top of React.
Speaker 2 (03:27):
I guess, yeah, like benef it's a fine grain reactivity,
but without using fine grain reactivity.
Speaker 1 (03:33):
Yeah. I think you kind of mentioned several things that
are kind of important in the context of React performance
as you were describing this. I think that first and
foremost is this whole thing about virtual dom and the reconciliation.
We actually had a couple of chapters in JavaScript jabber
(03:56):
talking about the virtual dom, what it is, why it exists,
et cetera. But I still think it might be worthwhile
to talk a little bit about what it is because
it's so central to everything we'll be talking about today.
So can you tell us a little bit about you
the virtual dorm from your perspective.
Speaker 2 (04:14):
Yeah, virtual dom is basically it's kind of an overloaded term.
It's basically taking two like versions of the UI and
figuring out the princess between them and then actually changing
the UI. React doesn't actually hold the dom tree inside
of itself. I mean it kind of does, but like
(04:34):
when it does when it figures out what to change,
it doesn't actually store the dominodes as the whole tree
and then dip the dominance. It difts like a virtual
version of it. This can lead to some problems. So
for example, like for Facebook, it might be somewhat okay,
like when you were switching pages, but like if you
(04:54):
are creating like a stock trading app, like a stock
treating dashboard, where like there needs to be like updates
every several like some amount of milliseconds, or you're making
like significant dom mutations every single second, or if your
website targets it targets like very low end devices, then
(05:15):
that sort of mechanism can lead to some performance problems.
Speaker 1 (05:20):
I think the key aspect here is that React took
what I considered to be kind of an idealized approach
to UI generation, which is, let's in an ideal world,
I would say react. The React approach is, let's take
the entire application state and apply like a function to it,
(05:45):
a pure function even that generates the UI that the
user sees, and that every change in the state would
ideally again regenerate the entire UI. So you know, you
check or uncheck a small checkbox in the UI, and
(06:06):
theoretically the entire user interface of the application gets re
rendered because then you don't need to think about state
changes in the user interface. It's just everything again and
again from scratch. But the problem with this approach is
that a naive implementation would obviously be just way too slow.
(06:30):
It's kind of taking, by the way, the approach that
we had in the old days of the multipage applications
and kind of applying it to the client side rendering
mechanism that we have in JavaScript code that updates the
don in that in the old days you would go
to the back end and then you would get the
(06:51):
entire page back each and every time. So it's kind
of like doing that, but again but doing everything on
the client side and doing it for every state logical change.
And the virtual dom was like the first thing that
they implemented in order to make it viable the from
the perspective of performance, that is the virtual dom. By
(07:11):
the way, it's a fancy term, but really really all
it means is JavaScript objects. Really, that's all the virtual
dom is. So instead of having actual dom elements, which
are rather heavy because of all the functionality that they encapsulate,
you just use JavaScript objects simple JavaScript objects as stand ins.
(07:34):
And like you said, when the state changes and the
new virtual dom is created, React then takes the new
virtual dome the old virtual dome, does a comparison, finds
the differences, and then calculates the minimal amount of actual
dom changes to transition from the first state to the
(07:55):
second state. And that's the reconciliation process. And for a
long time it was thought that it was that approach
was good enough in terms of performance. But like you said,
when user interfaces started becoming more complex, complicated or more complex,
and as we needed to support lower end devices like
(08:18):
more mobile devices for example, and as we needed more
frequent updates, even this type of optimization started to break
down because doing all this reconciliation work still has overhead,
and this is when million js, I guess came in
(08:38):
to start to try to reduce that. But like you said,
being able to be smart about pinpointing the exact locations
of the differences and not having to do the entire
comparison of the entire virtual dom tree, right, yeah, exactly.
Speaker 2 (08:55):
I view like virginal dom is more of in historical context,
like it's more of getting things correct. Like before people
use like Backbone or they roll their own JavaScript libraries
and this would literally results in like like there were
literally so many frameworks like bugs and these frameworks. Virtial
dom is like a very exhaustive approach to the problem.
(09:17):
But it's more likely to get things correct than that.
Speaker 1 (09:21):
Yeah, because when you're essentially building the entire UI from
scratch from the current state, you don't have to worry
about an incorrect UI transition or state transition messing up
your display. I think, uh, Facebook had they had this
story about one of the motivations for creating React in
(09:43):
the first place, is that they had a counter in
their user interface about the number of messages that you
had pending or something like that. And any change to
that mechanism was always buggy because they always had to
somehow sync with everything else that was changing on the page,
(10:04):
and because so many things were changing more or less
concurrently in the UI, all of them as synchronous to
each other, they would always get into age cases and
age situations. And being able to just re render the
entire UI from scratch virtually solve that problem very neatly.
(10:26):
But again, so we had a couple of performance issues.
One performance issue is the one that you addressed with
the mini and JS, which is the fact that even
that sophisticated reconciliation could be too slow, especially if the
virtual dome was really large, especially if the device was
(10:47):
low end, and especially if you did it very frequently.
The other problem, I think is that even building the
virtual dome, which is mostly just running your code that
generates the JAX from the state, can be heavy and
performance intensive if done too often, or if if it's
(11:12):
just too complicated. And I think that this is where
reacts can comes in, because it's that's your new project,
the one that we're going to talk about, because it
strives to, if I understand, correctly, minimize the amount of
redundant helps you help you to minimize the amount of
redundant rerenders that you perform. Correct.
Speaker 2 (11:36):
Yeah, exactly. I can give a brief introduct. Basically, react
scan is a tool that helps you find like re
rendering performance problems and you react ap today. You can
just drop it in your app as a script tag
and it basically highlights the components that render and potentially
slow down your app. I spent like maybe three years
(11:57):
optimizing websites, everything from like webar you see, like virtual
camera websites to e commerce websites. There's like static sites,
and when I try to debug these performance problems on
these sites, it's really hard. Like it's either like I
do console that time and time end, or I use
Lighthouse scores, which is like at skill level zero to
(12:19):
profiling tools and Chrum dept tools. React to have tools
at like skill level one hundred, and so there's like
nothing in between those those two types of tools. And
this made me really frustrate, right, I Like I spent
so long just trying to understand how these level one
hundred tools work that that I realized that most people
don't have the time or ability to figure it out
(12:44):
exactly so react Skain helps bridge the gap. Today we
do renders, but soon we'll support more stuff. More stuff
in that like I n p cls LCP which are
like the lighthouse Google Lighthouse scores, as well as stuff
like lung tasks. F he has all of this, like
(13:04):
metrics and stuff that take They are decently like, not
like decently hard like recently not easy to measure correctly
and interpret.
Speaker 1 (13:15):
Basically, so you threw out a bunch of metrics and then,
as I mentioned, metrics are near and dear to my heart.
They're part of what I do on the W three
C Web Performance Working Group, which I'm an invited expert on.
I think the three main ones referred to as unsurprisingly
(13:39):
as core web vitals because they are the core ones.
We talked about them on the show on several occasions.
I think we even had specific episodes dedicated to them.
But still again, it might be worthwhile to mention what
they are and what they measured. Do you want to
do that or should I?
Speaker 2 (13:57):
I can explain like ten seconds like I'm he is
basically interacting in a page and getting the result back visually.
LCP is basically the largest like content fil basically any
elements with text or some big text in it. In
it is the like however, time it loads and then
(14:17):
CLS is basically how much your page layout shifts. You
want your IMP to be as low as possible, you
want your LCP to be low as possible, and CLS
to be low as well.
Speaker 1 (14:29):
Yeah, exactly. And it's interesting because there they are not
trivial in the context of React especially. Yeah, and it's
interesting because different facets of React address different these different metrics. So,
for example, if we're talking about the largest content for paint,
(14:51):
which like you said, is the amount of time from
when the page starts loading until the largest piece of
content is actually rendered on the browser screen, if we
think about what React does to try to optimize it.
So initially React, for those who who may not recall,
was just client side rendered, and that kind of guarantees
(15:12):
slow LCP by definition, because nothing is shown until all
the JavaScript is downloaded, including React, and then the client
side javascripts need to do the ajax calls to get
the data and then render the UI based on the
data and the code, and only then do you actually
(15:33):
see anything on the screen. So that's when React introduced
service side rendering, or SSR and static side generation or
SSG with meta frameworks like next JS or remix. So
(15:53):
it's by the way, it's interesting in this context that
still many organizations that I ounter don't really care that
much about LCP in the context of React applications, because
a lot of the web applications that are built using
React are things like dashboard or internal enterprise applications, and
(16:16):
there the approach is that it's loaded once and then
used all day long, and therefore the loading time is
less important. I actually think that in many cases this
is a misguided view because, for example, let's say you're
commuting to work on a train. You want to use
(16:36):
that time you're connecting via VPN into your internal network,
you're loading your internal application, and it takes your entire
train ride to actually load, which isn't fun. But be
that as it may. So that's LCP. There's the IP
which you mentioned, which is how responsive the pages to
(16:59):
interac actions, how long it takes the page from when
you actually click on a button to actually render the
result of clicking on that button. And again, React can
be really problematic there because if it's doing very lengthy
rendering operations or re rendering operations and you click in
(17:22):
the middle of one of these operations, then it won't
actually respond or do anything until all that JavaScript finish
is running. And CLS, I think, is the one that
is least directly related to React itself, because it's more
it has more to do I think with how you
(17:42):
start your CSS stuff like that. I would say though,
that for people who are using what's it called React suspense,
they need to watch out for CLS because if they're
(18:02):
loading code doesn't match the size of the actual finally
rendered component, then things will shift after the after the
load the loader is done, So so you do need
to watch out for that if you're using suspense in
the context of React, I think would you agree with that? Yeah?
Speaker 2 (18:23):
Also for images, right.
Speaker 1 (18:25):
Yeah, but images are there, you know that's a universal
issue that's not reacts butific Yeah, so million js kind
of addressed I guess both LCP because you were running
the rendering code faster, and also it kind of addressed
(18:47):
I n P because it blocks the rendering time for
a shorter period of time. What I understand that you're
addressing with reacts scan is most about figuring out how
to do less rendering and also generally make the rendering
(19:08):
itself faster, which again will would primarily benefit I n P.
I guess.
Speaker 2 (19:16):
I see it as like rendering is always somehow related
to some performance problem on the page if you use
it reacts site like I'll give a couple examples, like
for example with with with CLS, right, it could be
a styling issue, but as a user, I want to
know like where that specific uh specific like layout ship
(19:42):
is occurring with i MP. I want to click a
button and I want and there's like maybe a bunch
of renders. I don't know why it's slow. A rendering
is somehow always somehow related to that, even LCP, as
you said, right, like like if there's a lot of
rendering on the page that doesn't need to render, like
maybe below the folder outside the viewpoort, then it's not good, right,
(20:05):
even like other performance issues like when FPS drops or
like I'm trying to think of other examples, but like
whenever the page feels sluggish, it's always rendering is always
somehow related to the problem.
Speaker 1 (20:19):
So FPS, can you elaborate on what that is?
Speaker 2 (20:22):
FPS is frames per second? Basically this is important for
movement or animation tasks, so like when you scroll the
page or something is animating like rainbow gradient. For some reason,
that FS is important. You want to usually keep it
over sixty fps.
Speaker 1 (20:42):
It is the standard. And again JavaScript gets in the
way because the main thread, well the browser is kind
of not exactly but mostly single threaded, so whenever you're
running JavaScript, it kind of blocks everything. And if you're
blocking everything too much, then you get jank or jitter
(21:02):
because you're not able, like you said, to hit that
sixty fps. I totally agree with what you said about
identifying things that render needlessly. My own experience is that
a lot of React teams don't even ever get there. Basically,
when they see that something that the UI renders correctly,
(21:26):
that's good enough for them, and they don't care about
the fact that it's rendering correctly over and over and
over again, effectively doing a lot of work at the
virtual dome level without actually ever updating the actual dome,
because the reconciliation basically notices that they're just recreating the
(21:47):
exact same virtual dome over and over again. But even that,
even though it's cheaper than updating the dome, still you know,
accumulates if you concer doing that you're literally just running
an infinite loop of JavaScript that's doing nothing. Is that
has that been also your experience that it happens in
(22:08):
a lot of organizations and a lot of websites.
Speaker 2 (22:11):
Yeah, that's definitely one of the problems. It's also I
don't think it's necessarily engineer's fault, right, it's really hard
to care about these things because they're not visible. Just
like if the page UI is not correct, it's very visible.
You have to fix it. If there's an error, you
have to fix it, right, It's not like you can
avoid these things. The performance you can really easily avoid
because most developers use like a really high end MacBook
(22:34):
or high end PC where you can like any performance
problem you can blaze through and like basically hit with
no problem. And also developers are so used to slow
build tools and slow like development startups that like one
hundred three or real seconds it feels like nothing. So
the problem is performance is not visible, and developers are
really out of touch in touch with users for performance,
(23:00):
like even even if even for like performance experts who
like think about performance every day, they're also not super
in tune with like the actual products performance Like maybe
they go to data Dog and they see the metrics
and they're like, okay, how can I improve this today?
Or they see a regression in performance after a specific
git commit, But then it's like, okay, what do I do?
(23:22):
Like how do I reproduce this? It's kind of hard
to do those things. Reacts again is our attempt to
try to fix some of this, right, Like how how
do we make performance visible? Like how can we show
developers that there's problems on the side without like having
them loaded up on a Moto G four or something.
Speaker 1 (23:42):
Moto G four, by the way, for those of you
are too young to know, is an old Motorola phone
that Google still uses virtually for simulating performance of websites
on low end devices. If you're using Lighthouse, that's what
they there. Okay, then so you want to visualize the
(24:06):
performance issues, how do you go about it? What do
you actually show? How do I see that I have
a performance issue in my React website? By the way,
the tool is for React, right It's not you know,
for websites that aren't React based.
Speaker 2 (24:21):
Correct, Yeah, React for now? Right now? We highlight renders
and if there is some sort of long task or
FPS drop or imp that's really high. We turn the
color of the renders to like from purple to like
red or something. In the future, we wanted to have
more visualizations, like when I click a button, what is
the IMP or like the local tested imp we have
(24:46):
like or like what is the like long animation frame?
Like when a long animation frame happens. I want to
see that the long animation frame happens. I want to understand,
like when jink happens, or when jink happens, what is
the cause of that. Jink renders is like our base
abstraction basically, like usually it's always related to It's like
always somewhere within the problem, and so we show it
(25:11):
via renders basically.
Speaker 1 (25:13):
So basically, if I understand correctly, you're adding rectangles around
the React components that get rendered. And these components and
these borders kind of highlight whenever the component renders. So
if it's constantly highlighted, you know that this component is
(25:36):
for some reason being constantly re rendered. Right and and
by the way, again, re rendering is at the virtual
dome level, so even a component might be re rendered
even if nothing actually is changed for it in the
actual browser dom. Correct, yes, yes, So it's it's your
(25:58):
code and React code doing work for that component, whether
or not anything actually gets updated in the actual display. Yep.
And usually the border would have one color what is it,
Like you said, purple or something like that. But if
it's resulting, if it's causing the browser itself to actually
(26:23):
experience delays, then it will actually change color and become red.
Speaker 2 (26:28):
Exactly.
Speaker 1 (26:28):
Yeah, very cool. So I assume you've tested it on
various websites and saw them flashing rectangles all over the place.
It gives like interesting examples.
Speaker 2 (26:43):
A month ago, I founded this performance problem on the
GitHub site when you would scroll on the code every
line of coder Revender. So I tweeted it, got a
lot of likes, a lot of views, and then I
don't remember their name, but someone from the VP of
the roll GitHub was like, hey, one day later, hey,
we fixed this issue. When I tested it, the fs increased.
(27:05):
Now it was like, holy crap, like's it was really cool.
How just this random package we made and then just
tweeting it out and just showing a video of it
actually made a real performance change on the site.
Speaker 1 (27:18):
Yeah, yeah, that's really cool. And my experience is that
it's exactly that that it's very difficult to notice that
the problems exist, especially like you said, when developers have
really high end max and stuff like that. But once
(27:39):
you understand where the problem is in a lot of cases,
not all cases, but in a lot of cases, the
fix is fairly straightforward. You've got let's say, some use
effect that's updating a state, which is retriggering the use effect,
which is again updating the state and over and over
and over again in this kind of an infinite rendering loop,
(28:02):
something along these lines. Yeah.
Speaker 2 (28:04):
Yeah, the main hard part of performance isn't the solution.
The solution space is actually really small. It's usually like
one to five solutions for every problem, But finding the
problem is the hard part. It's almost ninety nine percent
of the work.
Speaker 1 (28:25):
Yeah, I totally, I totally agree with that. By the way,
I'm just there are a whole bunch of sirens in
the background, so I apologize for being a bit distracted. Yeah,
that totally matches my own experience that it's sometimes that
being able to pinpoint the cause of a performance issue
(28:45):
is the hardest problem. But you know what, in that regard,
it's not that different from a lot of bugs. You know,
the famous Heisen bugs that happen occasionally are very difficult
to reproduce and figure out, and then you know, you
smack your head when you realize what the problem is
because the fix is often very very straightforward. My question
(29:10):
then is how were you able to get this information
out of React? I mean, you know, React doesn't exactly
tell you that, hey, you've got a performance issue. It
just does this whole rerendering thing kind of automatically behind
your back. So how did you figure this out?
Speaker 2 (29:30):
Yeah? Most simply so, React dept Tools has information about
componentry and renders. Well how does it do this? Well,
React internally has it attaches like a property on the
window object called React depth tools Global hook, and it
has much of information about the fiber tree, and so
(29:51):
reacts can internally uses that to get information about fibers
just for context. A fiber is basically like the virtual
do on how React internally represents the user interface. We
can use the fibers to detect renders, and then we
show those renders using a canvas on the screen.
Speaker 1 (30:12):
So base, ah, you're using You're not modifying the CSS,
You're actually using canvas in order to draw the stuff
on the screen.
Speaker 2 (30:22):
Yes, if we modify the CSS, there would be like
some overhead on that, so any performance score you would
see is going to be noticeably like it's going to
be artificially inflated. So what we did was we put
the canvas on a worker thread, so it doesn't have
as much performance impact as if you actually modify the CSS.
Speaker 1 (30:42):
Ah cool, So what you're saying is you kind of
put an invisible canvas on top of the entire rendered screen.
I guess, and you're and canvas can be updated from
a worker thread off of the main thread, which is
(31:03):
not something you can do with the regular browser dome.
So you're able to draw into this wholly separate user
interface GPU layer without impacting the rendering time of the
actual browser at all. That's very very cool.
Speaker 2 (31:27):
There's a little bit overhead because we have to still
send the data over to the worker thread, but from
our testing it's pretty minimal. It doesn't affect like the
standard metrics as much.
Speaker 1 (31:40):
I understand, but for example, you still need to for example,
get the rectangle the actual rectangles on the display of
the dome elements, and if they there scroll, you kind
of need to move the rectangle along with them. Or
something or things along that line. Correct, So that does
(32:03):
still take a little bit of overhead in terms of
work on the main thread. But basically you're just firing
that throwing that over into that worker and it does
the heavy lifting exactly. Yeah, have you measured the impact
the performance impact that having reacts can on the site
(32:24):
actually has, because that's that's indeed a real problem that
you know, it's kind of like quantum physics, where you're
measuring things can actually impact the behavior of the application.
Like I recently saw a tweet about somebody saying that
he had a bug in there in his code. He
(32:44):
added the log, the bug went away, he removed the log,
the bug came back. So sometimes even the act of
measuring can really impact the performance and behavior of the
of an application. So how how did you actually verify
that you have hardly any impact on the run time
of the application itself?
Speaker 2 (33:06):
Measuring here, Like it's like not really a good way
to figure out the overhead. Like, basically we run on dev,
which means they're using development builds, which is not the
same as a production build. So development bills will likely
be slower than production builds on a basic app. It's around,
it's like less than one percent. At more heavy apps
(33:28):
still less than one percent. But like in reality, we
like you can you have to like measure on like
a large scale applications and actually on the correct build
of the app to understand the overhead. Right now, it
doesn't matter too much, but like as I said, like
it maybe for some edge case it might be much
more question.
Speaker 1 (33:53):
As you said, you're using the same APIs that React
dev tools uses internally, in fact, by the way undocumented APIs.
As I understand, what is the advantage then of using
React scan over just using the React's own developer tools
(34:16):
for essentially the same purpose because they also have a
performance view in there. If you install the Chrome extension
for the React Developer tools, for example, you get a
performance tab, a React performance tab in the developer tools.
So what's the advantage of using a React scan over
that capability that React provides themselves out of the box.
Speaker 2 (34:41):
Yeah, Like I view React Depth tools as like the
endgame of debt tools. Like it's it's a great version.
There's obviously improvements that can be made, but it's like
the best React depth tools React.
Speaker 1 (34:54):
Right.
Speaker 2 (34:56):
The problem is, like you need kind of like a there,
there's there's like a very low like you have to
be decently skilled at using React deaf tools or crumb
debt tools in order to use those depth tools, and
most people don't really know how to do it. React
scin is a more accessible version of it, specifically for
(35:16):
rendering and performance app performance issues inside your React app.
React deptols is more general, more advanced depth tools for
interacting with your app. Uh yeah, I use React and
React depth tools. Uh for my use case.
Speaker 1 (35:36):
Oh okay, cool. So when I used React scan is
it Does it even require the depv tools to be open?
Or do I just see everything on the browsers display.
Speaker 2 (35:48):
Itself undevelopment in development, you just drop a script tag
into your like head tags and then it should.
Speaker 1 (35:55):
Work and you don't need to open depth tools at all.
Speaker 2 (35:58):
No, no, yeah, you just have it. It just runs
you know where.
Speaker 1 (36:02):
That's potentially a very significant advantage on mobile devices. The
fact that I can just drop in a script tag
and see the issues on the browser screen itself is
a big advantage in terms of identifying such issues versus
(36:25):
having to attach the phone a physical phone via a
physical wire to a mac or PC in order to
open a remote debugger and then debug everything that way.
It's a much more convoluted process. If I can just
see all the problems directly on my mobile screen, that's
(36:45):
a huge advantage from my perspective.
Speaker 2 (36:48):
Yeah, that seems like a really good use case.
Speaker 1 (36:51):
Now do you only show the squares with the colors
or do you sew additional information there?
Speaker 2 (36:58):
So induce us shows some additional information on the screen itself.
So each rectangle will have a little label on it
showing the component name and also how many times renders
and how much time it took. You can also there's
like a in browser toolbar. You can inspect any component
or render to see when it renders. You can replay them.
(37:19):
You can see what props change, what state changed, where
context changed, and you can just figure out exactly what
are the props or attributes or information about the React
component that are causing the problematic performance.
Speaker 1 (37:33):
Wow, that's really really cool. By the way, when I
drop in that script tag, does it automatically enable this
you AI, or do I also need to do something
in the browser itself to enable it, Because I'm thinking
that in some cases people will want to have that
(37:57):
script tag be present, you know, all the way is
but not have all the users seeing those rectangles.
Speaker 2 (38:05):
Yeah, by default it only runs in developments. We do
offer like programmatic off and on APIs. So like companies
like Notion or Shopify, what they do is they are sorry, yeah,
Shopify Notion, they have an internal to bar and basically
you can click like turn React scan on and it
(38:25):
turns the and opens the React skan overlay and two bar.
Speaker 1 (38:30):
What you might want to do as well is maybe
add the support for a special URL parameter m HM,
so that you could turn it on or off using
a URL parameter that you know doesn't hopefully doesn't conflict
with anybody's URL parameter, but that would make it especially easy,
(38:52):
especially on mobile. I thinking that that would be very useful.
We did similar things at Wix where we added special
debugging capabilities into Wix websites, but they were only enabled
with a very specialized, well not document not externally documented
(39:13):
URL parameter, obviously nothing that could actually break a website.
You know, you need to be careful because their potential
security issues around that. You know, somebody could send the
link with that URL parameter to somebody and then they
would see the red lines and then they would get
(39:33):
all freaked out because they would think something is wrong
or something along these lines. But in general, I think
that this can be a useful feature.
Speaker 2 (39:45):
Yeah, that's awesome.
Speaker 1 (39:46):
Right after this podcast, I'm glad that I can help
make the product better. I also saw various demos that
you were showing about all sorts of ways to graph
the component hierarchies in the React application. Is that also
part of the same thing.
Speaker 2 (40:06):
We haven't shipped that, but we're just playing around with
what visualizations would work. So, like for context, I was
working in this really large enterprise e commerce app and
they had a bunch of components depending on the same context.
But it was really commolluted, right because they were like
nested hooks. There was nested components, Like a bunch of
(40:26):
stuff was re rendering. I didn't know why. So I
spent like ten hours just on tl draw graphing out
the entire code base from the route that.
Speaker 1 (40:36):
Was re rendering.
Speaker 2 (40:38):
And I was like, why the why the heck am
I doing this? Like like this is like so much
work just to figure out why all these components are rendering.
One thing we want to do this, dude, try is
doing this automatically? Like, can we graph out the component
tree and also the hooks tree and show where the
source of the problem is most like re rendering issues,
(40:59):
like they can be caused by a higher component or
a context, but usually they're systemic, right, Like, it's usually
like one context causing all these components to rerender, and
all these components have faulty implementations that cause this performance issue.
So we're trying it. We're trying some visualizations to help exces.
Speaker 1 (41:19):
So we have a user from LinkedIn to asked, what
is the business model for the react scan project? Is
there a cost to using react scan? I'll fill in
the blank. Is it open source? Is it free? What's
what's your business model around this tool? Are is it
already released? Is it beta? Where are we at?
Speaker 2 (41:40):
Yes, it's it's not one point oh, but you can
it's stable, you can try in your app. It's free,
open source, you can copy the code, you can fork it,
you can do anything with it. If your company requires
it's a host on our internal package. You can do
whatever you want. The way we make money is through
monitoring and observability. So we have a different product that
uses is React scan on in like et or staging environments,
(42:06):
so you can run your playwright test. We figure out
the performance scores of these playwright test and tell you
whether the performance increase or decreased. This is a This
is a real problem because like most observability tools like
Century data DOT, they're really confusing, right, you have to
like read profiles, the graphs are somewhat like we'd like,
(42:27):
and it doesn't really tell me like what is the
root cause of the problem. We're trying to solve this.
We're trying to do this specifically solve this for React.
Speaker 1 (42:34):
So it's it's essentially a performance budget tool for React applications.
Speaker 2 (42:40):
Yeah, exactly.
Speaker 1 (42:41):
By the way, for again, performance budget is something that
we mentioned in previous episodes for those of you don't
remember or don't know what it is. A performance budget
is a way to say, like, specify how much how
performance I expect my application to be, and then during
the testing process in your CICD flow, you can measure
(43:07):
the performance of the latest build, compare it to your
budget limits, and if you exceed your budget limits, you
essentially break the build like you would for any other bug.
And then the only way in which you can release
it is either fix the performance issue that you're under
budget again, or unfortunately, in some cases, you might need
(43:31):
to increase the budget because maybe you just made the
UI more complicated and sophisticated, and therefore it's a legitimate
decision to make. But you're doing it with full awareness
of what you're changing. It's not just something that happens
and you're not even aware that it's going on, that
your application is becoming slower. So you're building a performance
(43:53):
budgeting tool that's focused on React application. It's not just
working at the co word vital is level. It's focused
on React and it helps you understand how you React
application is actually working in terms of performance, and if
you exceed your budget, not only does it break your build,
but it also tells you where the problem is likely act.
Speaker 2 (44:17):
We do also do quero vital So basically, the data
hierarchy is interactions. So if interaction becomes slower or your
playwright test that's a problem, then we go a little
bit deeper out like if an interaction is slow, what
components may have caused that? Or what components underwhere may
have caused that? And then potentially like down to the render,
(44:38):
like what props, context or state may have changed.
Speaker 1 (44:43):
Now, what I'm thinking that might be really useful in
this context is something although off the top, I'm not
exactly it's more of a vague idea that I have
rather than a plan. But you know, one way in
which REACT performance is improved in at least in perceived performance,
(45:04):
if not actual performance, is using suspense by deferring rendering
of certain non urgent UI components. Maybe they are maybe
they're outside the visual display area, or maybe they show
lower important information or stuff like that. How do you
(45:31):
handle those? Can you recommend to me that this thing
should be should use suspense or stuff like that? Is
that something that you're thinking about or looking at?
Speaker 2 (45:41):
Yeah, of course that's all on scope basically.
Speaker 1 (45:46):
Cool, and so any like hints about what you're thinking
about doing in this.
Speaker 2 (45:54):
Context specifically, For so, there's a couple applications like things
outside the viewport well and it if it renders, we
mark that as like an unnecessary render. M hmm, like there,
I mean, like obviously there are different solutions here, like first,
maybe don't render it, or maybe there are some like
(46:14):
hacky solutions for like partial hydration, like don't hydrate unless
it's viewed, or like suspense as you're saying, we don't
do recommendations yet, but we do detect the problems itself
right now.
Speaker 1 (46:29):
Okay, So when you're doing when you're doing the that
rectangle highlight, if the rectangle is wholly outside the visual
the visual viewport, then it gets kind of flagged and
logged that, hey, this was an unnecessary render. You should
(46:50):
be doing something about avoiding avoiding.
Speaker 2 (46:52):
That exactly, Yeah.
Speaker 1 (46:55):
Or postponing that or so something along these lines. That's
very very nice. So you said that you're using both
React scan together with uh the with the React dev tools.
What where do you focus? What information do you get where?
(47:19):
Like what's the benefit of using them both together? Yeah?
Speaker 2 (47:22):
Anywhere from like skill level zero to skill level maybe
seventy or eighty percent, which is basically like looking at
the renders where they occur inspecting components with props change
or components change. I use React scan for for React
deb tools, I use the profiler component so like it
shows like a timeline of like what functions ran. I
also use the Chrome dev tools profiler, and then sometimes
(47:45):
I use the componentry provided within React obt tools. Like obviously,
if React debt tools works for you, you should use it.
I recommend giving reactscan a try. If it works better
for certain use cases, you should use it for use case.
If it doesn't, then then don't.
Speaker 1 (47:59):
One more thing that you might try to do, assuming
it's not too complicated or doesn't have too high over
it in and of itself, is that if the user
hovers on top of one of those tooltips then that
you render on the canvas, then you can could display
additional information like what caused the latest surrender or stuff
(48:21):
like that, things that wouldn't fit inside the tooltip of itself. Again,
anything that can save me the need to have to
open Chrome dev tools and go back in history would
be very beneficial. Obviously a problem with hovering is that
it doesn't actually work on mobile devices, or maybe a
(48:41):
click on those you know, tapping on the tooltip or
something along these lines that could be that could be useful. Again,
especially because on mobile devices, accessing DEPV tools becomes a
lot more challenging. So anything you can show on the
mobile display itself is very ben official.
Speaker 2 (49:01):
That's an amazing idea. Yeah, perfect, I'm just getting this
is like a user interview.
Speaker 1 (49:08):
Well, you know, performance is my jam, so you know
I've been doing this for a long time, longer I
wouldn't say longer than you've been alive, but starting to
come on that. So, yeah, anything else you want to
tell us about your tools or things that you're looking
at doing, or things that you want the listeners to
(49:30):
know about.
Speaker 2 (49:32):
Yeah, I mean, if there's one thing you should listen
do is performance matters a lot, like probably more than
you expect. And even if it I mean, like even
if it doesn't matter your company, like people leadership doesn't
really care, you should try at least see if it
maybe will improve some metric for users or improve your sales.
(49:53):
If you're just an individual user, try learning how performance works,
upskill yourself performance. Like my experience, there are not that
many performance experts, and there's a lot of need for
performance experts, and so from a job opportunity perspective, there's
also there's an opportunity there, So learned performance har we
(50:17):
x scan if you want to. And yeah, in this context.
Speaker 1 (50:23):
By the way, there's the actual excellent web dot dev
website which is actually run by the Google Chrome DevRel
team I think, and they have a section there called
case studies Case Studies on Web dot Dev, which basically
is just this huge list of case studies of companies
(50:47):
that improve their performance and got a huge boost to
their sales or bottom line or whatever as a result.
So if your company doesn't care about performance and you
need to convince management that performance is actually important, then
web dot dev Slash case studies is a great resource
to use in this context. And I totally agree with
(51:10):
you that having good performance is a game changer in
many cases. It's the whole difference between an application that's
pleasant to use, that's engaging, versus one that you hate
using because it's janky and unresponsive.
Speaker 2 (51:29):
For sure.
Speaker 1 (51:29):
Yeah, and it's also an accessibility thing, and it's about
enabling people who might otherwise not be able to use
your application to actually use it and benefit from it.
Because again, like you said, if your application was written
(51:50):
by people with really high end devices fast max fast iPhones,
and they never bother to check on lower end device
is or they just don't care about performance because it's
good enough on their own devices, they not may not
be aware that people on lower end devices just found
find their application wholly unusable.
Speaker 2 (52:12):
Yeah, exactly. And you'd be surprised the amount of e
commerce companies where performance actually matters to sales that don't monitor,
monitor performance or care that much, and so what happens
is they are literally losing out on like seven to
eight figures sales every year.
Speaker 1 (52:30):
By the way, again speaking about React, we had Rick
Wickskomi from Google on our show or a few years back,
and he runs this great service. I don't know if
you're familiar with it. It's h it's a Chrome User Experience
Report or CRUs. Yes, uh. And they have this website
(52:50):
where you can actually see the performance graphs by technology.
So Google literally grabs performance in information from your browser
unless you opt out from your Chrome browser, and they
upload it into their database anonymously of course at least
so they say. And then they and there they run
(53:12):
all sorts of analyzes on it, including which technologies it uses.
And that makes it possible, for example, to see how
good REACT websites in general are in terms of performance.
So we mentioned the three co ed vitals. A A
site is considered to have good performance if it has
(53:35):
if it's good for all three cowed vitals. That means
that it's fast enough at the seventy fifth percentile for LCP,
for CLS, and for IMP for example, LCP needs to
be faster than two and a half seconds at the
seventy fifth percentile. As I recall, and it turns out
that if you look at React websites, can you guess
(54:00):
what percentage of React websites in the totality of all
React websites actually get good COVID vitals.
Speaker 2 (54:10):
If I were to guess, maybe like ten, No.
Speaker 1 (54:14):
You're being overly harsh. It turns out, well, it used
to be that way, but it turns out that the
browser makers have been doing a phenomenal job of improving
the performance of the platform itself. So even though React
websites in and of themselves may not have improved that much,
(54:35):
just because the browsers have been getting better and faster
and more sophisticated, then the React scores have gone up.
In fact, all websites scores have gone up amazing. So
if I look, so, we were at twenty percent on
React websites back in twenty twenty one. So in April
(55:01):
twenty twenty one we cross the twenty percent threshold. Now
React websites are forty one percent have good coed vitals.
That's phenomenal. That means that almost well fifty nine percent don't,
which is the majority of React websites, which is truly unfortunate.
(55:23):
By the way, if we compare to other technologies, WordPress
slightly ahead of React. So people building WordPress websites, they
are at forty three percent, so they are two percent
better than React. So you're thinking you're a hot shot
React developer, and I'm talking to our listeners, there's a
(55:44):
good chance that the WordPress website built by some web
designer has better performance than your sophisticated React website. And
if I'm looking at other technologies like you mentioned Shopify,
Shopify is at seventy six percent and wis for example,
is at sixty five percent. So seventy six percent of
(56:09):
all shops of all the Shopify websites have good coed
vitals and that's almost double React. That's pretty that's pretty
unfortunate from my perspective. Yeah, and hopefully with hopefully, with
tools like React scan, people can make their React websites
(56:33):
more like load faster, be more responsive, and generally be
more pleasant and more accessible to use. By the way,
have you also thought about doing things related to accessibility
in your application or you for now focusing only on performance?
Speaker 2 (56:51):
For now on performance, but that'd be a cool extension
if there if there is enough of a need for.
Speaker 1 (56:57):
That, I think there there should be. But you know,
it's your business. So if people want to try out
react scan, like you said, it's open source, it's free
to use, how can they go about it? And if
they want to try out your more sophisticated tools for
(57:17):
the c I c D pipeline, how should they go
about it?
Speaker 2 (57:21):
Yeah, you can just got to react scan dot com.
Let's react scan dot com or just look up react
scan and google there there's research. It tells you how
to install the basic react scan and we have another
page called monitoring, which should be on the website. You
can click on and then try the demo and then
add your website yourself. It should. React scan takes lesson
(57:41):
a minute to set up. Our minoring service takes also
probably less than five minutes.
Speaker 1 (57:49):
Is it also possible to add it to a page
using NPM or is it just via script tag?
Speaker 2 (57:55):
NPM script tag you can run to be your cl I.
There's there's like four ways to do it.
Speaker 1 (58:01):
Anything else that you want to mention and talk about
in this context, not at all.
Speaker 2 (58:07):
I'm just really really grateful to be a on this
podcast and good to talk to you again, Dan.
Speaker 1 (58:12):
Yeah, same here. I love talking about performance and I
love seeing somebody so young, so into it and making
such an impact in this context. You know, bringing anything
we can do to improve the situation with React is
great in my book. I mean, at the very least
we need to be above fifty percent. I mean, at
(58:34):
the very least more than half React websites should have
good performance. By the way, what is also surprising to
me and even more unfortunate. Can you guess what the
situation is with next js?
Speaker 2 (58:49):
Is it lower than React?
Speaker 1 (58:52):
Surprisingly? It is. You would expect it to be higher
because it provides SSR and SSG, which are great for LCP,
but it isn't. I actually have a talk that I
give on this topic trying to kind of analyze why
that is. But the bottom line is that, as I said,
(59:13):
with React, it's forty one percent of React websites. Our
websites using React would be a better way of phrasing
it have good core vitals. With NEXTGS it's only twenty
eight percent.
Speaker 2 (59:27):
Yeah, I'll be curious why. That's interesting.
Speaker 1 (59:29):
Yeah, I'll be curious why as well. I'm guessing part
of it is maybe having to do with the long
tail of old NEXTGS versions, maybe not installed on VERSELL,
maybe installed on AWS and not properly optimized. But it's
a good but it's a good question of why that is.
And like I said, I have several theories and I've
(59:52):
even given talks on this topic. So if you're running
a conference and you want to hear my opinion about
why some frameworks are faster than others, then invite me
to speak at your conference. Anyway, Okay, I think with that,
I'll be pushing us to that final part of our episode,
(01:00:15):
which is the picks part. I didn't give your heads
up for it. I hope that you can't prepare. Nonetheless,
I'll go first, so you have time to choose. Basically,
picks is where we shout out whatever. It can be
technical things, it can be non technical things. It can
be your favorite movie, TV show, band, whatever book you
(01:00:41):
still read books and and you know, or technical things
that you want to just you know, shout out about,
including your own. So I'll start with mine. I don't
have a lot in the way of picks. I have
just one. So I'm from Israel, from television Israel, obviously,
(01:01:07):
the situation here has been really unfortunate over the past year,
the over a year, almost a year and a half,
with the war going on and a lot of suffering
and loss of life. At least we got some really
great news as yesterdays of the time of this recording,
(01:01:28):
where a cease fire has gone into effect, and in particular,
three Israeli hostages were released. They were held in captivity
by Hamas for four hundred and seventy one days. Just
imagine being held in a tunnel underground with the threat
(01:01:51):
of death constantly hovering over your head, with hardly any
food and no ability to move. And some of them
were all so victims of abuse, even sexual abuse. It's
very distressing. So three of the hostages were released yesterday
as part of this agreement between Israel and Hamas. Their
(01:02:14):
names are Doron Steinbacher, Emily Damari and I should have
come better prepared and Romy gone. Two of them were
actually abducted from their own homes. So on October seventh,
(01:02:35):
twenty twenty three Hamas terrorists broke into their home kidnapped
them literally out of their beds. One of them was shot,
she lost some fingers in her hand, and they were
taken into Gaza and literally in their pajamas. The third
one was kidnapped from the Nova Music festival. Again. She
(01:02:58):
was also shot wounded and they never got medical attention
for that. And I'm really happy that they've been finally
being released and reunited with their families. Hopefully they'll be
able to make a full recovery from this ordeal. Obviously
it's not simple, but and that still leaves ninety four
(01:03:23):
hostages Israeli hostages in Hamasa's hands. I really hope that
the ceasefire can persist and these hostages will be released
eventually as well, hopefully as soon as possible, And that
would be my pick for today. It really brought joy
to my heart yesterday when these hostages were finally released,
(01:03:45):
and that's my pick for today. Do you have any
picks for us? Aidan?
Speaker 2 (01:03:52):
I have one thing I am much less, much less important,
but yeah, I really, I mean I need this since Algol,
but I really like the proxy API and JavaScript. So
basically you can wrap any object in this like proxy keyword,
and then you can spy on any property. So if
(01:04:13):
you access like object dot name, you know when that
you can like programmatically know when that property is accessed.
Speaker 1 (01:04:20):
Oh yeah, proxy is really cool. Yeah. Basically, you take
you do a new proxy, and you pass in the
object you want to what to be the instrument or
track and like you said, any access to either reader
property from that object, write a property to that object
can be tracked, can also be modified, by the way,
(01:04:43):
so you can kind of it. The one thing to
be careful with, by the way, in this context is
that it can be used, and it was in fact
created for that purpose to kind of break JavaScript semantics
in a sense, because you can override the standard JavaScript
object behavior with proxy. I've actually done exactly what you described.
(01:05:06):
I had a problem in an application, a legacy application
that I was trying to refactor. Some code was modifying
a global object and I was unable to locate where
that modification was happening. So I literally created a proxy
around that global and put a debugger statement in the
(01:05:26):
property set, and that way, I when the brake happened
in the developer tools, I had the call stack and
I could find where that operation actually happened. That was
I felt like having a superpower when I was able
to do that. Yeah, proxies are very powerful, by the way.
(01:05:48):
In other use of proxies. I don't know if you
know this, but View I think uses proxies at least
in the development mode to implement their reactivity.
Speaker 2 (01:05:59):
Yeah, I think Vaultier and some other estate management too.
Or you can use it to like for if you
want to get fired. You can use it to prank
or coworkers.
Speaker 1 (01:06:12):
Okay, now you have to tell me what did you do?
Speaker 2 (01:06:15):
I haven't done it, but I was thinking of replacing
like like we have an internal library, like returning a
proxy and having all the properties return undefined or something. Yeah,
something super stupid.
Speaker 1 (01:06:29):
Yeah, okay, you know, well, boys will be boys or
depths will be depths, I guess. Yeah. Anyway, Aiden, it's
been really fun having you on the show. I'm really
excited about the stuff that you're doing. I'm really happy
whenever something comes along which makes it possible to improve
performance on the web. We definitely need more of that,
(01:06:53):
and it's it's amazing to see somebody so young making
such an impact. And I hope to be hearing more
great things from you and having you on the show
again to talk about more stuff that you're doing. Yep.
Now and now if people want to contact you about
you know your existing projects, more ideas for what can
(01:07:15):
be done and improved with these or maybe ideas for
future projects. What's the best way to reach out to you.
Speaker 2 (01:07:21):
I'm on Twitter, Blue Skuy YouTube. Just look at my
name and then you can just DM me and I'll
answer you.
Speaker 1 (01:07:27):
So it's aid and buy on all those platforms.
Speaker 2 (01:07:30):
Aiden, Why Bye?
Speaker 1 (01:07:31):
Yeah? Aiden? Whyby? Okay? Great? So again, Aiden, thank you
for coming on our show and to all our listeners,
thank you for joining us. And that's it for today. Bye,
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Law & Order: Criminal Justice System - Season 1 & Season 2
Season Two Out Now! Law & Order: Criminal Justice System tells the real stories behind the landmark cases that have shaped how the most dangerous and influential criminals in America are prosecuted. In its second season, the series tackles the threat of terrorism in the United States. From the rise of extremist political groups in the 60s to domestic lone wolves in the modern day, we explore how organizations like the FBI and Joint Terrorism Take Force have evolved to fight back against a multitude of terrorist threats.