Why Use Next.js?
What is Next.js and what is it useful for? The second question is the more important of the two: what is the point of Next.js? And after one year of using it in production, was it the right choice?
The project & its constraints
About a year ago my team started work on a website with a major clothes retailer. The company I work for does forestry work and biodiversity preservation projects, and we were tasked with presenting these projects on a standalone website.
It’s worth noting here that we were unable to predict if the audience would be a massive rush or just a tiny trickle. This meant that we had to structure the server in a way that would allow us to deal with both situations. And that’s precisely why we used Next.js.
Why Next.js?
Next.js does server-side rendering (SSR). This allows us to generate static files. It allows us to optimize for search engines (SEO) and above all it allows us to use the serverless framework using a custom component. The full details of serverless are beyond the scope of this article, but one of the fundamental principles is for the architecture to be fully dynamic, to be able to scale automatically from 0 up to whatever is needed. This allowed us to be ready for either a high volume of traffic, without paying for unused computing capacity if no one showed up.
Next.js does all this by building on the foundation of React.
To understand exactly what it does and why it is useful, we first need to understand how React works. In a (vanilla) React app, the browser receives a load of javascript from the server, which it then interprets, using it to render an HTML page.
In Next.js, things happen differently. Using Next.js, the server itself generates HTML code directly from the React code. Why? For several reasons: First, rendering the page server-side means that Google’s bots (and those of other search engines) retrieve code they can understand directly, without having to first interpret the javascript and then execute it. Secondly, this also means the page loads faster, and page speed is an important component both of good user experience and of technical search engine optimization (SEO). And a nice bonus is that (in some cases) it is able to generate static HTML, which makes for cheaper and easy hosting. And we all like spending less.
But is server-side rendering not what PHP has been doing for the last 30 years or so? Absolutely. But although Next.js renders the first page server-side, just as PHP does, it then downloads and interprets the JavaScript (also known as hydrating the page), and then behaves as React does.
This means Next.js has the best of both worlds. It combines the advantages of PHP and React, of server-side and client-side rendering.
How did it go, what did we learn?
The end result does indeed minimize initial loading and rendering time, and provides the single page user experience, without having full-page refreshes.
The React base behind Next.js — and its popularity — means that we have a good chance of finding skilled people to help maintain the website if need be.
The developer experience (DX) of Next.js is also a strong argument in its favor, with changes in the code being reflected in near real-time on-screen, making the whole experience fun (which is important to me)
Our usual stack involves mainly PHP and TypeScript, and in contrast, the fact that Next.js uses a single language for both sides of the client/server divide makes it easier to reach the flow state (since there are fewer context interrupts due to language switches).
All in all, we’ve all found Next.js very convincing (and fun) and are using it on all our secondary websites. And I’ve switched to using it for my personal blog. I was already a fan of React, but Next.js makes it even better.
