4 ms·

Hmm, not sure what the hype is about. This still does not solve a lot of my problems with React. You still need the base ~97.5kb react runtime to render a "serv

Hmm, not sure what the hype is about. This still does not solve a lot of my problems with React. You still need the base ~97.5kb react runtime to render a "server component". And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Seems odd that they haven't worked out how this works for routing yet (https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606ffaf5e650f1284f07/text/0000-server-components.md#how-do-you-do-routing https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...) and that in the demo the whole app is rendered, not individual components. Just seems like turbolinks but for rendering to React VDOM rather than HTML. And I thought most people used React for CSR through hosting files on static buckets leaving out the server...?

mekkkkkk 6y ago
CSR-only apps quickly run into issues when it comes to SEO and initial page load speeds. For reasonably static content it can be solved by snapshotting the routes and serving the snapshots from the CDN. If you have more dynamic content you are forced to SSR, and this is where this feature comes in.
danabramov 6y ago
One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependencies, the fixed cost of React is offset by all the product and other third party library code. You might think it's not a problem for small/hobby apps, but those often fail to track their bundle size, so they also have perf problems. So we want to change the shape of the curve instead of just "making React smaller". If React itself is really your bottleneck, use Preact. >And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Keep in mind that you can shift things between Client and Server very fluidly. That's very much the point of the proposal. If you refetch something twenty times over a small period, it might be a good candidate to move to the Client. On the other hand, on most navigations you have to fetch anyway (to get data), and so you might as well do a bunch of CPU work on the server and avoid sending abstraction bloat down. One part that's missing from the current demo is granular refetching. That's going to be an important piece (including for routing). So that the refetch happens for partial subtrees and not always from the top. We have a rough idea for how it should work but it's still on the TODO list (as many other things we mentioned as ongoing research).
- kaleidawave 6y ago
  Cool thanks for clarifying. I appreciate the work being done to utilise the benefits of using the server for rendering. It might be worth mentioning the payload inflection point in the drawbacks on the RFC. Looking forward to where this goes!

mekkkkkk 6y ago

CSR-only apps quickly run into issues when it comes to SEO and initial page load speeds. For reasonably static content it can be solved by snapshotting the routes and serving the snapshots from the CDN. If you have more dynamic content you are forced to SSR, and this is where this feature comes in.

danabramov 6y ago

One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependencies, the fixed cost of React is offset by all the product and other third party library code. You might think it's not a problem for small/hobby apps, but those often fail to track their bundle size, so they also have perf problems. So we want to change the shape of the curve instead of just "making React smaller". If React itself is really your bottleneck, use Preact. >And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Keep in mind that you can shift things between Client and Server very fluidly. That's very much the point of the proposal. If you refetch something twenty times over a small period, it might be a good candidate to move to the Client. On the other hand, on most navigations you have to fetch anyway (to get data), and so you might as well do a bunch of CPU work on the server and avoid sending abstraction bloat down. One part that's missing from the current demo is granular refetching. That's going to be an important piece (including for routing). So that the refetch happens for partial subtrees and not always from the top. We have a rough idea for how it should work but it's still on the TODO list (as many other things we mentioned as ongoing research).

kaleidawave 6y ago
Cool thanks for clarifying. I appreciate the work being done to utilise the benefits of using the server for rendering. It might be worth mentioning the payload inflection point in the drawbacks on the RFC. Looking forward to where this goes!