Add a section about the principle behind React Compiler
I think it's good to say this explicitly. Lifted it from https://github.com/reactjs/react.dev/pull/8071.
Also driveby style nit
Size changes
📦 Next.js Bundle Analysis for react-dev
This analysis was generated by the Next.js Bundle Analysis action. 🤖
This PR introduced no changes to the JavaScript bundle! 🙌
Yea I hear you. I think it still makes sense as a higher-level explanation for the "big idea" since the rest is about finding boundaries of which things are actually pure. JSX is an obvious such boundary but you can get more granular (and that's what most of the work in the Compiler is actually about).
My higher-level point is we probably shouldn't let the implementation challenges (and empathy for the work that went into it) obscure the big idea. The big idea absolutely relies on some pieces of code being safe to reorder and/or to "replay" with their outputs. The rest is about how to make that work in JS.
I think it's the kind of simplification that is slightly wrong, but if you know why it's wrong, you're already not the target audience because you understand the nuance it skipped. Whereas if you don't know why it's "wrong", this simplification is more truthful than your initial understanding (which is that this is a bunch of adhoc magic).
Maybe there's some way to skip to the end and convey a fully accurate picture right away though.
Maybe:
Fundamentally, React Compiler relies on an old idea from functional programming: pure functions don't "do" anything (they only compute things), so it is safe to reorder their calls, or to reuse their past output for the same inputs. React Compiler checks that your components follow the Rules of React, and breaks up their code into smaller pieces that can be reused and reordered this way.
Hmm. I think about it as: React depends on ideas from functional programming. Components and hooks must already be written as pure for the programming model to work and retain local reasoning (it’s only safe to mutate props, hook args, or hook return values if you can make assumptions about how they’ll be used, which breaks composition). The compiler just builds on this idea to help bound the mutability.
I’d like to get this point across in some form, and build the intuition around how we decide what to memoize.
We also don’t do reordering (yet).
How about:
You can get an intuitive sense of how the Compiler works by looking at the playground.
Like many features in React itself, React Compiler relies on an old idea from functional programming: pure functions don't "do" anything (they only compute things), so it is safe to reorder their calls, or to reuse their past output for the same inputs. React Compiler verifies that your components follow the Rules of React, and then breaks up their code into smaller pure pieces that can be safely skipped or potentially reordered.
Since it does change the execution flow with skipping, I sort of think about it as reordering. Though I see it's not exactly the same. I think it helps build the intuition though if you start with a stronger guarantee.
updated with new wording. alternatively, https://github.com/reactjs/react.dev/pull/8074 is a revert