Vue user here. Why does react recalculate basically ⅘ of the page there? Especially on scroll? What state is altered during scrolling? Is the code not properly optimized or is this a limitation of the current implementation of the react framework?
@@ascpixII its not the cycles in that szenario that bothers the performance, its the latency and iops that are limited, per timeframe which will make it feel clunky and slow ^^
When you have 20+ tabs open and several programs running. You'll notice. And it's really annoying when a poorly optimzed website slows down your other important processes because someone thought you won't notice.
What's really annoying is when you have a framework that is foundationally a bad design choice that has taken over the world. The "diff virtual DOM" model was fine when we had pages with 200 DOM nodes. With pages now composed of thousands of DOM nodes, it simply doesn't scale. Which, if that was the only algorithm that existed, fine, but there are multiple signals-based frameworks that simply don't exhibit this problem.
@@MrTact67 but that's not a problem anymore Shitty code is just made by shitty developers regardless of the framework. We have good examples of highly optmized react code, and also we do have examples for shitty html+vanilla js code too. Frameworks are just tools, not football teams which you cheer of like a fan.
@MarcosMion2010 The most optimized React code is still going to be less efficient than vanilla JS using event hooks and AJAX callbacks. Most websites (including GitHub) don't need it.
@MarcosMion2010 Shitty code can be encouraged by the shitty design of a shitty framework/library/language. You can't dumb down the problem to "lol skill issue" when the tools involved are full of footguns.
Amusingly enough, that reminds me of the old days of Flash and AS3. For the most part, Flash renderer worked fine, but movement of an element (DisplayObject) resulted on the rerendering of all its content. So if you suddenly had to move a big complex object (like scrolling through a very populated scene), it would result in a lot of extra rendering and would impact performance. The AS3 solution to that was a little property called "cacheAsBitmap" which would result in the element keeping its rendered result in cache and not rerendering unless something happened inside it. Of course, you couldn't use it on everything, or it would keep an untold amount of image data in cache; but that was a great way to improve performances if you knew how to use it.
"99% of people, rerendering is fine" - I don't agree either. Even though I don't know the impact, but just his attitude seems like he's reckless about resources used by a process. It all takes energy, and the more reckless people are, the more we get into behaviors where it really hurts. I'm no fanatic, but I like it when I can use my laptop for 8h without charging. I almost can't do it anymore, and that's not because my battery capacity has degraded!
It is awful. Most people will know something is wrong. The tech illiterate might not be able to point out what is wrong, but the jitter would be noticeable to everyone and to people that are used to high refresh rates, etc, then it is immediately noticeable.
for a random pages that get like 100 vists a month it's fine but for something bigger it's a terrible take rerendering when a user interacts is not "fine"
I work exclusively on a very powerful desktop, underutilized so I always have performance to spare. There is never a time where I notice a website acting slowly. Even still, I hate this. Just because I have power to spare doesn't mean it's free to use. I doubt a more efficient website will make a tangible difference to my electricity bill but across the entire globe? That's likely a non-negligible amount of power wasted on re rendering poorly optimised react components.
I remember theo not liking svelte because the compiler was "too much magic", but now as always, when its something that he uses that adopts things that he supposedly doesn't like he immediately likes it
If you have a large existing codebase, anything which helps the toolset you already have is a blessing. Even if it’s not the toolset you would use on a new “green field” project.
Totally agree. All these dev influencers stay in their confort zone using React to sell more videos, tutorials and gain likes. How many money is costing all this over use of React for the tech companies globally?
@@SilvestreVivo You should think "how much money is react making them" instead of "how much money is react costing", people usually don't just use technologies that don't benefit them in some way.
That’s why going from Vue to React feels like you’re walking back in time. You have to tell it dependencies (yuk), you end up with pairs of get/set functions instead of smart property interceptors that track and optimise the rendering. In Vue you can alter a state variable and if this only affects a grandchild component then only that component gets rerendered. Vue compiler just works and is standard - nothing to turn on. No need for memos or useState.
Vue is catching up to Svelte and SolidJS faster than React is, but "catching up" is the key words there. At what point does it just become a worse version of frameworks designed with a compiler in mind, struggling to maintain backwards compatibility with a completely different paradigm?
because fundamentally react is just a bad implementation of declarative reactivity. overall it's too hard and the abstraction is leaking (hence the need for a compiler). chaotic mess of apis that need to be orchestrated like kubernetes just not to render x100times per second
It’s always been slow. But Facebook doesn’t care about wasting people’s time; their primary metric is time-on-site! They don’t want things to be fast/efficient.
If Facebook didn't care then the React devs wouldn't have spent a long time working on the compiler, which mostly fixes this issue (mentioned about half way through the video).
I really like what the React Compiler team are doing. I've long preferred Vue over React because there are far fewer easy mistakes to make, and that not only helps junior devs, but everyone working with and reviewing the code. React Compiler should be able to close some of that gap, and make the easy thing to write also the correct thing to write in far more circumstances. Big thumbs up from me.
I think it's also worth noting the concept of moving state "down", which is often not talked about since everyone recommends hoisting state up. If state changing in a component causes it and all children to re-render, then you can also architect your code in a way where only the things that are related are included in that. For example, in the provided example, a new component could be created for each of these sections and their related state and it will only cause that component to re-render, and if they needed to share state, you can also group those components into a component, instead of having a single parent with many states that are shared. Moving the state down also tends to make the code easier to follow, because components become inherently smaller, with less shared state, less code and less complexity overall. Obviously this will not be required with the compiler, and you may still need to memoize some functions or objects, but understanding this and writing "good" code that naturally reduces re-renders without memoization is always a plus. And it's always worth remembering that memoization is not free, you still need to do comparisons on dependency arrays, or props which is not "free". Love the video as always, and look forward to the day that I can open up a 500 file github diff and it's actually useable 😉
In this example you can move the counter state to the component, but the color picker state still needs to be in the parent there's no "architecturing" around that
@@Ked_gaming You actually can "architect" around the issue. The key is not to use useState in the parent, because updating state with the provided setter will cause all child components to rerender, even if they don’t depend on the state. Instead, you can use a "signal" (a value holder with the ability to notify listeners about changes). Store this signal in the parent using useRef to avoid re-renders. Then, pass the signal to child components via props or context. Each child can subscribe to the signal and manage its internal state using useState. This way, the state technically resides in the parent, but only interested children rerender when the signal updates. Libraries like Redux, Jotai, and Recoil implement similar mechanisms that all leverage this pattern in some way.
i am not a web dev and i don't like to write javascript, BUT every time i have had to write a web site because a web dev was taking too long with react and/or next.js and/or some other massively complex framework, I have been able to write it easily with SIMPLE static files and SIMPLE javascript that reads and writes json from a SIMPLE rest API. Hiding and displaying elements seems to do 90%-100% of the fancy ui stuff that people need those massively complex frameworks for. i realize i must be missing some major piece of web-dev ability, but whatever that ability is, i don't seem to ever need it.
I can see where server-side rendering could be quite a bit more efficient in some circumstances -- e.g. the UI varies quite a bit depending on the user's chosen components, and those components vary quite a bit based on a chosen theme. But even then, seems like all these fancy server-side frameworks are just re-inventing PHP.
i used to HATE writing PHP; it was so kludgey. But I have to admit it is probably 10x less complex and 10x faster than the server-side frameworks i have had the misfortune of getting close to. And I understand PHP is far more principled now than it was back in the day. As much as i disliked PHP, i would RUN to it after seeing web devs struggle with next.js and similar. That stuff seems like witchcraft. Even when that sever-side javascript stuff works correctly, it is difficult to understand HOW it works; it is like voodoo.
"I just tricked you guys into watching a react video" you got me! Also memoization kinda feels like that South Park edpisode where Cartman finds a really great detergent that really cleans his underwear.
The weird thing about your example is that it would totally not even be an issue if it was just made with vanilla javascript... What IS the advantage of react? Aside from JSX which is kind of a neat idea...
the advantage is the "reactivity" (declarative vs imperative) - modern people are afraid of vanilla (like assembler), too much explicit code to write, to handle state manually, they like 80kB+ libraries to hide the stuff and allow them "cooool reactivity" - which is actually awesome concept, if you don't ever start to think about doing it with vdom.... but with signals
Vanilla codebases become unmaintainable quickly. React, and other frameworks, mitigate this, but aren't immune to stupidity. The common saying is that if you're not using a framework, then you're making one, and the problem with making one is that other people outside of your scope aren't able to learn it in their free time (if they are to be potential hires)
@@MrMudbill I still havent seen a react code base that was actually maintainable, infact react seems to be the fastest way to get in a pickle, so many things have changed since I started using react that its not even funny. I honestly dont think that "vanilla is unmaintainable" inherently, you can write beautiful code in most environments and with most constraints, but vanilla JS is missing a neat way to do DOM markup for templating and components like JSX, aside from that there is not much of added benefit... I dont really see the advantage of shadow DOM in like 99% of actual use cases, and where it matters you are probably much better off doing a diff yourself.
@ React has added a lot, yes, but you can still run really old React code. Many things change over time, but if they are still backwards compatible, it isn't really a big issue, if any at all. Plus, this applies to practically anything, including languages themselves like Java and PHP. Change is inevitable. Now, if the project is small enough, you can get away with vanilla JS. But if you have a project that would take several months of constant work to rewrite from scratch, you will likely struggle more with vanilla JS than a framework. I assume at such a size, there would be more than a single employee working on it. I don't really care about shadow DOM or virtual DOM or React itself really. What matters is that the codebase follows an understandable structure and standard that is easier to adopt for new employees.
Our codebase is full of memoized components now. I hate it because it introduces extra clicks when finding the definition of the component you want. But even worse are the random uses of useMemo and useCallbacks for the most trivial functions. Holy boiler plate. Most are so trivial they don't save any computation are are probably more expensive to do the dependency array check. The only justification I can think for some of it is that they're passed as props to other components which might use it in another dependency array which actually relies on the thing you pass being memoized. Edit: and now that I've watched your video, I now understand that using useCallback is necessary for the effort placed into memoizing the component to pay off.
This problem is really hard to mitigate in a virtualized table where every cell is re-rendered for every pixel scrolled. Especially if the cells are not plain text or easy to memoize components. Need to show a tooltip on hover? Bad luck - welcome to the rabbit-hole. I literally had to solve this problem in every grid/table that I've implement since 2017 to present day and the solutions always felt like workarounds and hacks. React should've solved this re-render issue first before any suspense/rsc stuff since the core job to be done that it's selling is "render" before anything else.
@@andrewxv8088 Also, in addition to the reactivity api, the Vue SFC templates are made to optimize (reduce) rerenderings (Which is not available when you use Vue with JSX or the h() function)
@@xtremescript I worked on Vue projects, that multiple re-renders were definitely a culprit in performance issues. I don't see how Vue magically fixes that. This was like a few years ago using Vue 2.7 with options API though. Not well-versed in Vue 3 to know if the reality is now different.
The problem with React is its documentation, those concepts are really simple to understand that should be the first thing you learn before you start writing react code
This is very informative. I was of the belief, also, that React doesn’t constantly scan for changes. Thanks for taking the time to clear misconceptions.
this is the price for "reactivity", modern world doesn't want to touch "assembler" (which is vanilla js) - but there are also great frontend frameworks, not using vdom diffing, but signals - seems like best of both worlds
@@frantisek_heca that's the thing. We don't have to get rid of React an use Vanilla, we just have to change the scope of the apps. React should be used for dynamic parts. Static things should be plain html + css. This btw, would let us build better microfrontends and then compose what makes sence later.
That's exactly what's its supposed to be used for. It just became popular to use it as an SPA. a static site with ineractive react components is obviously the best solution. People just like to argue and complain.
The only framework I actually have experience with is Svelte and it apparently just figures out everything that can be affected when you build to make it perform well. No idea about the others but it does work
@@alekseykostyuk3806 but react is all-in, either you have everything in vdom or not, conceptually it's built in that way, i don't see a point in refactoring react to not be like this if there are already awesome frameworks done that way
Around 4:05 you mention the checks between the current and new virtual DOMs, would you be willing to go into more detail about this? Do the checks take just as long as making the changes? I feel like I understand most of the video, but this small part feels like such a crucial aspect to the entire video and I feel like it was glossed over just a tad. I would love to hear/learn more about this process in an explicit way (I loved the graphic on the blogpost btw)
I'd like to clarify this question a bit - Whenever i watch other videos talking about reacts re-rendering, they all mention how if something changes, the component and its children are also re-rendered because they are now different from the currently virutal DOM, but the other components remain untouched. Am I understanding you correctly, that you are saying that even though the other components are UNTOUCHED, there is still an existing lag because they still have to be compared to the current DOM to see if any changes have been made, even when there are no changes?
@@MrMudbill devops often need to be concerned with the complaints of speed of operation; especially during a maintenance event. I did wear many hats during my decades of IT work.
good explanation. one of the main things devs gets wrong is that there are two stages of comparison and potential updates. one is between virtual dom's and other between real and virtual
You are a blessing man, thanks for the time earned by watching this 13 minutes video. I'm currently updating my knowledge about webdev and this channel helps me a lot. Keep up the good work ! Cheers
When i was making my few first ui tree systems purely for fun, with layout geometry generation process, i had a lot of concern on performance with thoughts like "damn, i have to walk my tree up to 3 times recursively to make sure i dont waste computational power and time of a cpu". Also an interesting recursive puzzle was how the algorithm decides what nodes to render and what not.. Damn, that kind of explains why github gist/blob pages take so long to load on 4.6GHz CPU
With the old react component you had full control if it should render using the shouldComponentUpdate method, the new function components didn't make it all that simpler.
I made a site with an openMaps map on it, I basically HAD to use memoization on all the map components otherwise performance sucked enough to visibly see. After memoization everything runs great. I'm sure it could be made even better but memoization isn't that bad and it REALLY helps when you need it.
Kitze is like the person that replied to me a few days ago saying taking up a large amount of disc space didn't matter because that way programmers aren't wasting their time optimizing unnecessarily.
@ He's not just a carping nobody, he speaks from real experience that, most of the time, people will get stuck in traps of making their app perfect and in the end never getting anything out. I resonate with him. Sure, it is better to have an optimized app than a non optimized app. But there's more nuance than that.
How do you get react scan working on these sites which you do not have direct access to? Meaning you clearly are visiting sites and able to test them. How do you set that up?
Regarding the VDOM / DOM diff performance problems ... 1. Part of the reason "we don't talk about this" is because there's always someone who pipes up and says "you don't need to worry about re-renders because React is really fast at the diff and it's designed to to work this way". I can see it already in some of the comments 😉 2. The myth that the diff is only done when the props change is perpetuated by the fact that **intuitively** that's the way people would expect it to work. Obviously this babel plugin makes it align with the expectation. But why doesn't it work that way by default ? There must be some gotchas otherwise it would work this way in the first place.
Goddamn, this "99% of people won't notice" is such a spoiled I-have-a-maxed-out-MBP-and-don't-care dev comment. Imagine older Androids, older hardware in general, heat, other applications running, etc… and this kind of carelessness is definitely noticeable. Matter of fact, I have cut down my YT time (the irony) because my MBP, which is getting 10 years old soon, can't handle it that well anymore. So more efficient site = more videos watched = more money.
I never switched to the "functional" React fad. Every single component I make is PureComponent per default, unless it needs to be otherwise. So it doesn't do that re-rendering every time.
genuine question because i am actually interested in the react compiler, can you talk about (or point to a video) talking about the costs or tradeoffs for memo-izing everything (even if it's done automagically by the react compiler)?
Do you guys prefer to memoize the child components and put all of the state at the parent components or simply put the state at the child components so that when it re-renders, it doesn't affect other components other than itself? What are the benefits of each approach?
I think it may be more accurate to say that react has a rerender learning curve problem. I’m intentionally not saying that it’s a skill issue because I don’t want to sound dismissive. React has done a great job of lowering the learning curve for getting started, but I think for handling rerenders properly, that learning curve may still be a bit steep for many people
you could just isolate the state for every component and not use memo at all. The rerendering problem here comes from keeping the state global for all three components
I could have made this a 15 second video. React is old tech. It had its heyday but newer tools have refined concepts and produce better code with better DX and less footguns. Anyone starting a new project today should not use React. Better tools exist that dont require you to think nearly as hard about how the underlying engine works. React is trying to shift hard to use these new concepts, but theres so much legacy out there its hard to do. Use a newer stack and be happy. Svelte 5 is an amazing experience. Ill never go back to React for a new project.
I still find a use to React.memo and useMemo which is in making inner components. When I create a component that I absolutely don't want to be used outside of a specific component, I create it inside the parent component and have it memoized there.
Angular is still slow as heck, and react is still a little better (with the compiler, WAY better, angular is still stuck with the old change detection mechanisms for most of its ecosystem currently). Most JS frameworks are trash at speed, with few exceptions like svelte or solid-js.
@@wlockuz4467 That’s why I asked. But I didn’t know if it is handled the same in the background. Perhaps the wrapper already ships with solutions shown in the video?
re render has always been a pain in the ass, even the first time i got into react as a mobile developer, it was the most disgusting thing to deal with even more than async rendering
I have a question on the compiler-perf-demo download. I've got it downloaded and unzipped locally, what is the correct setup to get it running? (I'm new to react and working in an established codebase, so it's harder to start from scratch.) I thought it would be: npm install react typescript vite then npm run dev but that gives me errors. I didn't see anything in the readme, but I'm newer to this stuff. Thank you,
why would you care lol unless he's ricing the browser or something otherwise it's just exporting bookmarks from one and importing on the other and you're off to the races
So, instead of fixing the root of the problem, which is react rerendering each child component on each parent state update, they make a compiler that adds hooks boilerplate for you. And if you think about it, each hook is at least one function call and one new function declaration on every render, which is not optimized at all, but is "fast enough". At this point, I think they should just use signals like every other framework and admit it's a better model.
Awesomesuace!!! You are a true BadA**, wow! I did not know that I would learn how to use the React compiler in this video (I watch all of them:-, but rarely comment) , but I am sooo stoked to try this out. Thanks dude...
My latest project i wanted to use the react compiler. I appreciate showing the config apparently my build was in react 18 so i had to go through and update and enabling the compiler. The link for the rerender i think will also be super helpful
github is pretty performant as an end user experience if they wasn't using virtualised lists it would have a much poorer user experience on large data sets.
1000+ files in a single folder in one of my repos kills performance for me. while virtualised lists in theory should help, for some reason it's still slow and a clunky experience.
I assume a framework like Svelte gets this by default, no? I'm not experienced enough to say that confidently so if anyone knows for certain I'd appreciate it.
On the one hand, I’ll keep this in mind if I have to maintain a React app. On the other hand, I don’t see myself wanting to change my plans from migrating from AngularJS to Vue. Every time I see React code it just seems…. like something Zuckerberg would make, and more convoluted than I would think necessary.
when is the browser video that was live on x dropping? im stuck at the same spot with the dying of arc browser and im not sure if i should go the safari or zen route
basically if u r not dumb u should use solid instead of react, if u are open to new syntax you can prefer svelte also but dont be a react dev if you want to be an engineer, performence is one of the important things to consider
The same people who complain that you have to put the bare minimum amount of effort into making a react app not run like crap are the same people who are making apps that lock up because everything is done on the render thread
Is "React Compiler" some new/optional project or is it just the normal transpiler that I always have to use to convert my .tsx files into JavaScript bundles?
I've played with react but ages ago so I'm no expert. But I've seen this videos before. Opting out of rerendering and opt-ion memoize seems like a bad thing and I wonder why this is still the case today...
creator of React Scan (rerender tool shown in the video) - happy to answer any performance questions y'all may have
Looks cool, can't wait to try it!
Subbed to your channel, thanks for creating this!
Vue user here.
Why does react recalculate basically ⅘ of the page there?
Especially on scroll? What state is altered during scrolling?
Is the code not properly optimized or is this a limitation of the current implementation of the react framework?
@@AidenBai can some of these tools be incorporated into CI to help identify changes that may introduce potential performance issues?
React Dev Tools already have that, am I right? In Components tab in DevTools there is a setting “Highlight updates when components render”
So it's not the AI, it's the React Compiler that's taking our jobs...
Nope. It's not our job to fix a $h*tty framework.
The compiler is ⚡powered⚡by ai
@@j.r.r.tolkien8724 our job is to use the framework correctly. Otherwise you are free to choose any other one but every choice has its downsides
AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI
Dude, that was actually pretty funny
Brother will make a hello world page that consumes 700mb RAM and 800 Hertz of your CPU and be like: 99% of computers can render this page its fine
800Hz (800 CPU cycles per second) is not that much that's about 0.000025% of a 3.2 GHz CPU's power 🤓☝☝
Average electron app developer.
a $3 ESP32 runs at 240Mhz ie 240.000.000Hz .. I guess you ment Mhz at the very least, since 99% of all calculators run in the Mhz range
99% of computers can
@@ascpixII its not the cycles in that szenario that bothers the performance, its the latency and iops that are limited, per timeframe which will make it feel clunky and slow ^^
It’s funny how reacts biggest problems is it self
yeah, sentenced by its own design, but so obvious if you delve into the world of different frameworks
bUt WhAt AbOuT tHe EcOsYsTeM?
@@hanes2 such cancer, and we're too deep in it to move on to something else
Makes me wonder, does other frontend framework have the same problem? Like vue or anythin else?
@@orchne9179No as no other framework choose to re-execute functions every time to rebuild the component structure. They just track state changes.
The response tweet in 2:00 just feels like the "we rely on Moore's law to cover our crappy code" mindset.
“That’s not only not good, it’s pretty bad” bro needs to memoize his vocab store
When you have 20+ tabs open and several programs running. You'll notice. And it's really annoying when a poorly optimzed website slows down your other important processes because someone thought you won't notice.
What's really annoying is when you have a framework that is foundationally a bad design choice that has taken over the world. The "diff virtual DOM" model was fine when we had pages with 200 DOM nodes. With pages now composed of thousands of DOM nodes, it simply doesn't scale. Which, if that was the only algorithm that existed, fine, but there are multiple signals-based frameworks that simply don't exhibit this problem.
20+ is an understatement ... I've like 300 😂
@@MrTact67 but that's not a problem anymore
Shitty code is just made by shitty developers regardless of the framework. We have good examples of highly optmized react code, and also we do have examples for shitty html+vanilla js code too.
Frameworks are just tools, not football teams which you cheer of like a fan.
@MarcosMion2010 The most optimized React code is still going to be less efficient than vanilla JS using event hooks and AJAX callbacks. Most websites (including GitHub) don't need it.
@MarcosMion2010 Shitty code can be encouraged by the shitty design of a shitty framework/library/language. You can't dumb down the problem to "lol skill issue" when the tools involved are full of footguns.
The sad part is that at 6:30 the component is still lagging behind the mouse and that is what we consider snappy and acceptable nowadays.
Amusingly enough, that reminds me of the old days of Flash and AS3. For the most part, Flash renderer worked fine, but movement of an element (DisplayObject) resulted on the rerendering of all its content. So if you suddenly had to move a big complex object (like scrolling through a very populated scene), it would result in a lot of extra rendering and would impact performance. The AS3 solution to that was a little property called "cacheAsBitmap" which would result in the element keeping its rendered result in cache and not rerendering unless something happened inside it. Of course, you couldn't use it on everything, or it would keep an untold amount of image data in cache; but that was a great way to improve performances if you knew how to use it.
these ~10-15 mins videos are much better
dude, squawk off. Longer videos are much better too.
up
Agreed.
Yes 10000%
"99% of people, rerendering is fine" - I don't agree either. Even though I don't know the impact, but just his attitude seems like he's reckless about resources used by a process. It all takes energy, and the more reckless people are, the more we get into behaviors where it really hurts.
I'm no fanatic, but I like it when I can use my laptop for 8h without charging. I almost can't do it anymore, and that's not because my battery capacity has degraded!
It is awful. Most people will know something is wrong. The tech illiterate might not be able to point out what is wrong, but the jitter would be noticeable to everyone and to people that are used to high refresh rates, etc, then it is immediately noticeable.
for a random pages that get like 100 vists a month it's fine but for something bigger it's a terrible take rerendering when a user interacts is not "fine"
Yeah it's exactly this attitude that is turning 2GHz CPU Laptops into e-waste
I work exclusively on a very powerful desktop, underutilized so I always have performance to spare. There is never a time where I notice a website acting slowly. Even still, I hate this. Just because I have power to spare doesn't mean it's free to use. I doubt a more efficient website will make a tangible difference to my electricity bill but across the entire globe? That's likely a non-negligible amount of power wasted on re rendering poorly optimised react components.
I develop with a $150 laptop for this reason. Helps me sympathize.
I remember theo not liking svelte because the compiler was "too much magic", but now as always, when its something that he uses that adopts things that he supposedly doesn't like he immediately likes it
If you have a large existing codebase, anything which helps the toolset you already have is a blessing. Even if it’s not the toolset you would use on a new “green field” project.
Totally agree. All these dev influencers stay in their confort zone using React to sell more videos, tutorials and gain likes. How many money is costing all this over use of React for the tech companies globally?
@@SilvestreVivo
You should think "how much money is react making them" instead of "how much money is react costing", people usually don't just use technologies that don't benefit them in some way.
That’s why going from Vue to React feels like you’re walking back in time. You have to tell it dependencies (yuk), you end up with pairs of get/set functions instead of smart property interceptors that track and optimise the rendering. In Vue you can alter a state variable and if this only affects a grandchild component then only that component gets rerendered. Vue compiler just works and is standard - nothing to turn on. No need for memos or useState.
So, now we have React compiler 🎉
💯--and going from react to vue is *liberating*
The “reactive” (proxy) edit buffer objects in Vue seem to streamline this template/DOM update process substantially.
Not a popular opinion but vue is better than react in 90% cases. It's painful every time when I need to jump from vue to react.
Vue is catching up to Svelte and SolidJS faster than React is, but "catching up" is the key words there. At what point does it just become a worse version of frameworks designed with a compiler in mind, struggling to maintain backwards compatibility with a completely different paradigm?
"99% of users won't notice" until you look at a PR that's more than a few lines long
How many users that use use react look at PRs? I would argue that its pretty close to 99%.
I always get stuck at this and just leave my machine alone and come back later
because fundamentally react is just a bad implementation of declarative reactivity. overall it's too hard and the abstraction is leaking (hence the need for a compiler). chaotic mess of apis that need to be orchestrated like kubernetes just not to render x100times per second
exactly!
It’s always been slow. But Facebook doesn’t care about wasting people’s time; their primary metric is time-on-site! They don’t want things to be fast/efficient.
They absolutely do, slowness of any kind is a killer for retention. They're just bad at engineering.
If Facebook didn't care then the React devs wouldn't have spent a long time working on the compiler, which mostly fixes this issue (mentioned about half way through the video).
I really like what the React Compiler team are doing.
I've long preferred Vue over React because there are far fewer easy mistakes to make, and that not only helps junior devs, but everyone working with and reviewing the code.
React Compiler should be able to close some of that gap, and make the easy thing to write also the correct thing to write in far more circumstances. Big thumbs up from me.
Missed opportunity to run it on Facebook and Instagram, two sites that probably use most amount of React.
I think it's also worth noting the concept of moving state "down", which is often not talked about since everyone recommends hoisting state up. If state changing in a component causes it and all children to re-render, then you can also architect your code in a way where only the things that are related are included in that.
For example, in the provided example, a new component could be created for each of these sections and their related state and it will only cause that component to re-render, and if they needed to share state, you can also group those components into a component, instead of having a single parent with many states that are shared.
Moving the state down also tends to make the code easier to follow, because components become inherently smaller, with less shared state, less code and less complexity overall.
Obviously this will not be required with the compiler, and you may still need to memoize some functions or objects, but understanding this and writing "good" code that naturally reduces re-renders without memoization is always a plus. And it's always worth remembering that memoization is not free, you still need to do comparisons on dependency arrays, or props which is not "free".
Love the video as always, and look forward to the day that I can open up a 500 file github diff and it's actually useable 😉
In this example you can move the counter state to the component, but the color picker state still needs to be in the parent there's no "architecturing" around that
Or just don't nest components 100 levels deep.
or just dont use react
@@Ked_gaming You actually can "architect" around the issue. The key is not to use useState in the parent, because updating state with the provided setter will cause all child components to rerender, even if they don’t depend on the state.
Instead, you can use a "signal" (a value holder with the ability to notify listeners about changes). Store this signal in the parent using useRef to avoid re-renders. Then, pass the signal to child components via props or context. Each child can subscribe to the signal and manage its internal state using useState. This way, the state technically resides in the parent, but only interested children rerender when the signal updates.
Libraries like Redux, Jotai, and Recoil implement similar mechanisms that all leverage this pattern in some way.
@@janku3368 If you're going through all that length to not use the react compiler or memoization you're better off using vuejs
i am not a web dev and i don't like to write javascript, BUT every time i have had to write a web site because a web dev was taking too long with react and/or next.js and/or some other massively complex framework, I have been able to write it easily with SIMPLE static files and SIMPLE javascript that reads and writes json from a SIMPLE rest API. Hiding and displaying elements seems to do 90%-100% of the fancy ui stuff that people need those massively complex frameworks for. i realize i must be missing some major piece of web-dev ability, but whatever that ability is, i don't seem to ever need it.
No, there is nothing you can't do without React, but somehow a lot of people have been convinced that it is difficult to develop without a framework.
I can see where server-side rendering could be quite a bit more efficient in some circumstances -- e.g. the UI varies quite a bit depending on the user's chosen components, and those components vary quite a bit based on a chosen theme. But even then, seems like all these fancy server-side frameworks are just re-inventing PHP.
i used to HATE writing PHP; it was so kludgey. But I have to admit it is probably 10x less complex and 10x faster than the server-side frameworks i have had the misfortune of getting close to. And I understand PHP is far more principled now than it was back in the day. As much as i disliked PHP, i would RUN to it after seeing web devs struggle with next.js and similar. That stuff seems like witchcraft. Even when that sever-side javascript stuff works correctly, it is difficult to understand HOW it works; it is like voodoo.
2:06 "won't notice anyting..." Except when the page crashes on your old phone and you can't do anything. (iPhone SE 1st gen)
"I just tricked you guys into watching a react video" you got me! Also memoization kinda feels like that South Park edpisode where Cartman finds a really great detergent that really cleans his underwear.
Chipotl-away
It's mobile sites where you see this, especially if you're browsing sites on an iPad from a generation or two ago, they really don't scroll nice.
We've spend quite some time with React Scan making sure Drizzle Studio is 120fps all around
big thanks for the outstanding tool
The weird thing about your example is that it would totally not even be an issue if it was just made with vanilla javascript... What IS the advantage of react? Aside from JSX which is kind of a neat idea...
the advantage is the "reactivity" (declarative vs imperative) - modern people are afraid of vanilla (like assembler), too much explicit code to write, to handle state manually, they like 80kB+ libraries to hide the stuff and allow them "cooool reactivity" - which is actually awesome concept, if you don't ever start to think about doing it with vdom.... but with signals
There's no advantage, it's a bandaid for the web not offering native forward rendering pipelines.
Vanilla codebases become unmaintainable quickly. React, and other frameworks, mitigate this, but aren't immune to stupidity. The common saying is that if you're not using a framework, then you're making one, and the problem with making one is that other people outside of your scope aren't able to learn it in their free time (if they are to be potential hires)
@@MrMudbill I still havent seen a react code base that was actually maintainable, infact react seems to be the fastest way to get in a pickle, so many things have changed since I started using react that its not even funny. I honestly dont think that "vanilla is unmaintainable" inherently, you can write beautiful code in most environments and with most constraints, but vanilla JS is missing a neat way to do DOM markup for templating and components like JSX, aside from that there is not much of added benefit... I dont really see the advantage of shadow DOM in like 99% of actual use cases, and where it matters you are probably much better off doing a diff yourself.
@ React has added a lot, yes, but you can still run really old React code. Many things change over time, but if they are still backwards compatible, it isn't really a big issue, if any at all. Plus, this applies to practically anything, including languages themselves like Java and PHP. Change is inevitable.
Now, if the project is small enough, you can get away with vanilla JS. But if you have a project that would take several months of constant work to rewrite from scratch, you will likely struggle more with vanilla JS than a framework. I assume at such a size, there would be more than a single employee working on it.
I don't really care about shadow DOM or virtual DOM or React itself really. What matters is that the codebase follows an understandable structure and standard that is easier to adopt for new employees.
these
Our codebase is full of memoized components now. I hate it because it introduces extra clicks when finding the definition of the component you want. But even worse are the random uses of useMemo and useCallbacks for the most trivial functions. Holy boiler plate. Most are so trivial they don't save any computation are are probably more expensive to do the dependency array check. The only justification I can think for some of it is that they're passed as props to other components which might use it in another dependency array which actually relies on the thing you pass being memoized.
Edit: and now that I've watched your video, I now understand that using useCallback is necessary for the effort placed into memoizing the component to pay off.
This problem is really hard to mitigate in a virtualized table where every cell is re-rendered for every pixel scrolled. Especially if the cells are not plain text or easy to memoize components. Need to show a tooltip on hover? Bad luck - welcome to the rabbit-hole.
I literally had to solve this problem in every grid/table that I've implement since 2017 to present day and the solutions always felt like workarounds and hacks. React should've solved this re-render issue first before any suspense/rsc stuff since the core job to be done that it's selling is "render" before anything else.
is there and Vue equivalent for react scan?
Vue doesn't need one. It doesn't work like React. It rarely re-renders and when it does that it doesn't update the whole darn tree. Vapor mode baby
It doesnt have that problem to start with, because its reactivity is opt-in
@@andrewxv8088 Also, in addition to the reactivity api, the Vue SFC templates are made to optimize (reduce) rerenderings (Which is not available when you use Vue with JSX or the h() function)
@@xtremescript I worked on Vue projects, that multiple re-renders were definitely a culprit in performance issues. I don't see how Vue magically fixes that. This was like a few years ago using Vue 2.7 with options API though. Not well-versed in Vue 3 to know if the reality is now different.
Vue only calculates the parts of the VDOM that actually changed, so a tool like this would be redundant.
Good to see React catches up with Vue. However, it still lags way behind. So let's focus on Vue instead
there is a best way to fix any react issue - get rid of react
The problem with React is its documentation, those concepts are really simple to understand that should be the first thing you learn before you start writing react code
This is very informative. I was of the belief, also, that React doesn’t constantly scan for changes. Thanks for taking the time to clear misconceptions.
The product is exciting. But still, why do we need react to track things, which will never update on the page? Couldn't it be simple html & css?
this is the price for "reactivity", modern world doesn't want to touch "assembler" (which is vanilla js) - but there are also great frontend frameworks, not using vdom diffing, but signals - seems like best of both worlds
@@frantisek_heca that's the thing. We don't have to get rid of React an use Vanilla, we just have to change the scope of the apps. React should be used for dynamic parts. Static things should be plain html + css. This btw, would let us build better microfrontends and then compose what makes sence later.
That's exactly what's its supposed to be used for. It just became popular to use it as an SPA. a static site with ineractive react components is obviously the best solution. People just like to argue and complain.
The only framework I actually have experience with is Svelte and it apparently just figures out everything that can be affected when you build to make it perform well. No idea about the others but it does work
@@alekseykostyuk3806 but react is all-in, either you have everything in vdom or not, conceptually it's built in that way, i don't see a point in refactoring react to not be like this if there are already awesome frameworks done that way
Looks like compiler did save us a lot of headache like even memo doesnt work if you dont do it right like passing inline
Around 4:05 you mention the checks between the current and new virtual DOMs, would you be willing to go into more detail about this? Do the checks take just as long as making the changes? I feel like I understand most of the video, but this small part feels like such a crucial aspect to the entire video and I feel like it was glossed over just a tad. I would love to hear/learn more about this process in an explicit way (I loved the graphic on the blogpost btw)
I'd like to clarify this question a bit - Whenever i watch other videos talking about reacts re-rendering, they all mention how if something changes, the component and its children are also re-rendered because they are now different from the currently virutal DOM, but the other components remain untouched. Am I understanding you correctly, that you are saying that even though the other components are UNTOUCHED, there is still an existing lag because they still have to be compared to the current DOM to see if any changes have been made, even when there are no changes?
I've never used React and have done minimal JS but this seems like a logical point that every devops team needs to know about.
Devops? Do you mean front-end devs? I don't think devops do too much front-end work, unless they wear many hats.
@@MrMudbill devops often need to be concerned with the complaints of speed of operation; especially during a maintenance event. I did wear many hats during my decades of IT work.
@@eboyd53 speed of operation of what?
good explanation. one of the main things devs gets wrong is that there are two stages of comparison and potential updates. one is between virtual dom's and other between real and virtual
I also figured out this one last month. It's kinda hidden in React while Vue doesn't need.
Why did they stop using signals...
You are a blessing man, thanks for the time earned by watching this 13 minutes video.
I'm currently updating my knowledge about webdev and this channel helps me a lot. Keep up the good work !
Cheers
When i was making my few first ui tree systems purely for fun, with layout geometry generation process, i had a lot of concern on performance with thoughts like "damn, i have to walk my tree up to 3 times recursively to make sure i dont waste computational power and time of a cpu". Also an interesting recursive puzzle was how the algorithm decides what nodes to render and what not..
Damn, that kind of explains why github gist/blob pages take so long to load on 4.6GHz CPU
With the old react component you had full control if it should render using the shouldComponentUpdate method, the new function components didn't make it all that simpler.
I made a site with an openMaps map on it, I basically HAD to use memoization on all the map components otherwise performance sucked enough to visibly see. After memoization everything runs great. I'm sure it could be made even better but memoization isn't that bad and it REALLY helps when you need it.
That's why I prefer Vue
Have you truly noticed github being slow? Speak the truth, don't lie to yourself
i prefer Gaython
Imagine never having these problems in the first place. At least React developers have jobs, good for them
I prefer svelte😂 no more virtual dom
Vue doesn't re-render the component, it just updates the values. Much more efficient.
Love this. I ran into some issues implementing this with the Parceljs build system, but we'll get it working at some point.
This is why I use solidjs
Does this compiler and rerender tool work for react native? Or what is the alternative there?
Would love for this!
Kitze is like the person that replied to me a few days ago saying taking up a large amount of disc space didn't matter because that way programmers aren't wasting their time optimizing unnecessarily.
Kitze released products
@RT-. So? What's your point?
@ He's not just a carping nobody, he speaks from real experience that, most of the time, people will get stuck in traps of making their app perfect and in the end never getting anything out. I resonate with him. Sure, it is better to have an optimized app than a non optimized app. But there's more nuance than that.
facebook on desktop browser is slowAF
Kitze seems like the kind of guy who would rather argue than actually do anything except argue. Not the healthy attitude anyone sane would have.
How do you get react scan working on these sites which you do not have direct access to? Meaning you clearly are visiting sites and able to test them. How do you set that up?
Regarding the VDOM / DOM diff performance problems ...
1. Part of the reason "we don't talk about this" is because there's always someone who pipes up and says "you don't need to worry about re-renders because React is really fast at the diff and it's designed to to work this way". I can see it already in some of the comments 😉
2. The myth that the diff is only done when the props change is perpetuated by the fact that **intuitively** that's the way people would expect it to work. Obviously this babel plugin makes it align with the expectation. But why doesn't it work that way by default ? There must be some gotchas otherwise it would work this way in the first place.
React has always been beta software, now with the compiler it can finally go to 1.0
Can this fix, using the compiler, be applied in nextjs
Goddamn, this "99% of people won't notice" is such a spoiled I-have-a-maxed-out-MBP-and-don't-care dev comment. Imagine older Androids, older hardware in general, heat, other applications running, etc… and this kind of carelessness is definitely noticeable.
Matter of fact, I have cut down my YT time (the irony) because my MBP, which is getting 10 years old soon, can't handle it that well anymore. So more efficient site = more videos watched = more money.
Which tools is that you are using to show the rerenders?
12:25
@@AdorableCatDiaries thanks
Very glad for this improvement, and that it doesn't require any code changes.
I can't looking at Tailwind.
Why did we move away from PHP, html and js?
I never switched to the "functional" React fad. Every single component I make is PureComponent per default, unless it needs to be otherwise. So it doesn't do that re-rendering every time.
but how is colorpicker doesn't rerender with compiler too? you basically change color on every mouse move
genuine question because i am actually interested in the react compiler, can you talk about (or point to a video) talking about the costs or tradeoffs for memo-izing everything (even if it's done automagically by the react compiler)?
Do you guys prefer to memoize the child components and put all of the state at the parent components or simply put the state at the child components so that when it re-renders, it doesn't affect other components other than itself? What are the benefits of each approach?
I think it may be more accurate to say that react has a rerender learning curve problem. I’m intentionally not saying that it’s a skill issue because I don’t want to sound dismissive. React has done a great job of lowering the learning curve for getting started, but I think for handling rerenders properly, that learning curve may still be a bit steep for many people
you could just isolate the state for every component and not use memo at all. The rerendering problem here comes from keeping the state global for all three components
I could have made this a 15 second video. React is old tech. It had its heyday but newer tools have refined concepts and produce better code with better DX and less footguns.
Anyone starting a new project today should not use React. Better tools exist that dont require you to think nearly as hard about how the underlying engine works.
React is trying to shift hard to use these new concepts, but theres so much legacy out there its hard to do.
Use a newer stack and be happy. Svelte 5 is an amazing experience. Ill never go back to React for a new project.
Can someone explain why scrolling and moving cursor causing rerenders too?
I think those actions are managed by the browser and added or managed by the virtual dom
Only time to rerender is if what has already been rendered has actually changed.
Theo just rug pulled us on this one to demo react compiler and now I want to use it. 😠
I still find a use to React.memo and useMemo which is in making inner components. When I create a component that I absolutely don't want to be used outside of a specific component, I create it inside the parent component and have it memoized there.
A lot of resources just teach how to write react but not how react rendering actually works. Where can I learn more about this?
Well, angular got shit on for being slow, and people praised how react is better, look at where we are now.
Angular is still slow as heck, and react is still a little better (with the compiler, WAY better, angular is still stuck with the old change detection mechanisms for most of its ecosystem currently). Most JS frameworks are trash at speed, with few exceptions like svelte or solid-js.
@@diadetediotedio6918 Angular uses signals now, is it old?
Why is the scrolling re-rendering everything?
Is this problem just in the React-World or also relevant for NextJS projects?
100% relevant for nextjs, because nextjs is only a wrapper on top of react
relevant to nextjs because once in the browser nextjs is basically react
@@wlockuz4467 That’s why I asked. But I didn’t know if it is handled the same in the background. Perhaps the wrapper already ships with solutions shown in the video?
@ no, nextjs is not ready to use compiler yet, when using nextjs you usually lag behind react in features
How can I use that compiler? I tried to insert that in my code but it doesn't work
re render has always been a pain in the ass, even the first time i got into react as a mobile developer, it was the most disgusting thing to deal with even more than async rendering
Try to have multiple pinterest tabs open. It slows down my PC so much! It using React explains so much!
I have a question on the compiler-perf-demo download.
I've got it downloaded and unzipped locally, what is the correct setup to get it running?
(I'm new to react and working in an established codebase, so it's harder to start from scratch.)
I thought it would be:
npm install react typescript vite
then
npm run dev
but that gives me errors. I didn't see anything in the readme, but I'm newer to this stuff.
Thank you,
Day 1 of Waiting Theo release new video about changing browser
why would you care lol
unless he's ricing the browser or something
otherwise it's just exporting bookmarks from one and importing on the other and you're off to the races
I don't think I've ever had this be a problem. If a website is slow it's because network is slow.
So, instead of fixing the root of the problem, which is react rerendering each child component on each parent state update, they make a compiler that adds hooks boilerplate for you. And if you think about it, each hook is at least one function call and one new function declaration on every render, which is not optimized at all, but is "fast enough".
At this point, I think they should just use signals like every other framework and admit it's a better model.
May I know what’s actually your vs code font us its really nice 😅
Awesomesuace!!! You are a true BadA**, wow! I did not know that I would learn how to use the React compiler in this video (I watch all of them:-, but rarely comment) , but I am sooo stoked to try this out. Thanks dude...
I'm curious, do other frameworks suffer from this re-rendering issue?
My latest project i wanted to use the react compiler. I appreciate showing the config apparently my build was in react 18 so i had to go through and update and enabling the compiler. The link for the rerender i think will also be super helpful
github is pretty performant as an end user experience if they wasn't using virtualised lists it would have a much poorer user experience on large data sets.
It’s slow. Scrolling around a big pr, it cannot catch up at all. (M1 iMac)
it's slow.
lmao, github is not performant (especially on large prs)
It's not performant but definitely fine for most users.
1000+ files in a single folder in one of my repos kills performance for me. while virtualised lists in theory should help, for some reason it's still slow and a clunky experience.
Is this problem present in Vue2/3 too ? I heard that both Vue only render what changes, not the entire page.
Which is true
@@youloulou6591 so Vue doesn't has this problem ?
I assume a framework like Svelte gets this by default, no? I'm not experienced enough to say that confidently so if anyone knows for certain I'd appreciate it.
On the one hand, I’ll keep this in mind if I have to maintain a React app. On the other hand, I don’t see myself wanting to change my plans from migrating from AngularJS to Vue. Every time I see React code it just seems…. like something Zuckerberg would make, and more convoluted than I would think necessary.
Angular signals is looking pretty good right about now
I have not developed in React in 5 years. This is the 1st time I'm excited for react.
"complexity very, very bad
given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex"
when is the browser video that was live on x dropping?
im stuck at the same spot with the dying of arc browser and im not sure if i should go the safari or zen route
basically if u r not dumb u should use solid instead of react, if u are open to new syntax you can prefer svelte also but dont be a react dev if you want to be an engineer, performence is one of the important things to consider
sad is when your company chose the react tech (nextjs) :(
Use the tool that gets the job done most effectively.
@@MrMudbill
Which you don't know a priori, so this comment is pointless.
but is it safe and fine to start to use react compiler now? while it is still has no stable version
Hey, thanks for this video ... what color theme is this ?
The same people who complain that you have to put the bare minimum amount of effort into making a react app not run like crap are the same people who are making apps that lock up because everything is done on the render thread
Because of this rebuilding facebook feed excluding ads on it real time is so slow and laggy.
Is "React Compiler" some new/optional project or is it just the normal transpiler that I always have to use to convert my .tsx files into JavaScript bundles?
I've played with react but ages ago so I'm no expert. But I've seen this videos before. Opting out of rerendering and opt-ion memoize seems like a bad thing and I wonder why this is still the case today...
Unrelated comment:
I watched Severance for the first time, and whenever Adam Scott starts talking, he sounds exactly like Theo