Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interface any REST API you like, and be as dynamic as you want. Plus, MDX plugin makes it easy to creates competely static areas/content focus sites within the same project.
Unfortunately, I get the feel that with the release of v13 app router, they don't give the static export feature enought love. Features from the pages router were dropped for static export (shallow routing, static rewrites/redirects). I fear they are dropping static export all together in the future, as you don't need their comercial vercel offering at all when using static export.
This is incredibly complex for many static site use cases (i.e. blogs, documentation, marketing pages). Most don’t need JavaScript let alone React/JSX/Middleware/SSR/et al. I can’t imagine the long-term maintenance of something with so many moving parts and npm dependencies. Not saying there’s not a use case, but we should KISS before jumping to projects with a 1.8 GiB Git checkout & 828,128 LoC just to make a landing page.
It is definetely only geared if you create a webapp, not a website. You can have static content (with MDX) for certain parts of your app, and restrict i.e. dynamic javascript stuff to your user's account/login section. But everything is within a single codebase.
I personally don't care for the size of my node_modules folder, storage is cheap. Plus, with a yarn.lock or package.lock you don't have to care about npm dependencies, if you don't upgrade any, your simple `yarn install && next build && next export` will always produce the same result for years to come. The actual export output of NextJS is amongst the smallest you can get - you also get a nice summary of how big the initial load is for every route.
Everything is chunked per route, all js chunks and assets contain their hash in the filename. That is why you can serve all of /_next/static with the `Cache-control: immutable`. This means if you don't update a section of your app, there is not even a need for the client to send GET requests with the `If-modified-since`, means: No additional roundtrip for any chunks. Preloading can be configured, by default its on-link-hover - that is, if your user hovers over a hyperlink/route, nextjs will already fetch the required chunks for that route before the click happens.
Yes, NextJS is not competing with Hugo or other static site generators. It is aimed at tech-savvy people, and only for webapps that will require programming JS.
Agreed, but I think most people spend most of their time working on things more complicated than a blog. It seems there's a lot of excitement for purely static sites, which is fine, but I would call it hype at this point, and caution someone jumping into a new project against using a static site generator where it doesn't fit.
This is a actually the contrary they started caring more though all scenarios might not be covered yet.
See this example from Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
It's not related to Vercel business model but to the fact that this use case is less common (in proportion) when using Next.js.
I am not sure what you mean by static rewrites, isn't that covered by middlewares?
The link you posted from Gaeron uses the (now deprecated) pages router, directly supporting my argument.
I did a migration from pages router to app router for my static-export project. Btw both are still present in v13, you can pick whichever you want, but long-term the pages router will be gone.
With static redirect/rewrites I mean the feature in pages router where you put in the "redirect"/"rewrite" statement in your next.config.js. These will be respected and work in a static export environment. If you try to perform a static export using app router, it will error and tell you that you have to remove "redirect"/"rewrite" from next.config.js and it is no longer supported.
Yes, you could use a middleware for redirects, but that is exactly my point: Middlewares do not work with static exports, they are middlewares for the server-side next server. Which is not present in a static export (and requires running your own server again, or use vercel's offering).
The same holds true for shallow routing for static exports, it is a feature still present in pages router, but not in app router. There is a GH issue of a lot of users complaining about this, but no feedback from the maintainers whether this is planned to bring back: https://github.com/vercel/next.js/discussions/48110
Indeed it uses pages router, my point was more the timing because it has been posted recently while Lee Rob was tweeting about next export being reenabled (in 13.4 I think).
For shalllow routing you are probably right (I don't use them much so I can't tell much, but I do have a few critics regarding app router too) but regarding rewrites, an URL rewrite has to happen in a server so I still don't get your point. What was removed in v13 is the shortcut via next.config.js not the ability to do rewrites/redirects which can be done easily using middlewares or whatever your host provides. It's also recommended to setup i18n yourself in a similar fashion instead of using the built-in config, something that I've been advocating for a long time (https://github.com/vercel/next.js/discussions/17631#discussi...).
Gaeron example or the comments below show how to handle dynamic routes rewrites via nginx for instance.
Rewrites and redirects do not need to be executed server-side ever since the html5 URL API. Of course you can redirect client-side, as in NextJS: router.push(). And given that redirects/rewrites work for the pages router also contradicts that point.
But yes, you will need to add support within the webserver like nginx. A simple modification to `try_files` will do, and is probably present in most deployments anyway (because you will want URL routes like example.com/news instead of example.com/news.html). I think they just not considered that feature in the design of the app router. And I also don't think it is technically impossible to apply client-side redirects/rewrites within app router.
Unfortunately, I get the feel that with the release of v13 app router, they don't give the static export feature enought love. Features from the pages router were dropped for static export (shallow routing, static rewrites/redirects). I fear they are dropping static export all together in the future, as you don't need their comercial vercel offering at all when using static export.