This is also how I build most of my static sites, usually deployed to GitHub Pages. For example, here’s the demo page for a library I recently developed: https://exogen.github.io/turbo-colormap/
Or a more complicated app: https://exogen.github.io/t2-model-skinner/
Are all of Next.js’ features overkill for such sites? Sure, but the convenience such frameworks provide is worth it. And the reason to prefer it over something like Vite is simply routing, which Vite doesn’t cover out of the box, so as soon as I want to add a second page, I now have another problem to solve.
Next.js’ best feature is simply that you’re up and running with `npm i react react-dom next` and step two is just writing the pages.
I'm curious if Next has full support for Cloudflare or if this is the only way to run Next w/RSC off of Vercel.
I understand that somebody might want to generate static pages from code that generates it dynamically, but I fail to appreciate _why_. Are people using this for a handful of pages they want to load quickly and whose contents rarely change, or are people building entire static sites using things like React? If it's the latter... uh... why? It's been awhile since I was a web developer, so maybe my pain threshold is inappropriately low. I think Jekyll is fine and use it pretty regularly.
Next.js as a SSG is nice because TypeScript + React is nice for templating and arbitrary logic, and those are the tools you're probably already using.
You write your site as if it were a dynamic server, and out comes a static website.
Jekyll is fine, but it's built in Ruby and it's far less dynamic.
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.
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.
I think the reason to split the marketing page from the dashboard one is that you can deploy one without the other. I would actually prefer to have all the marketing stuff in its own repo away from any dashboard code.
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 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).
I’m actually quite excited for caching to make a comeback: https://overreacted.io/functional-html/#caching
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...
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.
Because it's an easy and widely used framework to write JavaScript components that react to changes in state
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.
Jekyll is fine. So is React. And Astro. Some folks like different things than others.
I wonder if the omission of React Context in this example is intentional. Do you think Context is compatible with suspense? In the sense that posts is being passed to components as props three times over.
Is it because each component is expected to abstract over async, relying on the promise state?
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.
This got popular in JS toolkits a few years ago, at least. For instance, Svelte(kit) also has a static output variant.
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
"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.
> 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 remember meteor.js!
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.
Thanks for reminding, that’s a great talk!
> 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.
If you put a cache around all GET API handler, you're faster than static.
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.
Most servers will natively use caching policies for serving static content as well.
I am having trouble understanding this article's premise:
```
RSC means React Server Components.
And yet, although this blog is built with RSC, it is statically served from a Cloudflare CDN using their free static hosting plan. It costs me exactly zero.
Zero.
How is this possible?
Aren’t these React Server Components?
```
Why is any of that confusing? The very first thing I think of when someone says "React Server Components" is, well, server side rendering of react components. What else could it possibly be? Is anyone who is an established React developer really confused by this?
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 confused with SSG which is the case for your blog.
Sure. I’m just trying to answer the parent’s question? I wasn’t the one to bring “SSR” into the conversation.
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
Varnish and PHP say hello from the distant past of 2008.
One more reason to be confused about nextjs
Are you confused about Astro? It follows the same model.