Comment by switz

2 months ago

It's unfortunate that there is so much misinformation about what react server components really are, but it's not necessarily the fault of either party. The name is confusing (names are hard), the architecture is new (people don't want to learn it), and it lends itself to conspiracy theories (that aren't true).

But it really is a magnificent piece of technology. Because they're called "Server Components" people think that "server" means run-time, but as a friend pointed out, 15 years ago people were running wordpress servers and caching pages ahead-of-time. As Dan mentions here: "server" doesn't imply it has to execute at run-time.

But there are also massive advantages to running a server at run-time that seem lost on people. I do think over time the concepts behind RSCs will filter out into most web frameworks because they are so powerful. It's the best functionality of the old-world SSR languages (PHP, rails) combined with the best functionality of the new-world client frameworks (React). You get to pick and choose when to lean on either, and they work together through composition.

I wish people were a bit more patient and spent a bit more time trying to understand these concepts before bashing them. Part of that is the fault of names, communication, and lack of documentation. But the underlying technology is rigid and strong. It's here to stay, even if it arrives in other forms.

I think it’s fair to say that a lot of the negative reception was also due to

1) No easy way to try outside a framework (now there is with Parcel RSC, but eventual first-class support in Vite will likely be the real tipping point).

2) Poor developer experience in the only official integration (Next.js). Both due to build performance problems (which Turbopack helps with but it still hasn’t fully shipped), due to bad error messages (massively improved recently), and due to confusing overly aggressive caching (being reworked to much more intuitive now but the rework won’t ship for some time yet).

Time will tell but I’m optimistic that as there are more places to try them, and the integrations are higher-quality, people will see their strong sides too.

  • Thanks for pointing out Parcel RSC. I just read through the docs and they do a great job of explaining RSCs from a place I can understand. In contrast to NextJS where it’s unclear where the framework stops

    https://parceljs.org/recipes/rsc/

    • "unclear where the framework stops" is a great way to phrase that issue. It's something I've run into with NextJS in a few contexts.

      I really appreciate when frameworks leverage standards and/or indicate the boundaries of the framework as much as possible.

  • I'll add to the confusing caching: Next deciding to monkey patch fetch() to add their caching, and Next relying on a React Canary version left in some (surely in me) a taste that RSC were half baked, which is weird since they've been around for like, five years?

> It's the best functionality of the old-world SSR languages (PHP, rails) combined with the best functionality of the new-world client frameworks (React).

And one of my pet peeves is people seeing the former and dismissing it as "everything old is new again" without considering the gains we've made in the meantime with the latter.

> I do think over time the concepts behind RSCs will filter out into most web frameworks because they are so powerful

I don't think that is true. React had one great feature that gives it its name: reactivity. People kept using it despite the bad abstractions added later like hooks, graphql and now RSC. The difference is that now react fatigue is way bigger than the hype, nobody loses a job by stating that RSC is terrible.

Too many devs rely on a single tool to try to do everything, at the cost of complexity. The amount of knowledge you need to use any Javascript framework is IMO, insane, let alone try to keep up with the latest and greatest.

The enshittification of the web partly is shipping giant JS bundles for no reason. (Developer needs > Consumer)