7 ms·

"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

"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. [1] https://github.com/facebook/react/pull/26380 https://github.com/facebook/react/pull/26380

fabian2k 2y ago
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.
- diob 2y ago
  I hadn't heard of route loaders till all this. 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?
  - fabian2k 2y ago
    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.
    - marcins 2y ago
      > 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).
  - svieira 2y ago
    It's either/both - the "simple" method is to manually host. The more complex methods use runtime or compile-time reflection on the code to determine what gets loaded when (a la https://engineering.fb.com/2020/05/08/web/facebook-redesign/#:~:text=Delivering%20data%2Ddriven%20dependencies https://engineering.fb.com/2020/05/08/web/facebook-redesign/...)
  - eddd-ddde 2y ago
    I'm familiar with route loaders from Qwik, I imagine they are similar. Essentially data fetching starts as soon as possible. Right after routing, right before rendering.
Zenzero 2y ago
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.
- deleted 2y ago
  [deleted]
- pkilgore 2y ago
  Preact is a delight an contains non of this nonsense (yet).
  - lioeters 2y ago
    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.
- hoten 2y ago
  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.
  - meiraleal 2y ago
    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.

fabian2k 2y ago

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.

diob 2y ago
I hadn't heard of route loaders till all this. 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?
- fabian2k 2y ago
  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.
  - marcins 2y ago
    > 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).
- svieira 2y ago
  It's either/both - the "simple" method is to manually host. The more complex methods use runtime or compile-time reflection on the code to determine what gets loaded when (a la https://engineering.fb.com/2020/05/08/web/facebook-redesign/#:~:text=Delivering%20data%2Ddriven%20dependencies https://engineering.fb.com/2020/05/08/web/facebook-redesign/...)
- eddd-ddde 2y ago
  I'm familiar with route loaders from Qwik, I imagine they are similar. Essentially data fetching starts as soon as possible. Right after routing, right before rendering.

Zenzero 2y ago

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.

deleted 2y ago
[deleted]
pkilgore 2y ago
Preact is a delight an contains non of this nonsense (yet).
- lioeters 2y ago
  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.
hoten 2y ago
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.
- meiraleal 2y ago
  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.