What's the big deal with Next.js?

Avatar of Neil Gebhard Neil Gebhard
/

When choosing a framework for a project, a few questions pop into my head. How do we increase performance? How do we reduce complexity? How do we scale?

With this in mind, Next.js does a great job in answering these questions. It does it in several ways.

Static site generation (SSG) allows a single-page application to serve static HTML files.

The way this works is content gets pre-loaded into HTML at build time. This means static HTML is delivered to the client on initial load. With this setup, HTML files are cached by CDNs, increasing data transfer speeds.

Server-side rendering (SSR) allows dynamic data to have HTML files built on the server.

Sometimes, HTML files can't be known at build time. Page content changes over time depending on data and the users. Nonetheless, re-deploying your website every time content changes is unfeasible. With SSR, we can still have content that is dynamic and pre-rendered. It is done by fetching on the server before files are delivered. This is quicker because it removes the overhead of browser-to-server round trip requests.

To be fair, SSG and SSR are available in vanilla React too, but it has to be added manually. Why not have these features built into the framework? That's what reducing complexity is all about.

SSG and SSR improve search engine optimization.

By removing client-side fetching, the content of a page is stable on initial load. Google web crawlers see exactly what your users see. There's no flickering. You're not left wondering if your page content loads in a timely manner.

Next.js has automatic code-splitting.

Code-splitting delays the load of certain files by dividing your app into small pieces of code. It improves performance by making the client only download files the user needs. This avoids the downloading of gigantic files. Also, having many small, individual files enables caching.

Next.js makes routing easier.

In Next.js, files map to URLs. Doing it this way, developers end up writing less code. Typical SPAs need a programmatic setup of routing (e.g. React Router). Next.js streamlines the process.

React codebases often have components map to pages anyway (i.e. /pages/Home).

Next.js has full-stack capabilities.

Next.js supports a backend inside itself. Most projects of any meaningful significance need a backend. How will we develop the next Twitter or Facebook without one? This removes the necessity to add an entirely separate codebase and framework. Oftentimes, the backend is in a completely different language too.

Next.js deployment is simple.

Vercel designed Next.js with deployment in mind. It only takes a few clicks and your app is live. Serverless functions make Next.js apps scale infinitely. It is production-ready by default.

What about create-react-app?

CRA is still useful for learning React and prototyping, or if performance optimizations aren't important.

I would also check out Vite or Parcel for lightweight React setups.

When should you not use Next.js?

If you have an existing codebase, it's probably not worth all the effort to migrate and refactor.

There is some extra work to learn the framework.

If your app has data that is frequently changing such as an analytics dashboard, pre-rendering is less useful.

Conclusion

Next.js is modern React. There aren't many downsides. The documentation is great and it's well-supported. Almost every use-case is met. I would recommend starting new projects using this amazing framework.