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