What Next.js is — who draws the screen, and when

When screens used to flash

Older websites went white for a moment every time you clicked a menu item. A slow connection made it longer and a fast one shorter, but the structure was the same.

The reason is simple. Every navigation had the browser ask the server for a new document matching that address, and the whole screen was repainted from what came back. That is the multi-page approach.

It had the advantage of simplicity: one screen is one document. Search engines found it easy to read, since every address returned a finished document.

Mobile apps raised the bar

Then mobile apps arrived. An app is fundamentally different from the web. Downloading it from a store already puts what is needed to draw its screens onto the device.

So moving between screens does not ask a server for a new document. Navigation happens instantly, and only the values to fill that screen come from the server. No flash, and it feels smooth.

Having felt that, users raised their standard. The question became whether the web could do the same, and the answer was yes.

The single-page approach is that answer. Load what is needed on first arrival, and when the user asks for another screen, reveal one that was already there, hidden. Not discard and refetch, but hide and reveal.

The problem that created, and the fix

The single-page approach had a cost. If screens are painted in the browser, a search engine arriving may see the blank state before JavaScript has run.

This is less severe than it once was; search engines have executed JavaScript and read the result for years now. Still, places remain that need content the server prepared in advance, such as the preview card shown when a link is shared.

So rendering on the server first is used alongside it. It is called server-side rendering: the server builds a finished screen and sends it, and the browser takes over from there and moves smoothly.

Letting you pick between the two per screen inside one project is what Next.js does. A landing page and shareable article pages can render on the server while a dashboard behind login renders in the browser.

The real reason it is called a framework

Next.js is not called a framework only because of rendering modes. It has to do with how web development actually happens now.

Nobody writes everything from scratch. Login, calendars, video players and other things many people need repeatedly have already been built by someone. Those bundles are called packages, and the warehouse you pull them from is npm.

So your project becomes a pile of other people's parts combined with the code you wrote. The problem is that a browser cannot read it in that state. A browser reads only the three files from post two.

The process that performs the conversion is the build. It merges parts and your code, splits and bundles them, and turns all of it into something a browser can read. When a deploy takes a few minutes, most of that is the build, and because writing code by a fixed set of rules gets the rest done for you, we call it a framework.

parts pulled from npm
        +                →  build  →  what a browser can read
the source code you wrote                 HTML · CSS · JavaScript

the few minutes a deploy takes is mostly this arrow