<p><pre><code> > I guess you could say this is a point in favor of Next.js because at least they’re reaping the benefits of closer collaboration with React. But in my experience, a team not being collaborative is a bad sign for their software.
</code></pre>
There is something actually kind of unique about React's fundamental design at this point that separates it from every other major framework: it kind of "inverts" the model of reactivity[0] that we typically encounter in UI applications (not just web frameworks, here). I first came across this thought after reading Arek Nawo's[0] comparison of React Hooks to Vue Composition.<p>It seems to me that this is actually a big source of the issues with React from the complicated state management libraries and models to the need to double render in strict mode (to flush out where developers have put state incorrectly).<p>I bring this up because in Feb 2023 -- two plus years ago -- a Tweet caught my attention at the time. Andrew Clark had posted (2023FEB18):<p><pre><code> > We might add a signals-like primitive to React but I don’t think it’s a great way to write UI code. It’s great for performance. But I prefer React’s model where you pretend the whole thing is recreated every time. Our plan is to use a compiler to achieve comparable performance.
</code></pre>
There's an acknowledgement that <i>"yeah, it's great for performance, but we don't care"</i>. Now, two years later, the compiler is still in beta and there's no evidence that it actually improved performance at all. There's just a certain arrogance from this team that makes it very hard to root for.<p>[0] <a href="https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react" rel="nofollow">https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...</a><p>[1] <a href="https://areknawo.com/vue-composition-api-vs-react-hooks-the-core-difference/" rel="nofollow">https://areknawo.com/vue-composition-api-vs-react-hooks-the-...</a>