Thanks for the video! I'm really glad to see 'React Forget' coming close to a usable state. React's use of stateful render functions for its components (vs Solid's constructor functions) makes the framework inherently less performant, but kudos to the folks on the React team, who are obviously making a monumental effort to close that gap. Being able to write less crazy workaround code is going to be a real boon.
Lol Mobx getting the shaft. Thanks for the video and, specifically, the compiled explanations. I'm glad the React team has done their due diligence by making the great leap into compiler world. Always appreciated it as a DOM library, but we all gotta change sometime.
Love all your videos, been watching for a couple years now. Your key takeaways in this video answered my concerns with MobX! Keep up the awesome work Jack !
This is huge! I am somehow worried but I think the compiler is great but I also think it takes alot from beginners where you have to learn that this can't work if the ref is changing and why it's changing. Also we need to keep in mind that there is a bunch of stuff happening in the background I'd say because react was and still is just JavaScript using all its rules but now some things get hidden so some could get a dumb down effect where they will wonder why its not working. So we need to encourage people to still write good structured code I think this will benefit my react native projects too. I am worried that too much caching might push the memory usage of the apps but I think it will be fine as its only for the mounted states and pointing to something is just fine.
oh god, I can already imagine so much of our code breaking because we do some dumb usememos where we want to recompute the value only when one of the 2 values changes.
It feels like we’ll have a stable flow around this fall or christmas due to other libraries’ dependency incompatibilites to work with react 19 and new compiler. But it’s pretty exciting news whatsoever because after getting used to server components and server actions with nextjs, the only cumbersome approach left is memoizing functions and calculated values. Thanks for sharing the experience and the mental model under the hood!
9:22 if the calculation is gonna be done this way doesn't that mean it'll be computed every single time? Whereas in useMemo it's only calculated on mount. So if it was a very long computation then the app can feel much slower with the compiler rather than the just the transpiler
Nice vid. What I'm most afraid of is if the compiler changes the semantics of a program. If it works with the compiler it should rather not be buggy without it. Also regarding the const name optim, Babel AST has a node.evaluate() and is already able to do such optimizations where one variable can be substituted by a const in the same file. I use this on Docusaurus to extract semi-static translation strings from the codebase.
But this might result in a larger app size because it will add extra code when compiled compared to signals which are runtime based. From my perspective signals are better but still this is a good change.
I'd be very surprised if it makes any material difference. At the end of the day, if you're deploying an app with server rendering/code splitting/lazy loading/minification it'll be a tiny amount of code for a huge payoff. 99% of all bundle problems come from the packages added (and typically only use a fraction of) anyway. As always, better focus on the big improvements, instead of worrying about what your code has compiled too
Valid points and also with gzip the increase in app size might be minimal.
4 หลายเดือนก่อน +1
Debugging will be tricky. You are going it hit breakpoints only on the first render or the updated render, where the breakpoint is at exact location where the update is happening.
One thing I can think of that makes this POTENTIALLY better than runtime signals is that it MIGHT be more deterministic. Signals can sometimes fail based on not following the rules of signals, which can vary based on framework. E.g. destructuring too early or something. Even if you follow the rules it can be hard to track reactivity and why things are not reacting in signals. React has a ton of rules too yet this compiler does remove some of the worst of them.
Thanks for the video. Considering dependency arrays are linted for which dependencies should be present, and they can be updated in an IDE using a keyboard shortcut, why should we need to maintain a dependency array? Speaking in general, if you are following the principles of react, you shouldn't need to bypass the type hints with extraneous dependencies. It would be nice if they were optional and we didn't even have to bother wrapping things with useMemo/useCallback.
I don't get how this compiler would be better than for example vue build tool to manage re render. It's seems more like react catching up on that front. Vue's reactivity is op out by default
Ultimately fixing the memo problem in the compiler is simply returning `() => __jsx(...)` instead of `__jsx(...)`. This way you just need to call whatever function is returned vs its parent function on re-render.
@@mattvicentActually not quite. Yes, you are allowed to directly code it in the render phase, however there are some cases where you do need to still use useEffect without dependencies. For instance, you are not allowed to access and mutate useRef mutable reference as this can lead to "UB" (see "Pitfall" on the useRef documentation). Note the subtlety here: this does not change the fact that there is still a distinction between the render phase (which React will expect your components to be free of side effects) and when effects are actually being run. React Compiler does not change this fact.
I am curios what happens with code that should not be memoized - derived state which dependens on most or even all of the component's props - cases when memoization is actually worse for performance than simply computing the value everytime.
The overhead of useMemo is minimal. And it's even less here because the compiler is using the new useMemoCache hook just once to create an array that manages the memoization. Personally I can't think of a case where not memoizing at all would be significantly faster than this. There has been a lot of FUD over the years about over-memoization and I've never actually seen that in practice. What I've seen is performance issues when stuff is NOT memoized when it should be, or when folks are hacking, doing crazy stuff like using JSON.stringify in their dependency arrays.
Great video! Can't wait to use React Compiler! Have a question here. Why React Compiler could not "compile" SortedList component in 11:02? isn't it as simple as removing the useMemo in the Compiler code?
My guess is the sortedNames.map it would need to know what the javascript function does and that could be difficult on lower level without putting some edge cases?
Quick Question: Do you know if manual memoization / callback will be unrecommended in the future? I know react loves to keep backwards compatibility but maybe the compiler is smarter then us and also knows how to do it better. Which means do we just write beautiful clean code without any memos and useCallbacks in the future or is it completely up to us if we don't break any rules the result may be the same or at least better?
I think it will be. It's not there now. According to the folks I talked with the hooks API was always designed to be automatable by a sufficiently sophisticated compiler. That's not actually what's happening here though. They created a new hook that the compiler uses that is more efficient than creating lots of useMemo/useCallbacks. You invoke the component once to get a set of memoized slots that they then use to manage the memoization.
wow react compiler looks really great though!!. Still has a lot of scope for improvements. I wonder why they didn't think of it atleast while introducing functional components. was it like they didn't think of the worst case scenario that this library can be pushed into? What React team gonna build next ? Maybe a custom react JS engine on top of browser's JS engine to efficiently execute JS functions produced by the Babel with React compiler.. I think its time to challenge backend developers for a battle of complexity😅.
Hi Jack! You mentioned that MobX won't work because of Proxies. All right, am I correct if I say that the same goes with Valtio? Another Proxy based library created by Daishi Kato.
I am sorry but I don't think I was able to connect dots when you move in b/w the normal version and compiler version that much. It was moving too fast.
Just FYI, you can slow the video down by setting the playback speed to be slower. You can also use the scrubber to replay certain sections multiple times.
Context works just fine. As for signals, depends on what you mean by that. If you are talking about preact-signals then that's really on them to figure out. Last time I looked preact-signals was directly altering the DOM nodes when a signal change and the signal was bound to a text element. If you are doing that then... well... who knows. Your fighting the framework and you get what you get. If what you mean is just using signals as a data management and dependency graph, then using something like useSignal to integrate it into your components, then that will work just fine. MobX is really the exception here since components are wrapped in an observer, and it's that observer that manages what changes. The compiler doesn't understand the semantics of the observer function and so it just falls back on not optimizing the component.
To visually track state changes and re-renders of React components within Google Chrome, you can use the "Highlight updates when components render" feature in the React Developer Tools extension. Here's how to enable it: Install the React Developer Tools extension for Chrome. Open your React application in Chrome. Open the React Developer Tools panel (usually found under "Developer Tools" > "React"). In the React Developer Tools panel, click on the settings icon (gear icon). Check the "Highlight updates when components render" option. With this option enabled, whenever a React component re-renders due to a state change or prop update, a colored border or rectangle will flash around that component in the browser window. This visual highlighting helps identify which components are re-rendering and when, making it easier to debug performance issues or unnecessary re-renders.
That wasn't in there because I don't have the data on that. Meta showed the data in their presentation because they have the data on the impact when they ported all of Instagram to it. It was 12% faster UI performance overall, with no change in memory footprint.
Will the compiler really ever be able to fix the need for a dependency array in useEffect? How would you opt out of it reruns. I might use a reactive value in the useEffect that isn’t meant to be part of the dependency array. That’s why solidjs provides an opt out array not an opt in array
My hunch is that at some point there will be an option al have the compiler manage the arrays and you can opt out when you need to. That’s not in there now though.
I'm just slightly confused... first "react forget" was the big hype of React 19 release but now we have "compiler" and that is supposedly NOT coming in React 19? is react forget now called compiler or are those two separate features?
Forget was the code name, React Compiler is the real name. React 19 is just the version of the library. React Compiler is a set of tools, including babel and eslint plugins, that optimizes components and hooks in React 19 code.
Could there be a case where we do want components to re-render but it is optimized by the compiler and now they do not re-render? I can't think of a situation where it is required, but I wouldn't be surprised.
I can't think of any legitimate circumnstance underwhich this would be the case. React components re-render when state, props, or context change. If you aren't changing any of those, why would the component need to re-render?
the software industry is all about bandaids. software continually evolves, but the industry can't wait forever for the perfect library or framework or language, so at some point they place long-term bets so you get huge "legacy" applications written in Java 1.8, PHP 5, jquery, or recently react, and there is a large demand for getting better performance without spending a lot of money and time rewriting entire projects.
I'm sure they did weigh in the tradeoffs with this and decided it was worth doing. React team moves slowly and quite deliberately. Yes I don't think React is perfect, but with big changes in React, the team usually knocks it out of the park in my opinion.
It's not using useCallback and useMemo specifically. There is a single useMemoCache hook that it uses that is run once and is used for all the memoization of the whole component. So that's going to be faster than a set of individual useMemo/useCallback calls. But one hook vs many hooks is in the noise performance wise. The big win is in the memoization of the elements which reduces whole code paths of execution as the memoized code is smart enough to avoid re-rendering component trees that don't need re-rendering.
I noticed the compiler is not memoizing functions from custom hooks. I had to useCallback my functions in my custom hooks to avoid rerenders. Any idea why?
Is it not optimizing any custom hooks? Or just that one custom hook? If it's just that one then it's possible that the compiler assessed some issue with it that wouldn't allow for optimization. The compiler is very conservative. If it doesn't think it can safely optimize the code without a change in behavior it will just leave the component or hook as is.
@@jherr Thank you for your reply. Yes I noticed it is not optimising any functions destructed from custom hooks. I thought the compiler will do so but when I brought back useCallback to memoize functions in custom hooks then components using these functions stopped re-rendering.
I don’t fully understand the question. All it’s doing is optimizing the components and hooks. It’s not doing any kind of bundling or tree shaking. The code shown in the video is a decent view of what the compiler is doing.
@@jherr Ok ma bad, I made an edit and will also rephrase it better here, but I think the answer is no based on the examples you provided, but anyway, what I mean is when it comes to the building/bundling time for production I thought it will just compile the react code into JS code and no need to generate the vendor chunk file which included in /dist because the code is compile from declarative to imperative, I hope I made it more clearer 💙
Huh is the counter component from 8:49 different then 0:33? Because I don't see props being passed. Does React Forget make and object argument a stable ref now? Is the memo already applied in the parent component? That would be great tho! I guess legend state would break if I upgrade to 19 because it proxy based?
The source on that one was a talk I have with Joe Savona directly. Basically the compiler doesn't get that this value can magically change, so it memoizes it for performance. Thus... bug.
9:50 i don't understand the names example. the prop is passed as-is to useState, so the value of the state should automatically update when the prop changes because useState will receive a new reference. what's the point of the useMemo..? it looks like a very wrong useEffect...
nope, name will be passed to the usestate only in the initial render, afterwards the name constant will not be updated anytime the usestate function receives a new value. It is called initial value for a reason
@@whoman7930 wow. i've worked with react a ton and always had this wrong assumption... thanks for letting me know. so the only oddity of that code example is that useMemo was used instead of useEffect? or how would you implement a state variable that's both updateable by the component itself as well as it's parent component?
Not significantly. This will hold references to elements, which are just pointers, so they are small. And we were already keeping those in the VDOM. Also, it's pretty smart about not memoizing every single element. It groups elements together based on their data, or lack thereof.
Why are we calling it a React Compiler when it would be far more accurate to call it React Transpiler (converts JavaScript to a more optimized form of JavaScript)
IMHO, it's really more of a compiler since, at least to me, I view a transpiler as making small code modifications for compatibility. Where these are more profound refactorings of code. For example the inline onClick callback function is moved into the memoization block where it's memoized with the data that it references. And then connected to its tag in a different memoization block later on when appropriate. That's a much more profound code modification than a simple transpilation.
Compilation definition by dictionary: processed through software that translates a complete set of high-level computer instructions into machine language before executing any of them. So I don't think it's correct to say "React Compiler". It does not matter what it does. If it does not generate machine code, it's not a compiler.
@@clusterdriven Cool. What's the dictionary definition of "machine"? I'm pretty sure that most folks consider the Java compiler a compiler, and it compiles code to the Java virtual "machine". Ruby also has a virtual machine. And it interprets from raw text and only has the bytecode model in memory. But that transformation step is "compilation" because it's compiling to a machine. So depends on what your definition of a machine is. BTW, this is the reason that many folks consider the structure and function of the compiler to be the arbiter of the definition, and not the target.
I was kind of hoping that the compiler would decrease bundle size, but it looks like it actually bloats the code, what about memory, the code may run faster (react always assumed that the real bottleneck is Dom operations and repaint), but doesn’t memoization use quite a lot if ram?
Outside of one small next specific issue around their font support requiring SWC (which means no babel, which means no compiler) Next is completely compatible.
React, itself, doesn't do that, because then it wouldn't be viable in React Native or server-side. React generating an optimized AST means that ReactDOM can generate JS/DOM, React Server Components can generate HTML text, and React Native can generate whatever the native platform expects, so long as you are using middle of the road, interchangable components.
So project React Forget "MobX" has finally released their 300kloc+ monster of a horse pill "compiler". The industry is moving towards "signals" so why isn't React being made more officially pluggable with external reactivity systems? Why on earth would they spend this much time and money to release such a monstrosity on the world?! Legacy code. This is designed for "quick" wins on absolutely horrifying legacy code bases that are permanently moored in hook hell. Frankly I wouldn't be surprised if a lot of the industry decides to NOT get tangled up with this thing.
And once this "feature" is released, you can look forward to the next major React release that introduces a new "feature" to work around all the bugs this "feature" causes :) You React people are so silly.
Thanks for making high quality indepth videos! I know this kind of content takes a lot of time.
Thank you.
Thanks for the video!
I'm really glad to see 'React Forget' coming close to a usable state.
React's use of stateful render functions for its components (vs Solid's constructor functions) makes the framework inherently less performant, but kudos to the folks on the React team, who are obviously making a monumental effort to close that gap. Being able to write less crazy workaround code is going to be a real boon.
Lol Mobx getting the shaft.
Thanks for the video and, specifically, the compiled explanations. I'm glad the React team has done their due diligence by making the great leap into compiler world. Always appreciated it as a DOM library, but we all gotta change sometime.
Good stuff Jack! Love the technique you’re using to highlight individual sections of code.
Love all your videos, been watching for a couple years now. Your key takeaways in this video answered my concerns with MobX! Keep up the awesome work Jack !
Amazing! I had to use why-did-you-render for this. Hope they include some debug mode for unnecessary rendering tool.
Thanks for the breakdown of the React compiler Jack! 🔥
Can we appreciate the custom repl Jack just built? This is such a good content quality.
This is huge!
I am somehow worried but I think the compiler is great but I also think it takes alot from beginners where you have to learn that this can't work if the ref is changing and why it's changing.
Also we need to keep in mind that there is a bunch of stuff happening in the background I'd say because react was and still is just JavaScript using all its rules but now some things get hidden so some could get a dumb down effect where they will wonder why its not working.
So we need to encourage people to still write good structured code I think this will benefit my react native projects too.
I am worried that too much caching might push the memory usage of the apps but I think it will be fine as its only for the mounted states and pointing to something is just fine.
oh god, I can already imagine so much of our code breaking because we do some dumb usememos where we want to recompute the value only when one of the 2 values changes.
Incredible video! I hope you can cover the new patterns/best practices for building react19.
Yeah Design pattern and System Design as relative to FE.
Hey Jack, Nice meeting you at react 2024 conf. As usual great content.
❤ Great content, Jack! Dang saw you at React Conf, should’ve said hello. Next time!
Definitely!
It feels like we’ll have a stable flow around this fall or christmas due to other libraries’ dependency incompatibilites to work with react 19 and new compiler. But it’s pretty exciting news whatsoever because after getting used to server components and server actions with nextjs, the only cumbersome approach left is memoizing functions and calculated values. Thanks for sharing the experience and the mental model under the hood!
Why not put gpt on the task and gace it out sooner?
Thanks for the video!! 🙏🙏🙏
Fantastic video - thanks!
Amazing video thanks!
9:22 if the calculation is gonna be done this way doesn't that mean it'll be computed every single time? Whereas in useMemo it's only calculated on mount. So if it was a very long computation then the app can feel much slower with the compiler rather than the just the transpiler
Nice vid.
What I'm most afraid of is if the compiler changes the semantics of a program. If it works with the compiler it should rather not be buggy without it.
Also regarding the const name optim, Babel AST has a node.evaluate() and is already able to do such optimizations where one variable can be substituted by a const in the same file. I use this on Docusaurus to extract semi-static translation strings from the codebase.
Good golly is it nice to see React finally answering Solid and Svelte in this way. This is going to make our code so much cleaner.
But this might result in a larger app size because it will add extra code when compiled compared to signals which are runtime based. From my perspective signals are better but still this is a good change.
Who cares. React apps are boated hogs for years, nobody in that community cares about network performance.
I'd be very surprised if it makes any material difference. At the end of the day, if you're deploying an app with server rendering/code splitting/lazy loading/minification it'll be a tiny amount of code for a huge payoff. 99% of all bundle problems come from the packages added (and typically only use a fraction of) anyway. As always, better focus on the big improvements, instead of worrying about what your code has compiled too
Valid points and also with gzip the increase in app size might be minimal.
Debugging will be tricky.
You are going it hit breakpoints only on the first render or the updated render, where the breakpoint is at exact location where the update is happening.
your videos are very insightful and I always learn some new things
Great as always!
You are greate Jack! keep it like that
Great video, very interesting!
One thing I can think of that makes this POTENTIALLY better than runtime signals is that it MIGHT be more deterministic. Signals can sometimes fail based on not following the rules of signals, which can vary based on framework. E.g. destructuring too early or something. Even if you follow the rules it can be hard to track reactivity and why things are not reacting in signals.
React has a ton of rules too yet this compiler does remove some of the worst of them.
Agreed. The perf metrics will be very interesting.
Really appreciate this 👍
Thats cool they saw the preact signal and think about it that way
The work on React Compiler started way before Preact Signals and has nothing in common with that approach.
Thanks for the video. Considering dependency arrays are linted for which dependencies should be present, and they can be updated in an IDE using a keyboard shortcut, why should we need to maintain a dependency array? Speaking in general, if you are following the principles of react, you shouldn't need to bypass the type hints with extraneous dependencies. It would be nice if they were optional and we didn't even have to bother wrapping things with useMemo/useCallback.
I don't get how this compiler would be better than for example vue build tool to manage re render. It's seems more like react catching up on that front. Vue's reactivity is op out by default
great content, bravo! 👏 👏 👏
Great video! thanks!
All that knowledge about memoization, dependency arrays and reconciliation I've gathered over the years is now becoming obsolete.
No, it's important to understand how the technologies work.
with the rearranging of the code, I expect it to build its sourcemap as well then?
Hey! glad I bumped into your video, high quality stuff!
I do have one question tho - are you sure that the compiler is not part of React 19?
100% sure.
You deserve to get your chance to speak at that conf ♥👍
Yeah, I submit a paper but it didn't get picked. :(
Great video Jack! I just notice that React Compiler is written in Rust !!! I hope some day you make a video about Rust...
It’s not. It’s written in node. It’s a babel plugin
They are writing an optimised version in Rust as well but current version is in Node
Thank you for using my kawaii logo for the thumbnail!
And thank you for making that logo. You are credited in the description.
@@jherr Thank you~!!!!
Are you the goat who’s been rewriting everyone’s logo in kawaii?
@@dylanthony1 yes :)
Optimizing compiler for JS… Google Closure rebuilds based on AST as well (old school)
unrelated but what camera are you using? has great detail on shadows AND highlights!
A7SIII with a 35MM GM lens.
Ultimately fixing the memo problem in the compiler is simply returning `() => __jsx(...)` instead of `__jsx(...)`. This way you just need to call whatever function is returned vs its parent function on re-render.
9:06 your useMemo should have [count] as a dependency
Great Content.
From Jquery to Frontend needing compilers...yea I grew up.
Can you share your VS Code settings.json and theme with us please :)
Now we have a use case for use effect without a dependency array 🎉🎉 - which is to run some code every time the component re-renders
Well, now you could just do it directly in the body of the component hehe
@@mattvicentActually not quite. Yes, you are allowed to directly code it in the render phase, however there are some cases where you do need to still use useEffect without dependencies. For instance, you are not allowed to access and mutate useRef mutable reference as this can lead to "UB" (see "Pitfall" on the useRef documentation).
Note the subtlety here: this does not change the fact that there is still a distinction between the render phase (which React will expect your components to be free of side effects) and when effects are actually being run. React Compiler does not change this fact.
I am curios what happens with code that should not be memoized - derived state which dependens on most or even all of the component's props - cases when memoization is actually worse for performance than simply computing the value everytime.
The overhead of useMemo is minimal. And it's even less here because the compiler is using the new useMemoCache hook just once to create an array that manages the memoization. Personally I can't think of a case where not memoizing at all would be significantly faster than this.
There has been a lot of FUD over the years about over-memoization and I've never actually seen that in practice. What I've seen is performance issues when stuff is NOT memoized when it should be, or when folks are hacking, doing crazy stuff like using JSON.stringify in their dependency arrays.
Great video! Can't wait to use React Compiler!
Have a question here.
Why React Compiler could not "compile" SortedList component in 11:02? isn't it as simple as removing the useMemo in the Compiler code?
Thanks for the reminder. I’ll talk with the team about that.
My guess is the sortedNames.map it would need to know what the javascript function does and that could be difficult on lower level without putting some edge cases?
Thanks
Quick Question:
Do you know if manual memoization / callback will be unrecommended in the future?
I know react loves to keep backwards compatibility but maybe the compiler is smarter then us and also knows how to do it better.
Which means do we just write beautiful clean code without any memos and useCallbacks in the future or is it completely up to us if we don't break any rules the result may be the same or at least better?
I think it will be. It's not there now. According to the folks I talked with the hooks API was always designed to be automatable by a sufficiently sophisticated compiler. That's not actually what's happening here though. They created a new hook that the compiler uses that is more efficient than creating lots of useMemo/useCallbacks. You invoke the component once to get a set of memoized slots that they then use to manage the memoization.
👍
Why in the first example all components refender ? We just setstate first counter, we don’t touch second one
Because react by default renders everything in a component on a state change in the parent component.
wow react compiler looks really great though!!. Still has a lot of scope for improvements.
I wonder why they didn't think of it atleast while introducing functional components. was it like they didn't think of the worst case scenario that this library can be pushed into?
What React team gonna build next ? Maybe a custom react JS engine on top of browser's JS engine to efficiently execute JS functions produced by the Babel with React compiler..
I think its time to challenge backend developers for a battle of complexity😅.
What's the reason it can't optimize the Sortedlist component at @11:09?
Hi Jack! You mentioned that MobX won't work because of Proxies. All right, am I correct if I say that the same goes with Valtio? Another Proxy based library created by Daishi Kato.
I hope I'm going to finish reading No BS TS before No BS Next.js comes (and I hope Next.js course coming very soon!)
Yeah. My hunch is that valtio is also incompatible.
It’s still running though 😂 still watching
I am sorry but I don't think I was able to connect dots when you move in b/w the normal version and compiler version that much. It was moving too fast.
Just FYI, you can slow the video down by setting the playback speed to be slower. You can also use the scrubber to replay certain sections multiple times.
Wow. 🤯
What about state management, would context or signals need be somewhat taken away?
Context works just fine.
As for signals, depends on what you mean by that. If you are talking about preact-signals then that's really on them to figure out. Last time I looked preact-signals was directly altering the DOM nodes when a signal change and the signal was bound to a text element. If you are doing that then... well... who knows. Your fighting the framework and you get what you get.
If what you mean is just using signals as a data management and dependency graph, then using something like useSignal to integrate it into your components, then that will work just fine.
MobX is really the exception here since components are wrapped in an observer, and it's that observer that manages what changes. The compiler doesn't understand the semantics of the observer function and so it just falls back on not optimizing the component.
The moment there were rumours about react forget, I stopped using memoization wrappers in my code so I don’t have to remove them all over again 😄
madlad
exciting
How are you getting the boarders to show when state changes?
To visually track state changes and re-renders of React components within Google Chrome, you can use the "Highlight updates when components render" feature in the React Developer Tools extension. Here's how to enable it:
Install the React Developer Tools extension for Chrome.
Open your React application in Chrome.
Open the React Developer Tools panel (usually found under "Developer Tools" > "React").
In the React Developer Tools panel, click on the settings icon (gear icon).
Check the "Highlight updates when components render" option.
With this option enabled, whenever a React component re-renders due to a state change or prop update, a colored border or rectangle will flash around that component in the browser window. This visual highlighting helps identify which components are re-rendering and when, making it easier to debug performance issues or unnecessary re-renders.
How is it the most advanced compiler? Svelte literally exists because of the compiler, there’s no runtime in v4
Glad to see react didnt forget react forget. But its definitely not the most advanced compiler, still great tho.
Thanks, but there are one point that have not appeared, the performance impact and specially when the memorization the components
That wasn't in there because I don't have the data on that. Meta showed the data in their presentation because they have the data on the impact when they ported all of Instagram to it. It was 12% faster UI performance overall, with no change in memory footprint.
So how do we get it if not with 19? Will it be separate package that we need to install into project? Or will we have to wait for next version?
Will the compiler really ever be able to fix the need for a dependency array in useEffect? How would you opt out of it reruns. I might use a reactive value in the useEffect that isn’t meant to be part of the dependency array. That’s why solidjs provides an opt out array not an opt in array
My hunch is that at some point there will be an option al have the compiler manage the arrays and you can opt out when you need to. That’s not in there now though.
This is beautiful ... 🥹
🔥🔥🔥
There is a "DONT_USE_OR_YOU_WILL_BE_FIRED" export in the react code? 😂
I'm just slightly confused... first "react forget" was the big hype of React 19 release but now we have "compiler" and that is supposedly NOT coming in React 19? is react forget now called compiler or are those two separate features?
Forget was the code name, React Compiler is the real name. React 19 is just the version of the library. React Compiler is a set of tools, including babel and eslint plugins, that optimizes components and hooks in React 19 code.
thank you!
So like Angular
Actually, Angular requires a compiler. This is an optional optimizing compiler.
Could there be a case where we do want components to re-render but it is optimized by the compiler and now they do not re-render? I can't think of a situation where it is required, but I wouldn't be surprised.
I can't think of any legitimate circumnstance underwhich this would be the case. React components re-render when state, props, or context change. If you aren't changing any of those, why would the component need to re-render?
@@jherr Yes, makes sense. Thank you so much, amazing video.
React compiler is more of a band-aid over a deeper design flaw. Caching is great, but it isn't free.
What’s the alternative? Solid?
@@BurgerBurglar8964 Try Svelte I think...
the software industry is all about bandaids. software continually evolves, but the industry can't wait forever for the perfect library or framework or language, so at some point they place long-term bets so you get huge "legacy" applications written in Java 1.8, PHP 5, jquery, or recently react, and there is a large demand for getting better performance without spending a lot of money and time rewriting entire projects.
Compile React to SolidJS and you get mad perf gains bro.
I'm sure they did weigh in the tradeoffs with this and decided it was worth doing. React team moves slowly and quite deliberately. Yes I don't think React is perfect, but with big changes in React, the team usually knocks it out of the park in my opinion.
From the looks of it, react compiler basically adds memoization to everything. Isn't it bad to add usememo and usecallback to everything?
It's not using useCallback and useMemo specifically. There is a single useMemoCache hook that it uses that is run once and is used for all the memoization of the whole component. So that's going to be faster than a set of individual useMemo/useCallback calls. But one hook vs many hooks is in the noise performance wise. The big win is in the memoization of the elements which reduces whole code paths of execution as the memoized code is smart enough to avoid re-rendering component trees that don't need re-rendering.
Does it work with Vite?
Yes.
I noticed the compiler is not memoizing functions from custom hooks. I had to useCallback my functions in my custom hooks to avoid rerenders. Any idea why?
Is it not optimizing any custom hooks? Or just that one custom hook? If it's just that one then it's possible that the compiler assessed some issue with it that wouldn't allow for optimization. The compiler is very conservative. If it doesn't think it can safely optimize the code without a change in behavior it will just leave the component or hook as is.
@@jherr Thank you for your reply. Yes I noticed it is not optimising any functions destructed from custom hooks. I thought the compiler will do so but when I brought back useCallback to memoize functions in custom hooks then components using these functions stopped re-rendering.
**EDIT** Does it compile the react code and while building is the React vendor/dependency opted-out from the final production bundle like Svelte?
I don’t fully understand the question. All it’s doing is optimizing the components and hooks. It’s not doing any kind of bundling or tree shaking. The code shown in the video is a decent view of what the compiler is doing.
@@jherr Ok ma bad, I made an edit and will also rephrase it better here, but I think the answer is no based on the examples you provided, but anyway, what I mean is when it comes to the building/bundling time for production I thought it will just compile the react code into JS code and no need to generate the vendor chunk file which included in /dist because the code is compile from declarative to imperative, I hope I made it more clearer 💙
Huh is the counter component from 8:49 different then 0:33? Because I don't see props being passed. Does React Forget make and object argument a stable ref now? Is the memo already applied in the parent component? That would be great tho! I guess legend state would break if I upgrade to 19 because it proxy based?
Yeah the state space is going to be changing.
Legend state works I’ve upgraded to 19
@@thevutv2349 it’s not just 19 you also have to add the compiler. 19 does NOT include the compiler.
Hey Jack, great video, thanks! Is there any source I can read about MobX incompatibility with compiler in more depth?
I need that info too. Cant find anything about that. Thanks !
The source on that one was a talk I have with Joe Savona directly. Basically the compiler doesn't get that this value can magically change, so it memoizes it for performance. Thus... bug.
@@jherr Thanks! I also run compiler health check on my MobX project and it indeed told me that MobX isn’t supported ☹️
Which extension is used here to highlight components which are rerendered?
That's React Devtools for Chrome.
9:50 i don't understand the names example. the prop is passed as-is to useState, so the value of the state should automatically update when the prop changes because useState will receive a new reference. what's the point of the useMemo..? it looks like a very wrong useEffect...
That's not how it works.
`useState` takes the default value only for the first time when the component is mounted.
nope, name will be passed to the usestate only in the initial render, afterwards the name constant will not be updated anytime the usestate function receives a new value. It is called initial value for a reason
@@whoman7930 wow. i've worked with react a ton and always had this wrong assumption... thanks for letting me know.
so the only oddity of that code example is that useMemo was used instead of useEffect? or how would you implement a state variable that's both updateable by the component itself as well as it's parent component?
@@FunctionGermany The best way is to use global state, and use the state through props.
And yes we can use useEffect for this, but its not much ideal.
Will they no longer need Babel?
What does that mean? Who is they? I don't understand the question.
Which state management library would the compiler work with?
Redux, zustand, recoil, jotai, those are all fine. It’s just proxied state managers like mobx and valtio and maybe legend.
@@jherr thanks for mentioning it I was not aware of this!
It should be Nice to add credit to logo creator
…
Correct, my bad and fixed.
Mobx: my bad. 😭
Its nice but to make this work, it will use more memory right? since they cache everithing now.
Not significantly. This will hold references to elements, which are just pointers, so they are small. And we were already keeping those in the VDOM. Also, it's pretty smart about not memoizing every single element. It groups elements together based on their data, or lack thereof.
@@jherr I see, thanks for sharing. :)
Why are we calling it a React Compiler when it would be far more accurate to call it React Transpiler (converts JavaScript to a more optimized form of JavaScript)
IMHO, it's really more of a compiler since, at least to me, I view a transpiler as making small code modifications for compatibility. Where these are more profound refactorings of code. For example the inline onClick callback function is moved into the memoization block where it's memoized with the data that it references. And then connected to its tag in a different memoization block later on when appropriate. That's a much more profound code modification than a simple transpilation.
Compilation definition by dictionary:
processed through software that translates a complete set of high-level computer instructions into machine language before executing any of them.
So I don't think it's correct to say "React Compiler". It does not matter what it does. If it does not generate machine code, it's not a compiler.
@@clusterdriven Cool. What's the dictionary definition of "machine"? I'm pretty sure that most folks consider the Java compiler a compiler, and it compiles code to the Java virtual "machine". Ruby also has a virtual machine. And it interprets from raw text and only has the bytecode model in memory. But that transformation step is "compilation" because it's compiling to a machine. So depends on what your definition of a machine is.
BTW, this is the reason that many folks consider the structure and function of the compiler to be the arbiter of the definition, and not the target.
But when you disable the React.Strict mode the code will update only once. Why is this so?
I was kind of hoping that the compiler would decrease bundle size, but it looks like it actually bloats the code, what about memory, the code may run faster (react always assumed that the real bottleneck is Dom operations and repaint), but doesn’t memoization use quite a lot if ram?
Just run a minifier after it compiles for prod builds.
Just see the output of Svelte code after compiled, it's a similar process.
You are not suppose to ship directly that code but use a bundler.
1 minute 5 comments already
you know Svelte has been doing the exact same thing with much less code for the last 5 years+. Most advanced? more like latest to the party
How is this compiler guy changing the nextjs scenarios plz make a video about it.
Outside of one small next specific issue around their font support requiring SWC (which means no babel, which means no compiler) Next is completely compatible.
Why can't it turn jsx into plain js? Doesn't svelte do this?
React, itself, doesn't do that, because then it wouldn't be viable in React Native or server-side.
React generating an optimized AST means that ReactDOM can generate JS/DOM, React Server Components can generate HTML text, and React Native can generate whatever the native platform expects, so long as you are using middle of the road, interchangable components.
So project React Forget "MobX" has finally released their 300kloc+ monster of a horse pill "compiler".
The industry is moving towards "signals" so why isn't React being made more officially pluggable with external reactivity systems? Why on earth would they spend this much time and money to release such a monstrosity on the world?!
Legacy code. This is designed for "quick" wins on absolutely horrifying legacy code bases that are permanently moored in hook hell.
Frankly I wouldn't be surprised if a lot of the industry decides to NOT get tangled up with this thing.
where is react rules link ??
react.dev/reference/rules And added to the description
Thanks !! But i already got it from react conference video 😊
And once this "feature" is released, you can look forward to the next major React release that introduces a new "feature" to work around all the bugs this "feature" causes :)
You React people are so silly.
I am very happy that Donal Trump has switch to this field.