I dont get it. Yes it's a static site, but it's only text and you're sending 100kb+ of JS over the wire. Is there any reason why you need React?
My exact thoughts[1] when it comes to hosting, things should be static, although I seek joy in Astro and Markdown.
[1]<a href="https://zeropoint.sh/blog/astro-as-static/" rel="nofollow">https://zeropoint.sh/blog/astro-as-static/</a>
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: <a href="https://exogen.github.io/turbo-colormap/" rel="nofollow">https://exogen.github.io/turbo-colormap/</a><p>Or a more complicated app: <a href="https://exogen.github.io/t2-model-skinner/" rel="nofollow">https://exogen.github.io/t2-model-skinner/</a><p>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.<p>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 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.
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.<p>Is it because each component is expected to abstract over async, relying on the promise state?
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).<p>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.<p>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.<p>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 am having trouble understanding this article's premise:<p>```<p>RSC means React Server Components.<p>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.<p>Zero.<p>How is this possible?<p>Aren’t these React Server Components?<p>```<p>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?