Three Export Modes

One misperception among the community (certainly something I used to have) is that it has other export modes. Next.js can build to a standard Node.js app with next build, however, there are actually three export modes:

Serverful Node.js: created with the next build command

Serverless Node.js: with a serverless target in next.config.js and the next build command

Static HTML: created with the next export command

While Zeit’snow v1 is the best host for Serverful Next.js, and now v2 is the best host for Serverless Next.js, the Static HTML mode is a diamond in the rough - literally exporting the app to a folder of static assets (both HTML/JS/CSS bundles as well as prefetched data) that can be served from as simple a utility as Zeit’s serve CLI!

Static is Universal

What is great about a folder you can statically export is that it is the one configuration that literally everybody supports. You can host it on a Raspberry Pi if you wish, or on an AWS S3 Bucket, or on a Node server, or heck you can print it out and have a dance crew do an interpretive dance of the code if you want (results may vary)! And if you ever outgrow your chosen hosting solution, you can pick up and move to the next one that suits you best!

This is the heart of the JAMstack idea - reducing vendor lock-in, promoting fast and secure defaults (because there is nothing as fast as serving a static file with all pre-computation already done). Even concerns about programming environment, like operating system and Node.js version, melt away because it literally doesn’t matter, therefore you never need to debug them.

The best part of all, the only configuration to do gets no more complex than figuring out what folder to upload. It harkens back to the drag-and-drop, FTP days that have been with us since the dawn of Web Development.

If you have your project on a Git provider like GitHub, GitLab, and Bitbucket, you can also set up Continuous Deployment to build and deploy your site after every merge. This is your gateway drug to adding on the rest of Netlify’s functionality onto your Next.js app:

Next.js as a Static Site Generator

By default, Next.js’s static export works on a 1 for 1 basis: if you have a potato.js file in your /pages folder, that directly maps to potato.html. This is fine for authoring static pages with React components and the rest of the React ecosystem, but to truly qualify as a Static Site Generator, it should generate pages from data. So for example, given a /content folder of markdown files, I should be able to generate a corresponding list of HTML pages from a template. Gatsby and React-Static are best known for doing this in the React ecosystem, but you may be surprised to learn that Next.js holds it’s own here!

Data-driven static generation has always been possible with Next.js, but it used to involve a lot of nonstandard custom server coding that raised the bar too high for something predicated on simplicity.

In the static export process we previously wrote about, we didn’t need to write this file because Next.js autogenerates your route map since v6. However, there is no way for Next.js to know ahead of time what dynamically generated routes to statically render. That’s where Dynamic Route Segments come in.

With Next.js 9, we can declare a file structure like this:

- /pages
- index.js
- about.js
- /blog
- [slug].js

Within [slug].js, we can receive that parameter and render the content in React accordingly, effectively turning it into a page template!

However this still isn’t good enough to make Next.js into a Static Site Generator. We need to pass other information other than the slug to the page, and we also need to tell Next.js how many of each slug it should render. It turns out that next.config.js is a very nice place to do this!