Why You Should Learn Next Next

So you've learned React. You know, at least vaguely, what the virtual DOM is and are comfortable with using hooks including useState , useEffect and useRef. What is the logical next step? I think you'll find the answer to this question within the question itself.

The Next Episode

Next is a framework built on top of React that purports to make the development process even more palatable. Personally, I enjoy working with React already, so I was surprised to find the extent to which Next delivers on its promise.

Key Features

What exactly makes learning Next a worthwhile endeavour? There's a lot that sets Next apart from simply using React, but let's start with 3 key features that Next implements to solve common React problems.

1. Server-Side Rendering (SSR)

Upon inspecting the source code of a classic React application in the browser, you will notice that it doesn't contain much. Typically, the only html sent from the server is a <div> with the id of root. The rest of the page gets rendered on the client side, i.e. inside the browser of the user.

Of course, client-side rendering is what makes React powerful in the first place and enables it to utilise its virtual DOM, based on which the real DOM tree gets selectively updated. Instead of rewriting the entire DOM tree every time a change is made by a user, the virtual DOM is capable of selectively updating only those elements that are currently being manipulated.

But React's biggest advantage can also be its biggest disadvantage in some specific cases. NextJS addresses these out-of-the-box, by default, whilst preserving React's other cool features.

Initial Load Time

Loading the DOM in a React application can take some time, and depending on the internet speed of the user, this might result in a blank screen being displayed for longer than is optimal.

SSR reduces the perceived load time of pages because the components are already pre-rendered into html pages on the server, as demonstrated in below video. Even though the actual time taken to load the contents of the DOM is similar, the non-SSR page on the left displays a blank page until all scripts are loaded, whereas the SSR page on the right appears to the user with instantaneously visible content.

Video demonstrating the difference in perceived page load times for non-SSR (left) and SSR (right). Network throttling enabled and set to ‘Regular 4G’ on Chrome Dev Tools. Credit: S. Karavadi's excellent article.

Data Fetching

Imagine you're fetching data, because why wouldn't you be. After all, we're all just slaves to the data, much like dogs are slaves to the ball. A standard React application would need to load all its scripts first to realise it even contains a hook designed to fetch data. Only then would it be able to send a request for the data and wait for its response.

We typically handle this by introducing spinners or similar components designed to tell the user the application is still waiting to receive its data. With Next, you are able to pre-fetch some data at build time, way ahead of the user's request to see it.

SEO

Although React already touts improved SEO capabilities compared to standard Javascript-heavy web apps, Next elevates these to the next level. In standard React applications, search engine crawlers will typically only see the initially empty html page being sent from the server. Pre-rendering your pages on the server side addresses this potential hiccup and allows search engine crawlers to see the content of the application and consequently to be able to index it properly.

2. Simplified Routing

Say goodbye to React-Router-DOM and its ever-changing documentation (although, I do appreciate you, maintainers!). Say hello to defining pages and routes within your folder structure instead! Next comes with a folder called pages, which you can fill with... well, pages. Each file inside the pages folder willl automatically convert to an eponymous route.

/pages 
    /about.js
    /index.js
    /projects.js
    /writing.js

The above folder structure would translate to an application that has the following routes:

/pages/index.js  - BASEURL/

/pages/about.js - BASEURL/about/

/pages/projects.js - BASEURL/projects/

/pages/writing.js - BASEURL/writing/

Neat, right? The file index.js maps directly onto the route / by default. Next can also easily handle nested routes, like so.

/pages 
    /index.js
    /snoop
        /dogg.js
        /doggydogg.js
        /index.js
        /lion.js

The above folder structure would translate to an application with the following routes:

/pages/index.js - BASEURL/

/pages/snoop/index.js - BASEURL/snoop/

/pages/snoop/dogg.js - BASEURL/snoop/dogg/

/pages/snoop/doggydogg.js - BASEURL/snoop/doggydogg/

/pages/snoop/lion.js - BASEURL/snoop/lion/

What about dynamic routes with dynamic parameters? Not a problem for Next either.

/pages
    /index.js
    /about
    /products
        /index.js
        /[productId].js

By wrapping a file name in square brackets, you can indicate to Next that you're defining a dynamic route, the parameter of which you can then access from within your code.

/pages/products/[productId] - BASEURL/products/{param}/

I'll go into more detail about how to access dynamic parameters in an article that focuses specifically on routing. But for the purposes of this article, just let it be known that handling routing is pretty intuitive and doesn't involve importing any additional libraries.

3. Backend Capabilities

NextJS also enables us to incorporate backend code that, say, communicates with a database or with the filesystem. You might find yourself writing NodeJS code inside a Next application to perform CRUD operations or authenticate users. The benefit of building a full-stack application using Next is that you no longer have to switch between separate projects to fine-tune your application.

Files that live inside the folder pages/api, which is created by default, will be treated as API endpoints. For instance, a route resulting from the file-path pages/api/artist.js would return a JSON response with a status code of 200, if it had something akin to the following backend code in it:

export default function handler(req, res) {
  res.status(200).json({ name: 'Snoop Doggy Dogg' })
}

I initially had no idea Next was capable of this. Knowing that I can create RESTful APIs using a React framework that I intuitively only associated with frontend capabilities continues to blow my mind.

That's It?

Nope, I barely scratched the surface. I found a very concise but technical summary of cool Next features on Reddit by none other than the (then) lead maintainer of Next. I encourage you to read it if you want to know more but can't be bothered actually spending hours sifting through the sizeable official Next documentation (which itself, by the way, ticks all "great docs" boxes in my opinion).

Still Not Convinced?

Another consideration is that NextJS is not just some fad that will blow over in a couple of months. Initially released by Vercel in 2016, it's become a well-established framework with an ever-growing community of users, making it a sought-after skill in the job market.

NextJS is here to stay, and slay.

Arguably, NextJS is already famous enough to render this article pretty much pointless. One last proof of Next's supreme rendering capabilities.