For anyone curious about live coding a very simple react compiler ("React Compiler Deep Dive"), check out the source + commits/steps here
As
@_gsathya
explained, react's programming model is great for both devs and compilers
I had a blast at (my first)
#reactconf
and learned so much, it was awesome meeting everyone!
(tbt to hanging out with
@_gsathya
before the conf started)
@JSer_ZANP
-memo added by the compiler may increase retained memory, but we try to only memoize values react would already be retaining through Component fiber internals, e.g jsx attributes. Added memo also decreases # of allocations per render, which is likely better for garbage collectors
@Ravicious
@en_JS
React compiler assumes that your code follows rules of react (e.g. pure functions, no writing to props, no dynamic hook calls). Strict mode + react lint rules helps you follow these rules and will help you debug + write better code.
But strict mode is not strictly required
@_mort96_
@t3dotgg
The core logic + program representation is entirely separate from babel. Eventually, we hope to have the compiler written in rust, then write small adapter pieces for babel/swc/esbuild.
If you’re interested, please check out these docs!
@bcheidemann
@potetotes
- we’ve found that some dynamic / interactive pages need a few rendering passes before “visual completion”, which is a similar metric to LCP. This is where the initial load + nav wins came from — minimizing the cost of these rerenders
@bcheidemann
@potetotes
Internally, we’ve seen that we typically get faster initial load / nav wins from compiler optimized code:
- we have a lot of non-product + react code we send to the client (e.g data libraries, design components), so regression in react codesize showed up less than we expected
@bcheidemann
@potetotes
Thanks for engaging with us here. We don’t have an explicit go-ahead from legal yet, but I hope we can get permission to share more numbers.
I totally understand being skeptical with regards to codesize though —
@JSer_ZANP
3. We have some theories on this, but didn’t get to spend a lot of time digging:
- the mentioned apps already have a sizable memory footprint, so a few new arrays won’t show much. it’s also worth noting that compiler output is much more efficientthan useMemo (no functions)
@jimmycallin
@acdlite
We’re currently not planning to support a small set of syntax (eg class components/this, side-effectful getters) as their dataflow + alias sets are intractable to compute. This will also apply to new language features.
This hasn’t affected our use of the compiler internally tho
@JSer_ZANP
2. So the metric we rely on internally is not first paint, but “visual completion” which measures how long it takes to load visible / viewport content.
We did find that bundle size regressed slightly, but was overshadowed by how much time we were able to save on initial renders
@JSer_ZANP
great questions, thanks for asking!
1. We measured between the interaction until the “last” react render. Optimized code caused fewer elements to re-render when a component high up in the tree invalidates. If you’re curious, we shared a flamegraph @ ReactAdvanced 2023
@iammerrick
depends on your definition of optimized. the compiler won't always add memoization because in some cases the component / hook simply doesn't need any.
this is the number of react fns *compiled*, but might be higher than the # that it added memo to