Next.js client-only SPA example
Made this example to show how to use Next.js router for a 100% SPA (no JS server) app.
You use Next.js router like normally, but don't define
getStaticProps and such. Instead you do client-only fetching with
react-query, or similar methods.
You can generate HTML fallback for the page if there's something meaningful to show before you "know" the params. (Remember, HTML is static, so it can't respond to dynamic query. But it can be different per route.)
Don't like Next? Here's how to do the same in Gatsby.
npm run build
This produces a purely static app in
It's purely static in the sense that it doesn't require Node.js — but router transitions are all client-side. It's an SPA.
out/ folder anywhere on a static hosting.
There is however an unintuitive caveat — which is maybe why people don't use Next.js widely this way at the moment.
In traditional SPA setups like CRA and Vite, you have one file like
index.html that's served for every route. The downside of this is that (1) it's empty, (2) it contains your entire bundle by default (code splitting and
React.lazy doesn't help here a lot because it creates waterfalls — you still have to load the main bundle first before it "decides" to load other scripts).
But if you look at what Next.js generated, it's an HTML file per route:
So you'd need to teach your static server to do this rewrite:
The syntax for these rewrites is different for different static hosts, and I don't think there's an automated solution yet.
I suspect this is why a lot of people don't realize Next.js can produce SPAs. It's just not obvious how to set this up.
Ideally I think Next.js should either pregenerate such rewrite lists for common static hosts (e.g. Nginx, Apache) etc or there should be some common format that can be adopted across providers (e.g. Vercel, Netlify, etc).
(Note that if we didn't do
next export, Next.js would still create static output, but it would also generate a Node.js server that serves that static output. This is why by default SSG mode in Next.js emits a Node.js app. But it doesn't mean your app needs Node.js by default. Next.js apps don't need Node.js at all by default, until you start using server-only features. But you do need to rewrite your requests to serve the right HTML file for each route.)
This is a better SPA
It makes sense to have an HTML file per route even if you're doing an SPA. Yes, we need to figure out a good way to set up these rewrite maps, but it's strictly better than serving one
index.html page with a giant bundle (or a smaller bundle + a bunch of code that's loaded in a waterfall), which is how SPAs are typically done today.
It's also great to have the ability to do a bunch of stuff at the build time. E.g. I can still do
getStaticPaths in this app to pregenerate a bunch of HTML files with actual content. It's still an SPA and still can be hosted statically! I can also eventually decide to add a server, and I don't need to rewrite anything.
I find this approach pretty-lightweight, what has made it uncommon until now is that 1) without RSC you needed hydration everywhere, making a static website like this potentially less performant than non-React alternatives 2) the URL rewrite thing is annoying to code, and few frontend devs have the required devops skill (and time) to produce an OSS lib to cover this use case.