3 ms·

React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React

React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy. My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t. If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.

thrw42A8N 2y ago
The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.
satvikpendem 2y ago
Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.
switz 2y ago
> React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it. Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability. I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites. > There are too many devs out there only expert in the way React does things and can’t step outside of it. This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day. > But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice. For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
- yakshaving_jgt 2y ago
  > Maybe you write isomorphic javascript I’m surprised to see people still misusing the word isomorphic.
  - switz 2y ago
    it's been a term of art for a long time
    - yakshaving_jgt 2y ago
      That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years. More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
      - thrw42A8N 2y ago
        It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.
        yakshaving_jgt 2y ago
        My argument is that it's a forced and silly misuse of the word. I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?
        thrw42A8N 2y ago
        Yeah, that's why everyone switched to "universal" after a year or two. But some people are not as up to date and some libraries kept their old names.

thrw42A8N 2y ago

The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.

satvikpendem 2y ago

Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.

switz 2y ago

> React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it. Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability. I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites. > There are too many devs out there only expert in the way React does things and can’t step outside of it. This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day. > But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice. For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.

yakshaving_jgt 2y ago
> Maybe you write isomorphic javascript I’m surprised to see people still misusing the word isomorphic.
- switz 2y ago
  it's been a term of art for a long time
  - yakshaving_jgt 2y ago
    That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years. More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
    - thrw42A8N 2y ago
      It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.
      - yakshaving_jgt 2y ago
        My argument is that it's a forced and silly misuse of the word. I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?
        thrw42A8N 2y ago
        Yeah, that's why everyone switched to "universal" after a year or two. But some people are not as up to date and some libraries kept their old names.