Static as a Server

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?

&gt; This builds on an insight that seems obvious in retrospect: you can take any “server” framework and get a “static” site out of it by running its “server” during the build and hitting it with a request for every page you want to generate, and then storing the responses on disk<p>I&#x27;m showing my age, but we used to do this using Wordpress <i>ages</i> ago. Like 15 years ago or more haha.

&gt; First, the “hybrid” approach reduces tooling fragmentation—why have two ecosystems when the overlap is so large? The difference is just when the code runs.<p>Because you end up with two subsets of supported features in the same technology, even in the linked page: <a href="https:&#x2F;&#x2F;nextjs.org&#x2F;docs&#x2F;pages&#x2F;guides&#x2F;static-exports" rel="nofollow">https:&#x2F;&#x2F;nextjs.org&#x2F;docs&#x2F;pages&#x2F;guides&#x2F;static-exports</a><p><pre><code> Supported Features The majority of core Next.js features needed to build a static site are supported, including: Dynamic Routes when using getStaticPaths Prefetching with next&#x2F;link Preloading JavaScript Dynamic Imports Any styling options (e.g. CSS Modules, styled-jsx) Client-side data fetching getStaticProps getStaticPaths Unsupported Features Features that require a Node.js server, or dynamic logic that cannot be computed during the build process, are not supported: Internationalized Routing API Routes Rewrites Redirects Headers Middleware Incremental Static Regeneration Image Optimization with the default loader Draft Mode getStaticPaths with fallback: true getStaticPaths with fallback: &#x27;blocking&#x27; getServerSideProps </code></pre> To me, this feels about as awkward as React moving from class based components to function and hook based ones, dragging a lot of the large libraries alongside with it, meaning that if you tried using class based ones for a while you&#x27;d run into cases where some of your dependencies would only offer documentation for the functional approach.<p>Mixing approaches that differ so much inevitably leads to awkwardness. I&#x27;d prefer a SPA library&#x2F;framework without awkward sharp edges and a separate SSR solution, each specialized at what they do, neither trying to do everything. That way the toolchains remain simpler, there&#x27;s fewer abstractions at play and fewer things to keep in mind. But if one tool to rule them all works for you, then great!

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:&#x2F;&#x2F;zeropoint.sh&#x2F;blog&#x2F;astro-as-static&#x2F;" rel="nofollow">https:&#x2F;&#x2F;zeropoint.sh&#x2F;blog&#x2F;astro-as-static&#x2F;</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:&#x2F;&#x2F;exogen.github.io&#x2F;turbo-colormap&#x2F;" rel="nofollow">https:&#x2F;&#x2F;exogen.github.io&#x2F;turbo-colormap&#x2F;</a><p>Or a more complicated app: <a href="https:&#x2F;&#x2F;exogen.github.io&#x2F;t2-model-skinner&#x2F;" rel="nofollow">https:&#x2F;&#x2F;exogen.github.io&#x2F;t2-model-skinner&#x2F;</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 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?

This model already has a name: pre-rendered.

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&#x27;s the latter... uh... why? It&#x27;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.

You guys gotta understand that Next.js is killing React. Just read reddit and HN, nobody asked for those features - we know it is being pushed just to make money, but a library&#x2F;framework should not be guided by VC objectives.

I am having trouble understanding this article&#x27;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 &quot;React Server Components&quot; 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?

I&#x27;m curious if Next has full support for Cloudflare or if this is the only way to run Next w&#x2F;RSC off of Vercel.

This got popular in JS toolkits a few years ago, at least. For instance, Svelte(kit) also has a static output variant.

If you put a cache around all GET API handler, you&#x27;re faster than static.

It&#x27;s unfortunate that there is so much misinformation about what react server components really are, but it&#x27;s not necessarily the fault of either party. The name is confusing (names are hard), the architecture is new (people don&#x27;t want to learn it), and it lends itself to conspiracy theories (that aren&#x27;t true).<p>But it really is a magnificent piece of technology. Because they&#x27;re called &quot;Server Components&quot; people think that &quot;server&quot; 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: &quot;server&quot; doesn&#x27;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&#x27;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&#x27;s here to stay, even if it arrives in other forms.

React is a technique not a technology.

One more reason to be confused about nextjs

Basically this started with vercel &#x2F; next.js. And now react support server components itself. Its nice, if you have business requirements that you can&#x27;t handle with the classic JAMStack approach. For example a shop, where the stock of products updates the UI (e.g. there is a sold-out label and the add to cart button should be disabled if out of stock). Lets say we use next. After a code update or with a cron job, you build the site every 6h. 3k pages (every product, categories etc.). Then, you use server componts and ISR with a ttl of 10min. ISR 10min means, the page get rebuild on the server after 10min with the next request and button gets disabled if the product is out of stock.<p>Yes, you don&#x27;t need this, and you can directly call an API, but, thats bad for the user, because they have to wait for the API request (and UI update) and bad for you, because you have as many API request, you have as page visits.<p>So, server components bring value with the ttl &#x2F; revalidate option of the page. A framework like next&#x2F;vercel brings value if you want to maintain you page over the next 10 years with more then 1 developer.