4 ms·

It seems every few years we keep jumping between client side and server side rendering. How is this better than strictly client or server side? It seems like it

It seems every few years we keep jumping between client side and server side rendering. How is this better than strictly client or server side? It seems like it just has the disadvantages of both with additional complexity to maintain an application now coupled to both your back and front ends. Presumably if your react app could be more performant with server-side rendering it would be better to simply use traditional server side rendering and sprinkle JS, and if it's really a "web app" I'm not sure how substantially faster react server components will be in practice. EDIT: I read the FAQ and some of the answers seem to need clarification: > Doesn’t always re-fetching the UI make interactions slow? The answer to this isn't really definitive. > What are the performance benefits of Server Components? The answer to this makes it sound server components make fewer requests than client, but in the context of GraphQL which is mentioned in the answer, the total amount of requests should be the same. If anything wouldn't a regular react app be more responsive?

city41 6y ago
One of the problems with server side rendered React is hydration. Even a 100% static website built with Gatsby will download a bunch of JS just to hydrate components that end up doing nothing. There have been some coarse workarounds for this such as gatsby-plugin-no-javascript for Gatsby and `unstable_runtimeJs: false` in Next. But those both operate at the entire page level. React server side components feels like it's taking those coarse solutions and making them more fine grained and less hacky. But my entire exposure to them is the video they just released, so who really knows at this point.
sophiebits 6y ago
This lets you choose on a per-component basis. The way I think about it: in most apps there are a lot of components that only rerender when there is new data from the server. Those components can be run on the server without losing any interactivity. Especially if a component has highly branching logic, this reduces the amount that has to be sent to the client by a large margin. The programming model is very similar and it’s possible to make one component that works on both server and client simultaneously, which means you’re not locked in if you want to move a server component back to the client later.

city41 6y ago

One of the problems with server side rendered React is hydration. Even a 100% static website built with Gatsby will download a bunch of JS just to hydrate components that end up doing nothing. There have been some coarse workarounds for this such as gatsby-plugin-no-javascript for Gatsby and `unstable_runtimeJs: false` in Next. But those both operate at the entire page level. React server side components feels like it's taking those coarse solutions and making them more fine grained and less hacky. But my entire exposure to them is the video they just released, so who really knows at this point.

sophiebits 6y ago

This lets you choose on a per-component basis. The way I think about it: in most apps there are a lot of components that only rerender when there is new data from the server. Those components can be run on the server without losing any interactivity. Especially if a component has highly branching logic, this reduces the amount that has to be sent to the client by a large margin. The programming model is very similar and it’s possible to make one component that works on both server and client simultaneously, which means you’re not locked in if you want to move a server component back to the client later.