What is Next?

February 10, 20199 minute read
  • node
  • nextjs
  • server

I just updated my website recently.

One of my main goals was to implement server side rendering. I wanted each page to be quick to load to maximize users' first experience. I ended up going with a library created by Zeit called Next.js.

Here, I record the benefits of Next that I valued enough to integrate it into my stack.


But first, a quick blast to the past. 🚀

Disclaimer: The following is my experience in technologies, and is not meant to describe everyone's experience. I know everyone has different context of what technology was like in the past.

When I started getting into web development, Node was still in it's infancy, and the primary, modern stack to learn at the time was the LAMP stack. It had been around for a while and was one of the de-facto stacks to use.

LAMP stands for:

Linux - Operating System - This was before there were so many cloud platform options to deploy and run your applications on, so you were expected to have your own Linux server, or pay a lot of money for a VPS (Virtual Private Server).

Apache - HTTP Server - This was the handler for incoming requests on a specified port. You were able to proxy requests to different applications based on the domain name and route provided.

MySQL - Database - This one is still around and still important, but not quite as popular as it once was.

PHP - Programming language - This was the language of choice for server-side scripting to render the HTML by the server.

The way this stacked worked was by taking a request to your Linux server, passing it through Apache, thus routing it to a PHP script to generate the resulting HTML to serve. It was great for first render, but each subsequent call to a new page would cause a whole new render.

I played around with this stack a little bit, but never really committed to learn everything that could be done with it. For the most part, I could download PHP scripts and setup Apache to "install" apps on a personal Linux server, but wouldn't really develop anything.

Javascript was still important as it was the only programming language option for the browser, but websites weren't quite as dynamic as they are now.

Node Stack(s)

Fast forward a little bit and browsers are becaming more capable, Javascript matured as a language, and Node started to become more popular to be able to use a single programming language on both the front-end in the browser as well as the backend on the server.

Eventually, Node started to take off as an acceptable, stable server-side runtime engine. With the use of Express, Node was effectively able to replace both Apache and PHP on the server.

With the prevalence of Javascript and Node came the popular MEAN and MERN stacks. Which stands for:

Mongo - Database - The most popular NoSQL database, which means flexible objects which could be stored without adhering to a strict schema.

Express - Routing library - Similar functionality to Apache, but more imperitive and executed at runtime, instead of being configured separately and requiring another process. Apache still has its' uses, but isn't required.

Angular or React - Front-end rendering framework libraries - These libraries allow a lot of logic to be moved to the front-end.

Node - Server runtime engine - Executes javascript on the server, usually used to execute an express-based app to route requests to return content.

The proliferation of this stack led to a lot of front-end rendering where the server would return no meaningful markup, but includes a script to "hydrate" the markup.

Example HTML returned from the server:

<html>
  <head>
    <script src="/scripts/index.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

This may be fine depending on the type of user experience you are going for. For example, with propert client-side routing, an application where a user opens it up once, and navigates through different pages without closing the application may never notice the time it takes to load the first page. Although, without proper client-side routing every link would cause a new request, with new dummy HTML, and new rehydration.

This pattern is called a Single-Page Application, or SPA for short. The hydrating script is usually the same for every route, and it just renders different HTML based on information in the window.location object.

The downfall comes from when you have an application, or website, that demands fast single page loading for proper user experience. Think a media site, or a blog, where users go to a page and expect to immediately be able to read an article. They will not wait long for a page to load, fetch data, and render the article.


Next.js

This is where Next comes in, and it can help with both the immediate loading need scenario, as well as front-end application that may not need as much performance.

Note: Since I mentioned Angular above, I want to point out that Next is very React focused, and the remainder of this article assumes React knowledge.

What does Next provide us out of the box?

Server Side Rendering - This is what PHP provided in the LAMP stack. It receives a request, renders the proper HTML, and returns it to the browser. You specify pages via a directoy with top-level React component files, and the output of those components are what are rendered at the root.

Example:

/pages
  - welcome.jsx
  - hello.jsx
// Welcome.jsx
export default () => (
  <p>Welcome!</p>
);

In this example, when you fetch the url localhost:3000/welcome, welcome.jsx is rendered. Contents from hello.jsx are left alone, until you navigate to localhost:3000/hello.

Client Side Routing - Next takes a hybrid approach. On first request it does everything server side, then by using their built-in Link component on the front-end, subsequent requests can fetch assets in the background and hydrate the HTML without doing a full page reload.

Let's say welcome.jsx provided a link to go home:

// Welcome.jsx
import Link from 'next/link';
export default () => (
<>
  <p>Welcome!</p>
  <Link href="/home">
    <a>Go Home!</a>
  </Link>
</>
);

In this example when you click on the "Go Home!" link, Next will fetch the contents from home.jsx and hydrate the existing page with the new markup. If there are common elements on a page, like navigation, they won't be re-rendered.

The next points are more developement focused, but help with the overall experience of coding with Next.

Code-Splitting - This one is very behind the scenes for both the developer and the end-user, but it helps with user experience by making subsequent requests smaller, and never loading more than what is necessary. I won't admit to knowing how Next does it, but basically it can bundle front-end code into smaller chunks that can be shared between components.

Automatic Transpilation and Bundling - For anyone who has ever started an application with create-react-app (aka CRA), you know the limits that a library can have when serving the masses (npm run eject anyone?). Next still uses webpack and babel, but they allow a bit more configuration.

For webpack, they provide a more imperical approach, allowing you to use code to reconfigure the settings. They also provide a lot pre-built extensions to avoid having to write any code.

For babel, I think they have a brilliant solution - they allow you to just create your own .babelrc file and add whatever babel plugins and presets you want, as long as you add the next/babel preset first.

Custom Server & Routing - This is probably one of the biggest selling points to me. Being able to bake Next into my existing (or new) Express server is the best flexibility I could ask for. It allows you to push all of the server side rendering concerns into Next, while allowing the rest of the server to handle the API endpoints without having to stand up multiple servers.

Static HTML Export - Lastly, if you don't want a server at all, or most of your content is static, and thus no need for a server, Next provides the ability to just export all of your pages to static HTML files. The one caveat is if you do any data fetching server-side, that data won't be updated unless you handle the fetching client-side as well.

These are just a few of the features that sold me to integrate Next. But Next has a lot of great features baked in, to read more check out it's official page: https://nextjs.org.


How I Integrated It

Luckily, I already had an Express server setup to deliver my website, along with an API to fetch the content.

All I really had to do was rearrange my React components, placing some in the pages folder, leaving the rest in a components folder. I also had to replace react-router's Link component with Next's Link component.

By following Next's custom server instructions to integrate Next into my existing Express server, I was up in no time. I was able to replace most of my non-API related routes with a general catch-all route that calls Next's handle function and voila, the entire front-end is in the trusting hand's of Next.

I have already seen the benefits in speed and have been so much faster at adding little features across my website.

I definitely see a bright future for Next. 🌟 Maybe MERN really means Mongo, Express, React, and Next.js. 🤔 That's my new favorite stack to use ❤


Thanks for reading!

Was this useful to you? If you have any questions or comments, feel free to use my Contact Form to send me a message, or tweet and follow me on Twitter.