No, but it's primarily because Meta has their own server infrastructure already. RSCs are essentially the React team trying to generalize the data fetching patterns from Meta's infrastructure into React itself so they can be used more broadly.
I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-external perspective:
Like I said above and in the post: it was an attempt to generalize the data fetching patterns developed inside of Meta and make them available to all React devs.
If you watch the various talks and articles done by the React team for the last 8 years, the general themes are around trying to improve page loading and data fetching experience.
Former React team member Dan Abramov did a whole series of posts earlier this year with differently-focused explanations of how to grok RSCs: "customizable Backend for Frontend", "avoiding unnecessary roundtrips", etc:
Conceptually, the one-liner Dan came up with that I liked is "extending React's component model to the server". It's still parent components passing props to child components, "just" spread across multiple computers.
Yeah the "just" is doing a lot of things, nobody asked for a react server but it turns out it could be the base for a $10B cloud company. Classical open source rugpull.
Replay is really impressive - having a record/replay runtime that can capture all the inputs to the JS engine and reproduce execution deterministically is in a completely different category from what CDP exposes. That’s what enables true time-travel debugging.
Wirebrowser sits at the other end of the spectrum: it attaches to any unmodified browser that supports CDP and works directly with the live runtime. The workflows end up being very different, but it’s fascinating to see what becomes possible when the runtime itself participates in the recording.
Don't think Archive links work on Substack or other similar sites like Ed's, and this link stops at the paywall cutoff (ie just the free content portion).
Hi. I'm the current Redux maintainer, and have been since Dan handed it over to me in mid-2016, one year after he created Redux. It's also worth noting that Dan never used Redux on a real app (that I know of), whereas I've spent years maintaining Redux and Redux Toolkit and designing APIs based on the needs of our users.
Redux is still by far the most widely-used state management library in React apps. Some of that _is_ legacy usage, sure. But, our modern Redux Toolkit package has ~30M downloads a month. Zustand has become very popular as a client-side state option, and React Query is now the default standard data fetching tool, but you can see that even just RTK is still right up there in monthly NPM downloads:
I've frequently talked about the original reasons for Redux's creation, which of those are still relevant, and why Redux is still a very valid option to choose even for greenfield projects today:
Because that's the responsibility we've placed on ourselves :)
I actually did a recent conference talk called "Maintaining a Library and a Community" where I discussed how being an OSS maintainer is really about communicating with your users and contributors, more than it is about writing code yourself. And yes, a big part of that is responding to issues _and_ reviewing externally-contributed PRs:
I also even just tweeted over the weekend about how a user filed a PR to add a good new option to one of my libraries, but I still had to take time to review it, figure out what additional functionality should be added, then add tests and docs:
What "naming conventions and file structures" are you referring to? I don't think Dan ever really popularized anything like that for _React_.
If you're thinking of _Redux_, are you referring to the early conventions of "folder-by-type" file structures? ie `actions/todos.js`, `reducers/todos.js`, `constants/todos.js`? If so, there's perfectly understandable reasons why we ended up there:
- as programmers we try to "keep code of different kinds in different files", so you'd separate action creator definitions from reducer logic
- but we want to have consistency and avoid accidental typos, especially in untyped plain JS, so you'd extract the string constants like `const ADD_TODO = "ADD_TODO"` into their own file for reuse in both places
To be clear that was never a requirement for using Redux, although the docs did show that pattern. We eventually concluded that the "folder-by-feature" approach was better:
which is what we later turned into "Redux slices", a single file with a `createSlice` call that has your reducer logic and generates the action creators for you:
Read it earlier this year and it definitely changed some of my thinking along those same lines.
My loose summary of the book:
"Any money left in the bank when you die is essentially wasted - you could have used it to have experiences when you were alive, or given it to family / charity earlier when it would have had more benefit. Figure out what major experiences and memories you want to have in life, plan to do them earlier when you have health and time, and build up memories for later in life."
I didn't find the discussions of how to plan out retirement savings very useful - there's a lot better info on withdrawal approaches in various FIRE-related groups.
But the "be willing to spend now on activities you might not be able to do later / don't hold off on 'living' until you're retired" argument made a _lot_ of sense to me for a variety of reasons, and it was a major factor in researching early retirement a few months later (and deciding to make that a new goal. along with taking more vacations before then).
React's bundling system and published packages has gotten noticeably more complicated over time.
First, there's the separation between the generic cross-platform `react` package, and the platform-specific reconcilers like `react-dom` and `react-native. All the actual "React" logic is built into the reconciler packages (ie, each contains a complete copy of the actual `react-reconciler` package + all the platform-specific handling). So, bundle size has to measure both `react` and `react-dom` together.
Then, the contents of `react-dom` have changed over time. In React 18 they shifted the main entry point to be `react-dom/client`, which then ends up importing the right dev/prod artifacts (with `react-dom` still supported but deprecated):
Then, in React 19, they restructured it further so that `react-dom` really only has a few utils, and all the logic is truly in the `react-dom/client` entry point:
So yes, the full prod bundle size is something like 60K min+gz, but it takes some work to see that. I don't think Bundlephobia handles it right at all - it's just automatically reading the main entry points for each package (and thus doesn't import `react-dom/client`. You can specify that with BundleJS though:
Hi! I maintain Redux and am deeply involved in the React community, and have spent a lot of time both critiquing the React team's decisions and explaining their decisions to the community.
I actually wrote exactly that blog post and did a conf talk on it earlier this year. I covered why the React team switched to directing users to use "frameworks" to build React apps, the development influences behind React Server Components, why the React docs didn't list tools like Vite as viable options until just a couple months ago, and various other related topics:
I wrote an extensive post and did a conference talk earlier this year recapping the overall development history and intent of RSCs, as best as I understand it from a mostly-external perspective:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
- https://blog.isquaredsoftware.com/2025/06/presentations-reac...
reply