> 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.
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/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: 'blocking'
getServerSideProps
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'd run into cases where some of your dependencies would only offer documentation for the functional approach.
Mixing approaches that differ so much inevitably leads to awkwardness. I'd prefer a SPA library/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'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!
I consider Next.js as a solution that not only embraces the JAMstack approach, with all its benefits and drawbacks, but also facilitates the implementation of business requirements that demand a more dynamic content update mechanism, such as Incremental Static Regeneration (ISR). Additionally, it supports functionalities like handling headers, redirects, and rewrites. Essentially, Next.js addresses the limitations of JAMstack while retaining its advantages.
(God why is this 8 paragraphs. This is what you get for being my first HN post of the day with a cuppa fresh coffee in hand. Shame on you for being the first post I saw while firmly rocking on my hobby horse.)
Dunno, the Next.js hybrid approach seems both trivial to understand the trade-offs of, but also optimal:
You get to use the same tooling, but if you don't use any of the dynamic stuff like the router (stuff you'd obviously need to use a server for), then you get to output static html files.
Or, you can start with an SSG site and then decide that you want server-side logic, and all you do is opt-in to some server-side logic.
This works well because instead of traditional SSGs like Jekyll, Next.js has the nice UX/DX of writing a dynamic server where it has a build step that crawls all your routes to generate static files (the right way to do SSG imo). So when you decide you want to run on a server, you just deploy it on the server instead of using the crawl step.
Framing this into a confusing subset vs superset distinction kinda obscures what's really going on. It's like writing an Express app but opting in to SSG by using a build tool that wget-crawls your local server.
The downside of Next.js is that client-side "rehydration" is inherently complex, not that it can enumerate your routes to generate static files. It's just that when you build a system that can render server html templates to strings and then rehydrate them in the browser, it's trivial to build the tool that saves those server templates into static html files.
And I think you're imagining that you could only do such a thing if you designed for it from the beginning, essentially bending over your abstraction to force that feature, when it's actually a trivial entailment of the system in the first place.
you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev supports static HTML-only output for a site built with React.
as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.
I think you just proved the point by introducing yet another frontend framework to learn.
And you absolutely don't want one tool to do everything. HTML/CSS is native and understanding it is a requirement for React. It also doesn't require Node and a build step.
I think all software engineers in the world who know HTML/CSS (like who doesn't?) beg to differ
Really funny how some devs think they know the secrets of engineering simplicity and everyone else is a fool for not knowing what they know (HTML/CSS).
Read this thread. There are some comments about using React components for everything and never touching HTML tags and CSS. And they probably call themselves senior frontend engineers.
> HTML/CSS is native and understanding it is a requirement for React.
It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
> It also doesn't require Node and a build step.
The point is assuming you already have node and a build step. You already know React. So just use it for everything. Everyone who thinks they can "just write HTML/CSS" ends up introducing Hugo or Gatsby or whatnot (or, worse, writing their own "simple" Makefiles and shell scripts) and gradually adding more and more features until it's just as complex as React. Just use React.
> It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
...what? What are you writing in React if not HTML tags and CSS classes? How can you even write anything in React without that? React doesn't do anything CSS specific either, so I don't understand how you'd even style anything if HTML and CSS were not a "necessity."
> I try to avoid having to know or care about the underlying implementation details.
This feels quite ignorant. I'm not sure, in some ways I understand it, for example, when running software on the JVM, I typically don't think about how it's implemented, so I share some of that ignorance.
At the same time, specializing to just knowing one technology (e.g. React) and not caring about up or down the stack can also be limiting - both for any career moves (Vue? Angular? working with how the resources are packaged and deployed?) as well as just debugging things in more detail (since one can feasibly imagine cases where you need to look at both the output HTML/CSS/JS to understand why certain things are happening, not just a React plugin in DevTools).
You don't have to learn things that are of no value right now, but you probably shouldn't go out of your way to not learn things. Staying curious is generally pretty nice!
I mean, sure, I do actually know a bunch of the details and it's occasionally useful for debugging. But I look for ways to work at the React level if possible (e.g. using the React dev tools to debug the component hierarchy rather than using the raw browser dev tools where possible). IME it's better to fully specialise in a small set of technologies than to dabble across a wider range.
And what are in those components? Divs with a className property I assume? Or are you literally only using components other people have made in UI libraries with no changes of your own?
I generally use preexisting components, there's not a lot of value add in creating my own date picker or dropdown box or whatever. Obviously I put my own content in, and compose together existing components to make bigger new components if the component I want doesn't exist (e.g. if I couldn't find an address entry component I might make one out of individual text entry components). I think some of the components I use might actually be or correspond to "basic" HTML tags, but that doesn't make any difference at the point of use.
If a component doesn't have built-in styling support (i.e. configurable via React properties) then I'll use Tailwind so I can at least ignore all the selectors and cascading nonsense of CSS. (I remain hopeful that the world will eventually see that inline styling is the way to go; with Tailwind I meet them halfway)
Okay, well you do realize you're not the average programmer right? I'd even say this is junior level if you are not really creating your own code and components, so it's not accurate to say that HTML and CSS are not "necessary" unless you're doing what seems to be very basic work. And Tailwind is still CSS, again, so without knowing what things like flex actually do, you can't use Tailwind either. I'm beginning to suspect you may just use AI to build much of your code for you.
If your company has a good component library, you can really stay in that circle for 95% of the time. If you need that 5%, usually there's a library unless you're doing something really bespoke like canvas/webgl.
And AI really can do a lot of work nowadays. I met a founder who built their entire mvp with v0.dev. 5 pages, multiple flows, modals with photo taking/uploading and working color picker. They only needed to add the api-calling logic.
If you load external content on build (e.g. external blog pages, prices from an external store, etc), then you'll need some way to template that into your HTML. I'm not a huge React fan but I do like JSX compared to other templating languages.
Yeah, but this function needn’t run in the browser. Just generate HTML with it and save into a file! (I don’t have a link to npm handy, but I’m sure there’s a library that can do that already.)
Alternatively, you can use Astro with React components, which will render them using React-DOM, but save them as static HTML by default (you can still choose some components to be hydrated, though).
The article in question is specifically about using Next.js to do what you are saying (generate static HTML files from a set of React components). He also mentions using Astro for it.
Think a about the case, that you have a shop, and you need the stock to disable the add to cart button. You can do a API request for every page visit. Or, use something like ISR to revalidate stock on the server and rerender the page every 10min.
> 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
I'm showing my age, but we used to do this using Wordpress ages ago. Like 15 years ago or more haha.
That came later, but yes we could (we did some wild stuff with v8js in PHP). And I'm convinced that anything in the blog requires either feature, though I get that more complex systems might.
Yeah, I remember all the fun that I had with PhantomJS & friends... My point was that isomorphic/universal/whatever it's called now JS and declarative component frameworks do have some advantages over our WP setups from 15 years ago. Agreed that you should still choose the right tool for the right job though.
With Moveable Type we even generated .php files with prerendered content in it from the database and using the PHP part of it to add server side dynamic functionalities. This was a very nice balance between a static and a fully dynamic website.
Think about product stock that change or you have a website with a cms and 100 Editors that push changes every 5min. If you have 5k pages. Then its likely, that builds take longer then 5min. And if you want to have a up-to-date website, you have to build it every 5min. This is where ISR and SSR comes into play, to update the pre-rendering on the server.
5k pages in 5 minutes? That's only 16/second. If your generator/server is on the JVM I'd expect it to be capable of more like 5k/second at least (and if you have a sensible `last_updated` or `version` field, you could early return with a Not Modified for even better performance). If you're batch processing, you could do a lot better than that.
Why would you rebuild the site every time an editor updates a page? Just update the page that was edited. Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
That's a good suggestion, and it works well if you know which sites have changed before building.
> Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
This is essentially what Incremental Static Regeneration (ISR) does.
But, mostly you pre-render it, because else, the first user has to wait to long for the page. ISR is also re-rendering for the next user. The current user has the old version and the page is re-rendering in the background for the next user.
The JAMstack architecture is advantageous because it allows for the use of simple servers—essentially S3 buckets that can serve static files. This setup requires less security patching and reduces costs for server hardware. Additionally, the server essentially acts as your cache, allowing you to distribute it widely.
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/
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 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.
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?
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.
No, you can not pre-render a shop site that needs product stock for UI updates. For this business requirement the classic JAMStack approach does not work. You need ISR or SSR. And you can combine pre-render with ISR for example.
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.
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.
It is certainly not true that the point you describe is inevitable. Lots of sites will never reach the point where they need dynamic content. As to "why not" - because simplest is best until such time as you have a genuine need for the complexity. YAGNI is a maxim for a reason.
Really feels like this generation of devs do not see the value in YAGNI, mostly appear to chase complexity because that's how you peddle courses, talks, books, etc.
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.
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.
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 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).
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.
This makes perfect sense for a headless CMS. An editor might upload changes or a new article a few times per day/week into a database through a headless CMS. A webserver could make a request to the headless CMS/database for every web page load, but if the content doesn't change then the webpage can be computed and served statically.
The web server can compute just the changes per page or regenerate the whole site on any change on the backend.
I too have had to use Next but didn't want to feel locked into Vercel.
this is the biggest effort I'm aware to run Next with a full-ish feature set outside of Vercel: https://opennext.js.org/. Supports AWS, Cloudflare, and Netlify. You can also run Next as a normal node webserver. I've only used the Cloudflare integration and it was a bit janky but worked (and seems to be entering 1.0 soon so may be less janky).
AFAIK this is completely unsupported by the Next team, but would love to be proven wrong!
the biggest headache i had in particular was different ways of handling environment variables, but the different adapters at OpenNext have had a rolling list of caveats/unsupported features for as long as i've been following the project so i didn't want to outright say "full". hopefully the effort on Next's side to build a standardized adapter API will help with this!
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
I'll add to the confusing caching: Next deciding to monkey patch fetch() to add their caching, and Next relying on a React Canary version left in some (surely in me) a taste that RSC were half baked, which is weird since they've been around for like, five years?
> 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.
Too many devs rely on a single tool to try to do everything, at the cost of complexity. The amount of knowledge you need to use any Javascript framework is IMO, insane, let alone try to keep up with the latest and greatest.
The enshittification of the web partly is shipping giant JS bundles for no reason. (Developer needs > Consumer)
> 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.
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.
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.
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
It’s not like this is not used anymore. Majority of CMSes that are actually good are written in PHP. And every single one of them will have various html caching drivers. From simple file caches, to redis, varnish or outside cdns like cloudflare.
Good that you say that. I believe the model is more important here than the implementation detail, framework or language of choice.
Plus, I think Astro wins over Next in terms of documentation and the general developer experience.
Next has the bad vibes, unfortunately because of all Vercel thing. At least for me. I believe if Next would position itself somewhere like Astro, people would be more open to learn and dig it. I don‘t exactly know if it‘s 100% true, but I feel like if I invest my time in Next, I will be locked-in by the Vercel world of things. And no one likes that.
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?
Basically this started with vercel / next.js. And now react support server components itself.
Its nice, if you have business requirements that you can'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.
Yes, you don'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.
So, server components bring value with the ttl / revalidate option of the page.
A framework like next/vercel brings value if you want to maintain you page over the next 10 years with more then 1 developer.
> 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.
Because you end up with two subsets of supported features in the same technology, even in the linked page: https://nextjs.org/docs/pages/guides/static-exports
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'd run into cases where some of your dependencies would only offer documentation for the functional approach.Mixing approaches that differ so much inevitably leads to awkwardness. I'd prefer a SPA library/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'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!
I consider Next.js as a solution that not only embraces the JAMstack approach, with all its benefits and drawbacks, but also facilitates the implementation of business requirements that demand a more dynamic content update mechanism, such as Incremental Static Regeneration (ISR). Additionally, it supports functionalities like handling headers, redirects, and rewrites. Essentially, Next.js addresses the limitations of JAMstack while retaining its advantages.
(God why is this 8 paragraphs. This is what you get for being my first HN post of the day with a cuppa fresh coffee in hand. Shame on you for being the first post I saw while firmly rocking on my hobby horse.)
Dunno, the Next.js hybrid approach seems both trivial to understand the trade-offs of, but also optimal:
You get to use the same tooling, but if you don't use any of the dynamic stuff like the router (stuff you'd obviously need to use a server for), then you get to output static html files.
Or, you can start with an SSG site and then decide that you want server-side logic, and all you do is opt-in to some server-side logic.
This works well because instead of traditional SSGs like Jekyll, Next.js has the nice UX/DX of writing a dynamic server where it has a build step that crawls all your routes to generate static files (the right way to do SSG imo). So when you decide you want to run on a server, you just deploy it on the server instead of using the crawl step.
Framing this into a confusing subset vs superset distinction kinda obscures what's really going on. It's like writing an Express app but opting in to SSG by using a build tool that wget-crawls your local server.
The downside of Next.js is that client-side "rehydration" is inherently complex, not that it can enumerate your routes to generate static files. It's just that when you build a system that can render server html templates to strings and then rehydrate them in the browser, it's trivial to build the tool that saves those server templates into static html files.
And I think you're imagining that you could only do such a thing if you designed for it from the beginning, essentially bending over your abstraction to force that feature, when it's actually a trivial entailment of the system in the first place.
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?
you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev supports static HTML-only output for a site built with React.
as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.
I think you just proved the point by introducing yet another frontend framework to learn.
And you absolutely don't want one tool to do everything. HTML/CSS is native and understanding it is a requirement for React. It also doesn't require Node and a build step.
I think all software engineers in the world who know HTML/CSS (like who doesn't?) beg to differ
Really funny how some devs think they know the secrets of engineering simplicity and everyone else is a fool for not knowing what they know (HTML/CSS).
Read this thread. There are some comments about using React components for everything and never touching HTML tags and CSS. And they probably call themselves senior frontend engineers.
> HTML/CSS is native and understanding it is a requirement for React.
It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
> It also doesn't require Node and a build step.
The point is assuming you already have node and a build step. You already know React. So just use it for everything. Everyone who thinks they can "just write HTML/CSS" ends up introducing Hugo or Gatsby or whatnot (or, worse, writing their own "simple" Makefiles and shell scripts) and gradually adding more and more features until it's just as complex as React. Just use React.
> It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
...what? What are you writing in React if not HTML tags and CSS classes? How can you even write anything in React without that? React doesn't do anything CSS specific either, so I don't understand how you'd even style anything if HTML and CSS were not a "necessity."
> What are you writing in React if not HTML tags and CSS classes?
UIs made of React components. I try to avoid having to know or care about the underlying implementation details.
> I try to avoid having to know or care about the underlying implementation details.
This feels quite ignorant. I'm not sure, in some ways I understand it, for example, when running software on the JVM, I typically don't think about how it's implemented, so I share some of that ignorance.
At the same time, specializing to just knowing one technology (e.g. React) and not caring about up or down the stack can also be limiting - both for any career moves (Vue? Angular? working with how the resources are packaged and deployed?) as well as just debugging things in more detail (since one can feasibly imagine cases where you need to look at both the output HTML/CSS/JS to understand why certain things are happening, not just a React plugin in DevTools).
You don't have to learn things that are of no value right now, but you probably shouldn't go out of your way to not learn things. Staying curious is generally pretty nice!
I mean, sure, I do actually know a bunch of the details and it's occasionally useful for debugging. But I look for ways to work at the React level if possible (e.g. using the React dev tools to debug the component hierarchy rather than using the raw browser dev tools where possible). IME it's better to fully specialise in a small set of technologies than to dabble across a wider range.
And what are in those components? Divs with a className property I assume? Or are you literally only using components other people have made in UI libraries with no changes of your own?
I generally use preexisting components, there's not a lot of value add in creating my own date picker or dropdown box or whatever. Obviously I put my own content in, and compose together existing components to make bigger new components if the component I want doesn't exist (e.g. if I couldn't find an address entry component I might make one out of individual text entry components). I think some of the components I use might actually be or correspond to "basic" HTML tags, but that doesn't make any difference at the point of use.
If a component doesn't have built-in styling support (i.e. configurable via React properties) then I'll use Tailwind so I can at least ignore all the selectors and cascading nonsense of CSS. (I remain hopeful that the world will eventually see that inline styling is the way to go; with Tailwind I meet them halfway)
Okay, well you do realize you're not the average programmer right? I'd even say this is junior level if you are not really creating your own code and components, so it's not accurate to say that HTML and CSS are not "necessary" unless you're doing what seems to be very basic work. And Tailwind is still CSS, again, so without knowing what things like flex actually do, you can't use Tailwind either. I'm beginning to suspect you may just use AI to build much of your code for you.
If your company has a good component library, you can really stay in that circle for 95% of the time. If you need that 5%, usually there's a library unless you're doing something really bespoke like canvas/webgl.
And AI really can do a lot of work nowadays. I met a founder who built their entire mvp with v0.dev. 5 pages, multiple flows, modals with photo taking/uploading and working color picker. They only needed to add the api-calling logic.
> you don't need to send 100kb+ of JS over the wire to build a static site in react
It is telling that the blog of the fw creator ships 500kb of JS/CSS/HTML to display text on a screen.
> it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR)
WebComponents (+lit-html)
Yep. 411 KB of JS (126 KB minified). 525 KB of fonts! 40KB of HTML. 1.1MB (704 KB minified) total for approximately 4.3 KB of actual text.
That's a crap:content ratio of 256:1
Wow this is a great metric to use.
If you load external content on build (e.g. external blog pages, prices from an external store, etc), then you'll need some way to template that into your HTML. I'm not a huge React fan but I do like JSX compared to other templating languages.
Then use JSX without React?
What do you mean?
JSX compiles to jsx(“div”, props, children) function calls so you need a runtime (which can be small) to render that into strings.
At which point, who cares if you’re using react to do it? It’s a good zero dep implementation of a jsx fn.
Yeah, but this function needn’t run in the browser. Just generate HTML with it and save into a file! (I don’t have a link to npm handy, but I’m sure there’s a library that can do that already.)
Alternatively, you can use Astro with React components, which will render them using React-DOM, but save them as static HTML by default (you can still choose some components to be hydrated, though).
The article in question is specifically about using Next.js to do what you are saying (generate static HTML files from a set of React components). He also mentions using Astro for it.
Basically at any time they could turn it into an SPA, but tbf you don't need RSC for that.
Think a about the case, that you have a shop, and you need the stock to disable the add to cart button. You can do a API request for every page visit. Or, use something like ISR to revalidate stock on the server and rerender the page every 10min.
> 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
I'm showing my age, but we used to do this using Wordpress ages ago. Like 15 years ago or more haha.
We did, but we were not able to run our PHP in the browser or prerender our jQuery on the server.
> pretender our jQuery on the server.
That came later, but yes we could (we did some wild stuff with v8js in PHP). And I'm convinced that anything in the blog requires either feature, though I get that more complex systems might.
Yeah, I remember all the fun that I had with PhantomJS & friends... My point was that isomorphic/universal/whatever it's called now JS and declarative component frameworks do have some advantages over our WP setups from 15 years ago. Agreed that you should still choose the right tool for the right job though.
With Moveable Type we even generated .php files with prerendered content in it from the database and using the PHP part of it to add server side dynamic functionalities. This was a very nice balance between a static and a fully dynamic website.
My exact thoughts[1] when it comes to hosting, things should be static, although I seek joy in Astro and Markdown. [1]https://zeropoint.sh/blog/astro-as-static/
Think about product stock that change or you have a website with a cms and 100 Editors that push changes every 5min. If you have 5k pages. Then its likely, that builds take longer then 5min. And if you want to have a up-to-date website, you have to build it every 5min. This is where ISR and SSR comes into play, to update the pre-rendering on the server.
5k pages in 5 minutes? That's only 16/second. If your generator/server is on the JVM I'd expect it to be capable of more like 5k/second at least (and if you have a sensible `last_updated` or `version` field, you could early return with a Not Modified for even better performance). If you're batch processing, you could do a lot better than that.
Why would you rebuild the site every time an editor updates a page? Just update the page that was edited. Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
That's a good suggestion, and it works well if you know which sites have changed before building.
> Even better, don't pre-render anything until the first time it's requested, then render, serve, and cache it.
This is essentially what Incremental Static Regeneration (ISR) does.
But, mostly you pre-render it, because else, the first user has to wait to long for the page. ISR is also re-rendering for the next user. The current user has the old version and the page is re-rendering in the background for the next user.
The JAMstack architecture is advantageous because it allows for the use of simple servers—essentially S3 buckets that can serve static files. This setup requires less security patching and reduces costs for server hardware. Additionally, the server essentially acts as your cache, allowing you to distribute it widely.
My website has about 700 pages. A full rebuild takes around 10 seconds.
That's nice, how many API requests in build-time do you have per page?
Your artifact or whatever has a footer typo
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 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 model already has a name: pre-rendered.
No, you can not pre-render a shop site that needs product stock for UI updates. For this business requirement the classic JAMStack approach does not work. You need ISR or SSR. And you can combine pre-render with ISR for example.
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.
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.
It is certainly not true that the point you describe is inevitable. Lots of sites will never reach the point where they need dynamic content. As to "why not" - because simplest is best until such time as you have a genuine need for the complexity. YAGNI is a maxim for a reason.
Really feels like this generation of devs do not see the value in YAGNI, mostly appear to chase complexity because that's how you peddle courses, talks, books, etc.
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.
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 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
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.
This makes perfect sense for a headless CMS. An editor might upload changes or a new article a few times per day/week into a database through a headless CMS. A webserver could make a request to the headless CMS/database for every web page load, but if the content doesn't change then the webpage can be computed and served statically. The web server can compute just the changes per page or regenerate the whole site on any change on the backend.
You can also simply call it caching and put that rendered html in cache inside or even outside your system and you get the same thing.
Because it's an easy and widely used framework to write JavaScript components that react to changes in state
Jekyll is fine. So is React. And Astro. Some folks like different things than others.
[dead]
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 too have had to use Next but didn't want to feel locked into Vercel.
this is the biggest effort I'm aware to run Next with a full-ish feature set outside of Vercel: https://opennext.js.org/. Supports AWS, Cloudflare, and Netlify. You can also run Next as a normal node webserver. I've only used the Cloudflare integration and it was a bit janky but worked (and seems to be entering 1.0 soon so may be less janky).
AFAIK this is completely unsupported by the Next team, but would love to be proven wrong!
(I'm on the Next.js team) We're working with Cloudflare on an official adapter.
https://github.com/vercel/next.js/discussions/77740
that's great to hear, thank you for the update :)
Next works great as a vanilla node app. What features are you missing from Vercel's platform out of curiosity?
the biggest headache i had in particular was different ways of handling environment variables, but the different adapters at OpenNext have had a rolling list of caveats/unsupported features for as long as i've been following the project so i didn't want to outright say "full". hopefully the effort on Next's side to build a standardized adapter API will help with this!
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
https://parceljs.org/recipes/rsc/
"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.
I'll add to the confusing caching: Next deciding to monkey patch fetch() to add their caching, and Next relying on a React Canary version left in some (surely in me) a taste that RSC were half baked, which is weird since they've been around for like, five years?
> 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!
Too many devs rely on a single tool to try to do everything, at the cost of complexity. The amount of knowledge you need to use any Javascript framework is IMO, insane, let alone try to keep up with the latest and greatest.
The enshittification of the web partly is shipping giant JS bundles for no reason. (Developer needs > Consumer)
> 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.
React is a technique not a technology.
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.
It’s not like this is not used anymore. Majority of CMSes that are actually good are written in PHP. And every single one of them will have various html caching drivers. From simple file caches, to redis, varnish or outside cdns like cloudflare.
[dead]
One more reason to be confused about nextjs
Are you confused about Astro? It follows the same model.
Good that you say that. I believe the model is more important here than the implementation detail, framework or language of choice.
Plus, I think Astro wins over Next in terms of documentation and the general developer experience.
Next has the bad vibes, unfortunately because of all Vercel thing. At least for me. I believe if Next would position itself somewhere like Astro, people would be more open to learn and dig it. I don‘t exactly know if it‘s 100% true, but I feel like if I invest my time in Next, I will be locked-in by the Vercel world of things. And no one likes that.
[dead]
[flagged]
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?
Don’t engage with trolls, dude.
Basically this started with vercel / next.js. And now react support server components itself. Its nice, if you have business requirements that you can'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.
Yes, you don'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.
So, server components bring value with the ttl / revalidate option of the page. A framework like next/vercel brings value if you want to maintain you page over the next 10 years with more then 1 developer.