"This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse." [1]
Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking.
My impression from the later responses was that they underestimated how often this particular pattern for parallel loading with React Suspense is used. The people that are slow to embrace the newer patterns would likely not have used Suspense at all, so nothing would have changed for them. This would have affected a specific subset of people that used Suspense for parallel loading, but didn't switch to route loaders.
What are they, in plain terms? Is it just manually hoisting what you know a route needs all the way to the top of the tree? Or is it some compile time magic that analyzes your components used, making the decision for you on what to fetch for a route?
Haven't used them myself yet. As far as I understand it's essentially moving the data loading into the router. The router has an API for the loaders so the rest will work automatically like loading states. So yes, this means you have to define what to load at the top where you define the routes. Though I think this also works with nested routes, but I don't have any experience with them.
> So yes, this means you have to define what to load at the top where you define the routes.
And Meta's way of doing this is with Relay, so you are still defining component data requirements with the components and query fragments, but there's a compile step that produces those route level queries.. so you still get "co-location of a component's data requirements with the component", and "top level early data fetch" for the render-as-you-fetch pattern.
This change breaks the fetch-as-you-render pattern where components make individual data requests for their data, because that pattern is considered bad for performance (for Meta's use case).
It feels like the react team has decoupled from the best interests of the community. Much of the appeal of react was in building the SPA. There are so many web apps that are best built in react on the frontend. Instead we now get this Vercel-driven RSC use-client mess which is of little benefit to the SPA crowd.
The fact that the suspense change made it this far shows how the react team has lost focus. Now more than ever, the ecosystem is really primed for a competing framework to dethrone react. I say this as someone that has invested a lot into using react.
This seems unfair given how the team reverted the change. You can argue they messed up and maybe aren't as in tune to some segment of their user base as they should be, but not that they aren't interested in making the best software they can for everyone.
That's not unfair, the move was clearly to benefit a PaaS provider in detriment of the majority of React users. They are clearly not taking most users need in consideration and they should be judged for that.
If you've worked with React and especially built e-commerce stores with it you'd realize what they are aiming for mimics a lot of the work that went into Relay but for the larger community. This is a continuation of that and not driven by trying to pump Vercel bills.
Kind of discredits all your opinions on that topic
I love Preact, in many ways it's superior to React. But I wonder if their positioning might be weighing them down, that they will always be catching up to stay compatible with React, to implement the same/similar interface. I know "preact/compat" is optional and separate, but there's an expectation that they will keep up with React's new features - even if it doesn't fit well with the design and goals of Preact.
Preact is how I wish React would have evolved: stay small, keep a simple interface, focused on being a view library instead of a sprawling framework.
Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking.
[1] https://github.com/facebook/react/pull/26380