5 ms·

Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. This has nothing

Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. This has nothing to do with RSC, and @dang /moderators should probably change the headline. "Moving from a client-side app to a server app (using React Server Components) made our site faster" is very unsurprising, not very interesting (what would be interesting is comparison from another server rendering technique), and wouldn't have made the HN homepage likely, but they've already cheesed their way here.

throwaway10965 3y ago
I don't see the difference between their and your headline.
- nwienert 3y ago
  Because they could have moved to a server based app not using RSC and seen similar gains, so the deception is they are trying to make it seem like RSC caused the gain (and riding on the back of a hyped new technology) whereas it's not really the case.
  - madjam002 3y ago
    But RSC is how you do server based apps with React, and they’re clearly sticking with React. Sure you can render to static markup without RSC but then you have to do a lot of work to mix server/interactive client components, RSC makes it a lot easier to achieve “server based apps”. It’s not a deceptive headline at all.
    - nwienert 3y ago
      I think it’s less work to just use static content in places and avoid having to learn a whole new model of rendering, routing, data fetching and a lot of rules than it is to have a traditional ssr app that compiles a few static pieces of content.
  - ricardobeat 3y ago
    RSC is how React figured out partial hydration. Before this, you would simply not move to a server-rendered app, as it was not worth it - the client bundle would stay the same and you're just increasing overhead.
    - nwienert 3y ago
      Not true in the slightest. A server rendered app would deliver your html up front so your app is completely rendered immediately, this has been common for many years now and improves performance quite a bit. Couple with sending some static parts that avoid JS which is quite doable you have 90 some % of the benefit in a simpler model. That’s also why more direct a comparison of a SSR app to a RSC app is interesting. Partial hydration is great but it’s a shame React is coupling it to a whole new routing model, component model, server rendering, and with such complex rules on use and inherent waterfalls as a side effect. There’s no reason to. You can get partial hydration any number of ways and avoid all the complexity.
      - ricardobeat 3y ago
        > Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' for the majority of React apps; they are usually monolithic and built on top of frameworks that make it difficult. Not impossible (we were doing this back in 2016 with different tech), but very uncommon. As I said above, this is exactly what RSC is solving for. It's not a new thing, but the first solution endorsed by React itself, and enabled them (and potentially all React apps) to gain SSR with partial hydration, reduce bundle sizes and actually improve load performance. I'm not a big fan of any of this, just stating what it is. And I agree that it introduces monstrous complexity to an ecosystem that's already overflowing with it. Astro for example achieves this without introducing too many new concepts.
        3y ago
deleted 3y ago
[deleted]
willio58 3y ago
I think their headline makes total sense. It's true after all, turns out putting most of the work on your server rather than your client is a great idea for performance. You seem to be taking personal offense to using React Server Components for this, which is odd to me.
- nwienert 3y ago
  You do know you can move to the server without RSC? This misconception is exactly what I'm talking about.
eyelidlessness 3y ago
This is a weird take, given that RSC is generally positioned for this kind of conversion. Among others, sure, but this is definitely one. It’s not deceptive to write about using a tool for one of its explicit intended purposes.
- nwienert 3y ago
  See this: https://news.ycombinator.com/item?id=37608452 https://news.ycombinator.com/item?id=37608452
  - eyelidlessness 3y ago
    It seems as though you’re reading this article—and apparently others on the topic—as some form of attention metric gaming combat. I think the author just, uh… wrote an article about their experience with adopting a technology. You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may offer some advice, for whatever it’s worth: there’s going to be a very long tail of people coming to this, or any similar, solution with less depth of knowledge and nuance, and it might be a more enjoyable reading experience to preemptively give them some grace on that.
    - nwienert 3y ago
      I feel like my comments are fine and curious who you think I'm not giving grace to, I'm not attacking anyone except the article framing itself. My only ask was that HN, which usually clarifies titles to be more accurate avoid extra hype, apply that here, as the company obviously profits at the expense of the uninformed with the title here. If anything I'm helping people less experienced understand this. HN does this title clarification all the time for much less concrete things. I'd ask you why you felt necessary to bring in the "weird" adjective when clearly you understand this area and exactly how the less informed may not understand those graphs and title - in this very thread many of people even seem totally confused that RSC = the only way to do server rendering = novel to React. If I can give you feedback as well, instead of trying to score a point and muddy waters, just write the improved version of what I'm saying if you feel capable of doing so.

throwaway10965 3y ago

I don't see the difference between their and your headline.

nwienert 3y ago
Because they could have moved to a server based app not using RSC and seen similar gains, so the deception is they are trying to make it seem like RSC caused the gain (and riding on the back of a hyped new technology) whereas it's not really the case.
- madjam002 3y ago
  But RSC is how you do server based apps with React, and they’re clearly sticking with React. Sure you can render to static markup without RSC but then you have to do a lot of work to mix server/interactive client components, RSC makes it a lot easier to achieve “server based apps”. It’s not a deceptive headline at all.
  - nwienert 3y ago
    I think it’s less work to just use static content in places and avoid having to learn a whole new model of rendering, routing, data fetching and a lot of rules than it is to have a traditional ssr app that compiles a few static pieces of content.
- ricardobeat 3y ago
  RSC is how React figured out partial hydration. Before this, you would simply not move to a server-rendered app, as it was not worth it - the client bundle would stay the same and you're just increasing overhead.
  - nwienert 3y ago
    Not true in the slightest. A server rendered app would deliver your html up front so your app is completely rendered immediately, this has been common for many years now and improves performance quite a bit. Couple with sending some static parts that avoid JS which is quite doable you have 90 some % of the benefit in a simpler model. That’s also why more direct a comparison of a SSR app to a RSC app is interesting. Partial hydration is great but it’s a shame React is coupling it to a whole new routing model, component model, server rendering, and with such complex rules on use and inherent waterfalls as a side effect. There’s no reason to. You can get partial hydration any number of ways and avoid all the complexity.
    - ricardobeat 3y ago
      > Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' for the majority of React apps; they are usually monolithic and built on top of frameworks that make it difficult. Not impossible (we were doing this back in 2016 with different tech), but very uncommon. As I said above, this is exactly what RSC is solving for. It's not a new thing, but the first solution endorsed by React itself, and enabled them (and potentially all React apps) to gain SSR with partial hydration, reduce bundle sizes and actually improve load performance. I'm not a big fan of any of this, just stating what it is. And I agree that it introduces monstrous complexity to an ecosystem that's already overflowing with it. Astro for example achieves this without introducing too many new concepts.
      - 3y ago

deleted 3y ago

[deleted]

willio58 3y ago

I think their headline makes total sense. It's true after all, turns out putting most of the work on your server rather than your client is a great idea for performance. You seem to be taking personal offense to using React Server Components for this, which is odd to me.

nwienert 3y ago
You do know you can move to the server without RSC? This misconception is exactly what I'm talking about.

eyelidlessness 3y ago

This is a weird take, given that RSC is generally positioned for this kind of conversion. Among others, sure, but this is definitely one. It’s not deceptive to write about using a tool for one of its explicit intended purposes.

nwienert 3y ago
See this: https://news.ycombinator.com/item?id=37608452 https://news.ycombinator.com/item?id=37608452
- eyelidlessness 3y ago
  It seems as though you’re reading this article—and apparently others on the topic—as some form of attention metric gaming combat. I think the author just, uh… wrote an article about their experience with adopting a technology. You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may offer some advice, for whatever it’s worth: there’s going to be a very long tail of people coming to this, or any similar, solution with less depth of knowledge and nuance, and it might be a more enjoyable reading experience to preemptively give them some grace on that.
  - nwienert 3y ago
    I feel like my comments are fine and curious who you think I'm not giving grace to, I'm not attacking anyone except the article framing itself. My only ask was that HN, which usually clarifies titles to be more accurate avoid extra hype, apply that here, as the company obviously profits at the expense of the uninformed with the title here. If anything I'm helping people less experienced understand this. HN does this title clarification all the time for much less concrete things. I'd ask you why you felt necessary to bring in the "weird" adjective when clearly you understand this area and exactly how the less informed may not understand those graphs and title - in this very thread many of people even seem totally confused that RSC = the only way to do server rendering = novel to React. If I can give you feedback as well, instead of trying to score a point and muddy waters, just write the improved version of what I'm saying if you feel capable of doing so.