Server-side rendering with Next.js

A while ago, I wrote about pre-rendering single-page applications that could remove the need for servers to produce the HTML for dynamic content. It was almost a shot at server-side rendering (SSR) because of my bias to static site generation (SSG) like Gatsby and Next.js (the export part of Next.js that is). For the last year, I've been using SSR via Next.js and I now completely see the benefit.

Where server-side rendering shines

One of the first hurdles we hit with static sites was the requirement to rebuild a site a few hundred times a day because content types were either getting created or updated. Sure, incremental builds helped but when you're talking about plenty of changes across different content types, you'll be building your site a whole lot.

An example for illustration purposes is that Leadhome at any point had a few thousand property listings. There were a few added every day, a few removed, many updated and many being sold or going under offer. That alone would cause the site to rebuild a few hundred times a day without even considering other content types. Along with that, we had area profiles, buying and selling guides, and blog posts. All of which the marketing team were able to modify when needed.

Again, I'm not saying that it's not feasible to do this via static site generation, it just didn't seem practical for us to build the required infrastructure when delivering dynamic HTML has largely been solved for a few decades. This is where moving back towards SSR made sense – for Leadhome at least.

SSR creates the requested HTML on every request which the browser can then load. In the context of React, the client (the browser) will then hydrate the app (load the dynamic client-side scripts) allowing your client-side Javascript to manipulate the DOM. This gives you the benefit of client-side routing, state management etc.

Now, there are plenty of people that will say "what's the point of SSR when search engines support Javascript". Well, simply, they say they do but not one including Google has said they fully support client-side Javascript generated pages and whilst Google my do an alright job of it, a lot of people don't use Google. I've also had the chance to build a crawler and there are plenty of things that need to be done to make sure pages render correctly without affecting SEO.

To summarise, SSR solves the problem we had without having to invest a large amount of time on engineering the best solution via static sites.

Next.js, the only real contender

When Leadhome had started the conversation about building our new frontend apps, Next.js was brought up but there was quite a bit of resistance mainly around the file-system routing. Many options were looked at, even languages outside of React, and also pursuing pre-rendering again. However, Next.js came out on top for most things and a proof of concept begun. Here are some of the benefits that were found.

DevEx (Developer Experience)

Getting setup with Next.js was super easy. It's not a boilerplate like many of the other frameworks I've used. The power comes in via a couple of Next.js scripts that just assumes a bunch of structures such as pages in either `/pages` or `/src/pages` and reads from a config file if it exists.

One of the major points, however, was the fact that Next.js was not just a fly-by-night project and it was around to stay. Especially now with additional funding for Vercel, Next.js is set to continue growing and improving. This means that the community will carry on growing and all the documentation supporting the project will get better and better.

First-class support for SSR, SSG and the in-between

Having the ability to jump between SSG and SSR was a game-changer. We could literally choose the best option without changing a huge amount of context. Then if you had gone with SSR and needed a page that didn't require any dynamic requests, Next.js would simply prepare most of the JS required for the page and simply convert it to HTML at runtime (one less step than full-blown SSR and without the build step of SSG) – this is known as Static Optimisation.

Next.js is also great for single-page apps (SPAs) which is something people often don't consider Next.js for. It has all the requirements for doing so which gives you enormous value when running large scale apps that require SEO pages (server-side) and customer dashboards (client-side).

Performance as a priority

Next.js invests a lot into application performance from code-splitting to image optimisation at runtime with a companion component. When performance is such a key criterion for user experience and even SEO, this was definitely a massive positive.

This also meant that the entire performance of your app would be pulled forward as the framework advances instead of having to invest a huge amount of time doing performance updates yourself.

Is Next.js the only solution?

No. It just worked for Leadhome's context and came before the time of incremental builds (which it now has as well). GatsbyJS also has really great features and my personal opinion is that they're converging onto exactly the same path as each other. I'm sure GatsbyJS would say that they're doubling down on static generation but I can imagine a world where they are like-for-like and driving innovation by competing with each other.

At this present point, Next.js is my go-to framework as it is able to handle all of my requirements right now.