Thank you.

Yeah Design pattern and System Design as relative to FE.

Why not put gpt on the task and gace it out sooner?

Definitely!

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.

100% sure.

A7SIII with a 35MM GM lens.

Agreed. The perf metrics will be very interesting.

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.

The work on React Compiler started way before Preact Signals and has nothing in common with that approach.

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.

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

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.

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.

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 💙

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.

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?

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 :)

Yeah, I submit a paper but it didn't get picked. :(

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.

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.

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.

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.

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.

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.

No, it's important to understand how the technologies work.

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.

Because react by default renders everything in a component on a state change in the parent component.

That's React Devtools for Chrome.

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.

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.

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.

Yes.

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 ☹️

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.

madlad

Actually, Angular requires a compiler. This is an optional optimizing compiler.

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!

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. :)

Correct, my bad and fixed.

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.

What does that mean? Who is they? I don't understand the question.

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.

react.dev/reference/rules And added to the description

Thanks !! But i already got it from react conference video 😊

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.

Seeing the resulting code, I think both do similar things

Yeah nah. Svelte5 has deep fine grained reactivity, meaning if you change just one property in an object, there is no component updates at all. only exactly where the property is used is updated

@@tomm5765holy shit. That’s actually amazing

1:10 It feels funny when he says all this. He’s talking like this is new tech that hasn’t been used in a framework like svelte. Rich was right from the very start. I remember how the react community criticised Svelte heavily due to its compiler

@@tomm5765If you update a deep property, and that property is used only for some subcomponent, React Compiler will bail out of it just fine. You should try the live playground. If we have to compare to Svelte here, I think it’s worth noting that if a derived computation from two inputs (eg list1.length + list2.length) produces the same results (e.g. list1 increased by one item but list2 decreased by one item), React Compiler would be able to bail out, while Svelte, afaik, would not.

no its not lol

@@nahfamimgood jk

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.

Skill issue

React team: Do not use useEffect for api calls. Me: 🤔🤷‍♂️

The thing with this compiler is now you will actually have to know less about this because some of it should hopefully be automatic and abstracted away.

cursed as fuck lol @@rand0mtv660

The point is you don’t need to know about many of those hooks and don’t even need to add them. The compiler will optimise the code automatically.