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.

I think this was pretty good at explaining the impact:

https://www.youtube.com/watch?v=zqhE-CepH2g

Convinced me to start new project with React just because of the RSCs.

> 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.

Not sure what you mean — we’re just reading some files from the disk and passing that down. It doesn’t need Suspense because everything is static (so no loading indicators are needed). If this was dynamic then I’d probably still not add a loading indicator because you expect a blog index to “pop in” with the rest of the page rather than behind a spinner.

Most servers will natively use caching policies for serving static content as well.

Point taken, but I more or less consider this “static”. The distinction is artificial (of course there’s always a server behind the scenes), the question is just which server you’re programming against in the abstraction stack of the majority of your program. Hybrid approach often includes “incremental regeneration”, i.e. partial builds on-demand with caching. So that fits very well there. But it’s an implementation detail. The programming model you’re writing against can just use an “invalidate” function without concerning itself with the outer “actual server” layer.

It's because inevitably there comes a time where you want some pages (or even sub-pages) to be static, and other pages (or parts) of your application to be dynamic. If the question is "why" the inverse is "why not"?

Dan's blog is rendered as static, works without javascript and still lets him write complex client-side components when he calls for it. And if one day he decides to add a page that renders content dynamically, he can do so in the same patterns and framework that he's already using.

The goal is developer-choice. No need to pick static or dynamic holistically, have access to both when you need them. No need to pick between hydrating the entire website vs. rendering exclusively on the server. No need to pick between writing client-side amenable code or server-only code.

How many platforms have a "marketing" website for / and a platform website for /dashboard? No need to split them, just use a framework that accommodates both seamlessly. It's more powerful, even though it does come with a learning curve.

Nowadays it’s common for things to not be entirely static but kind of a mix. Some interactive client stuff, some dynamic server stuff. It’s nice to stay within the same programming model for these.

React might sound like a weird choice to you but its composition model including server and static stuff is quite powerful. See here for a slightly contrived but representative example: https://overreacted.io/impossible-components/#a-sortable-lis...

Although I don't usually use react, for me, there is a certain joy and also efficiency that comes from using some of the abstractions that you got from the larger JavaScript/web ecosystem while also having the ability render all that magic to a folder with a couple of HTML, CSS and JavaScript files.

With LLMs to help wrestle the boilerplate, I've found I can whip up a fast static site using advanced ergonomic abstractions that make the whole process a joy! In the past, wrestling the Node and NPM ecosystem was a a complete nightmare. Now it's, a dream — with the occasional storm cloud.

Mainly because they all discovered that fully dynamic client-side SPAs written in 100% JS are extremely slow, and wanted a way to speed them up whilst keeping most of the developer experience of an SPA.

That's it. It's not a clever way to arrive at the conclusion that the server is useful, but they got there in the end.

As someone who uses Astro a lot for (mostly) static pages, the two standout features of this approach that come to my mind are code sharing and the ease of integrating SSR/CSR where needed.

Components (be it Astro, Svelte, React, etc.) have a lovely API for sharing code across web pages. I used Hugo before and hit the limits of shortcodes pretty quickly. I can't comment on Jekyll though.

Furthermore, if the need for some dynamically rendered pages or client-side interactivity comes up, it is very easy to integrate this later on. I can build static, server-rendered and client-rendered pages (and everything in between) with the same set of tools, which means less mental load when I develop.

Because it's an easy and widely used framework to write JavaScript components that react to changes in state

Because most mainstream frameworks are too bloated to handle more than a few hundred rps on a normal server, and caching has gone out of fashion (?), so it's the best way to save money.

All of this makes very little sense, but every couple years a guru will shout new commandments from his social media mountaintop and reshape the landscape. It's more of a religious ritual at this point, really.

On a more serious note, it's also because the market is saturated with developers who specialize on React, and this is what's easy and makes sense to reuse their knowledge and code (vs say, setting up a caching reverse proxy and dealing with invalidation).

Jekyll is fine. So is React. And Astro. Some folks like different things than others.

this post describes not really running RSC on the server, but instead running it on the developer's laptop, taking the resulting HTML, and pushing that to a server. the more common use case of RSC is where it is actually being run server-side as requests come in, perhaps behind a cache, not baking everything down into a static bundle once

If you think of “server side rendering”, you might be assuming that it requires runtime Node.js hosting (which is usually paid). But that’s not the case — my blog is statically generated during deployment. Like Jekyll. So the point of the post is to show why it’s not a contradiction. In modern tools, “static” is often an output mode of “server” frameworks rather than a separate category of tools.

Are you confused about Astro? It follows the same model.