Next.js - Full Context Review

#full context review#next.js#frontend

Published on:

6/18/2022

by:

Joe

What else is left to be written about Next.js?

In 2022, that's a valid question! With the amount of post, videos, tutorials, crash courses, even books out there about it, you might wonder, is there anything left that's worth covering? The obvious answer is yes, there is. You are not reading another one of those shallow introductory posts. Here at the Full Context Development blog, I deliver something different.

Following a well-defined evaluation method, I go from technical details to real-life outcomes and give you an in-depth, practical overview of how to create the most value with a given technology. It's also like a meta-review. I process the official and community coverage of the tools and document the most important concerns you have to keep in mind while working with them. Like a one-stop guide to best practices and handling common challenges.

So what about this article? Besides all the above, you will learn every nitty-gritty, technical detail of Next.js that will influence the financial performance of your software, short-, mid- and long-term. These are the factors you should get right on a Next.js project in order to maximize profits. I will put the influence of Next over this area into numbers and show you the exact business metrics and mechanism of how it leads to increased revenue and reduced costs. Why? As Patrick McKenzie @patio11 famously said, these are the real problems, sofware engineers are ultimately hired to solve. Here are the main stats right off the bat:

Next.js in numbers:Total Impact: 22850

4500

2000

12250

1850

2250

Next.js is a no-brainer choice for any web project in 2022. It drastically improves developer productivity, while its other contributions are also significant, impactful benefits in their own right. There are, however, certain situations where it's not the optimal choice. (More details are in the Conclusions part.)

(Don't worry if it makes little sense now, there are instructions just a bit further down)

Before you dive in, make sure to take a look at the Table of Contents (yes, it's scrollable) to check the outline and find the most interesting parts you don't want to miss. There are a lot of gems ahead. Some of my favourites are: A list of tools and techniques to improve the frontend performance of Next.js projects. Introductions to next-runtime, a library to bring some of the goodies from Remix.run to Next.js. The exciting instant integration with Framer through URL imports and Handshake. A design checklist to help you bring out the most from Next.js projects. A guide to choosing a rendering mode. Practical tips on how to save money on Vercel hosting, and some ideas about choosing a serverless provider among a lot more, valuable and interesting facts related to the framework. But of course, the main aspect is doing a full context review. Let's get it on!

The core design of Next.js

What I'm not going to do: is introducing how to work with Next.js from the ground up. Instead, I will analyse the core technical design of the framework, especially the building blocks that are relevant in identifying its influence over the real-life outcomes of using it. Right after a quick look back on why does it exist in the first place. (it's relevant)

While this review is not an introduction, I will still name the basic elements of the framework just to be clear about what we will discuss. This next section might be boring if you are familiar with Next. I tried to add in useful information here and there but feel free to skip forward in this case.

How it all started: Do you remember the days (OK, years...) around 2015 when JavaScript fatigue was in full swing? New frameworks and build tooling were constantly popping into existence. People memed about choosing a project setup taking a full month. That was the environment where Next.js was born as an answer to these problems.

And to one more fundamental issue. People realized SPAs are not great for SEO, but still wanted to use them for many valid reasons. SSR was "invented" to save the day, but it was extremely difficult to set it up on a React project. Not to mention in combination with the myriad of other necessary tools. (Looking at you CSS-in-JS)

So let's see the full set of what Next.js is and how it solves these problems and much more.

Rocket tagged 'Remix' flying up high, pulling 3 office workers, representing developers, with itself. Image caption: Remix is an insanely powerful productivity booster.

Server: A production ready, pre-configured Node.js backend (or serverless functions on some providers) to server your assets, do the SSR magic and host your custom APIs, now the middleware functions too.
Compiler: It uses Webpack and Babel under the hood, pre-configured to hide away all the complexity from the devs. To be more precise, in version 12 they replaced Babel with the Rust based compiler SWC for increased build and fast refresh performance but also for a smaller selection of available extensions. If you have a custom Babel configuration, it will fall back to use the earlier tool. (They are also collecting feedback about which transformations should they port to enable wider adoption of SWC.) The compiler also does a lot of additional optimizations we will get to later.
CLI: There's the next tool to start, build, and export your app and another package called create-next-app to speed up your initial project setup. Did you know it can initialize a new project based on any item from their extensive example collection with the --e [name]|[github-url] option?

Then continue with the main structure of a Next.js application. The details will be discussed later at places where their influence is most relevant.

Pages: The elementary building blocks of a Next project. There are 3 flavors: static-, server rendered- and incrementally generated static pages.
Router: Declarative, file-system based routing to navigate between those pages. This is one of the major limiting factors of Next.
APIs: A very efficient way to create HTTP event handlers in your backend / serverless provider.
Middleware: Functions executed before handling requests to pages / APIs. These are running in a standard Web API based Edge Runtime. You can find a really nice collection of examples about what's possible with them here.

This structure and feature set increased developer productivity so much that most metaframeworks created later adopted the same or a very similar approach, often declaring that they are inspired by Next.js. This trend led to the state where we are now in the front-end community:

What's a Full Context review?

Stage 1: Business Idea

Stage 2: Business Vision & Mission & Strategy

Stage 3: Product Strategy & Roadmap

Stage 4: Organization & Processes

Stage 5: Product Design

Stage 6: Software Design

Stage 7: Implementation & QA