4 ms·

Is SEO still the main use case for RSC? Have search engines improved on this front at all the last decade? How does Google 'see' client JS apps these days? Wi

Is SEO still the main use case for RSC? Have search engines improved on this front at all the last decade? How does Google 'see' client JS apps these days? Wild if people start adding one more distributed stateful component to their apps because Search Engines forced them too.

SahAssar 3y ago
I don't know about search engines, but many metadata scrapers do not execute JS so at least for things like open graph (or similar) previews (in chat/twitter/fb etc.) some server rendered html is required.
afavour 3y ago
Performance is, or should be, a reason to use server components. I don’t think SEO is a factor (SSR is relevant there, not server components) Imagine a tree-based navigation component. It’ll render out a series of <a> tags, probably nested inside <ul>s and <li>s. Then the initial page state JS blob will contain the exact same information so that React can, somewhat uselessly, hydrate this tree-based navigation component. So page load is slower because it has to parse the state info then run a load of useless VDOM diffing against an already complete DOM. This has long been an irritation of mine with React. It’s all so unnecessary but React makes it really difficult to have part of your page render statically. At least server components are an attempt to fix that.
- parhamn 3y ago
  > I don’t think SEO is a factor (SSR is relevant there, not server components) Ah, yes thanks for that clarification and your comment.
doytch 3y ago
One of the touted benefits of RSCs is actually colocation of code while avoiding waterfalls. Naively, you can implement a component that fetches some data (eg, post) and renders. Some descendants may also need to fetch data and render it. But now you’re blocking the descendants from rendering until the first fetch completes, so you have a waterfall load that takes unnecessarily long. An alternative has always been to fetch everything at the route/top level. But now it starts to feel a bit strange that your route component needs to know about everything its descendants need. RSCs promise to allow you implement the former pattern which gives better maintainability without the performance hit of a waterfall since the entire render-fetch-data-render back and forth is done on the backend near your data.
- squidsoup 3y ago
  This is a problem nicely solved by graphql fragments - components declare their data dependencies, and the compiler generates a single query.
redbar0n 3y ago
The main use case for RSC is reducing the JS bundle size sent to clients. You can now use npm modules only server side if you want (markdown formatting being a popular example).

SahAssar 3y ago

I don't know about search engines, but many metadata scrapers do not execute JS so at least for things like open graph (or similar) previews (in chat/twitter/fb etc.) some server rendered html is required.

afavour 3y ago

Performance is, or should be, a reason to use server components. I don’t think SEO is a factor (SSR is relevant there, not server components) Imagine a tree-based navigation component. It’ll render out a series of <a> tags, probably nested inside <ul>s and <li>s. Then the initial page state JS blob will contain the exact same information so that React can, somewhat uselessly, hydrate this tree-based navigation component. So page load is slower because it has to parse the state info then run a load of useless VDOM diffing against an already complete DOM. This has long been an irritation of mine with React. It’s all so unnecessary but React makes it really difficult to have part of your page render statically. At least server components are an attempt to fix that.

parhamn 3y ago
> I don’t think SEO is a factor (SSR is relevant there, not server components) Ah, yes thanks for that clarification and your comment.

doytch 3y ago

One of the touted benefits of RSCs is actually colocation of code while avoiding waterfalls. Naively, you can implement a component that fetches some data (eg, post) and renders. Some descendants may also need to fetch data and render it. But now you’re blocking the descendants from rendering until the first fetch completes, so you have a waterfall load that takes unnecessarily long. An alternative has always been to fetch everything at the route/top level. But now it starts to feel a bit strange that your route component needs to know about everything its descendants need. RSCs promise to allow you implement the former pattern which gives better maintainability without the performance hit of a waterfall since the entire render-fetch-data-render back and forth is done on the backend near your data.

squidsoup 3y ago
This is a problem nicely solved by graphql fragments - components declare their data dependencies, and the compiler generates a single query.

redbar0n 3y ago

The main use case for RSC is reducing the JS bundle size sent to clients. You can now use npm modules only server side if you want (markdown formatting being a popular example).