I’ve tried to make a very specific point about static shifting from a category of tools to an output mode of server tools (running server request/response model ahead of time). What’s the clickbait there?

Thanks for reminding, that’s a great talk!

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.

> If you think of “server side rendering”, you might be assuming that it requires runtime Node.js hosting (which is usually paid)

Because that is what SSR mean. Not to be confusão with SSG which is the case for your blog.

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.

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.

Thanks!

More concisely: it’s not always the case that prop drilling is possible within a component hierarchy. In a more involved application you store this object in context.

Is what you are describing compatible with this pattern? How does this inform the design of RSCs and as a developer, how can I expect this to affect me?

This depends on how you need to use this object.

One way would be to put it into Client context near the top, then it will be available in Client context below. So if it’s just for the Client stuff, your existing approach works.

For data fetching, a more common approach is not to do any “passing down” at all. Instead, have components that need that data below read that data independently. Slap React.cache around the function that gets the data so that all calls are reused across a single request. Then the first call kicks it off and the other calls will wait for the same Promise under the hood. And you can kick off preloading somewhere up above in the tree if you want to eagerly begin.

That should cover most cases.

To give a concrete example, I’ll probably add some dynamic stuff at some point in the future, like commenting with Bluesky or such. It’s nice not to switch tools for that.

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

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/

I slightly disagree with your nit. I don’t think code fence really demarcates the boundary because the code below the fence definitely does run on the server — otherwise, referencing other Astro components wouldn’t work there. The fence represents the “bindings vs template” separation but not “server vs client” in my reading.

Fair point, you've convinced me on the "bindings vs template" distinction.

However, from a developer's perspective, the ability to securely make backend requests with secrets in the top fenced area and pass results to the template still feels like a clear "server-side execution context" boundary.

Yeah. Not saying it’s the same thing but the conceptual equivalent to this boundary is

import "server-only"

This causes a build error if imported from a client environment. So the intended usage is that you put that into your secrets (and maybe even in your data layer entry point) and you’re golden. It will poison any transitive import that eventually imports that thing.

The developer wouldn’t necessarily “see” where they are at any given moment but importing the “wrong thing” would give them a module stack trace so they can decide where to “make the cut”. It takes a bit to embrace this workflow but it’s productive once you “mark” what’s server-only.

The enforcement of “can’t use state on the client” is built on the same mechanism but inverse (client-only).

I'm hoping someone will do something like that. I try to write with the audience of writers in mind.