Next.js: The good, the bad, and everything you need to know

NextJS is a technology that is widely used nowadays for web development. Personally, I quite like it and have used it in multiple projects. After several years of using both React and NextJS, I want to tell you about the good, the bad, the advantages, and the problems I have encountered while creating products.

If you want to learn React and NextJS, I am considering offering a webinar training. If you're interested, sign up here so I can notify you by email.

Introduction

The first thing I want to tell you is why I started using React: when I began my career, Angular.js was trendy, and we developed some web applications for clients (some of them very interesting, to be honest), going through several versions of it. Then I started working for other clients who used React, which had just appeared around that time and was trending, so I had to learn it.

There's a lot to tell here, and I'll save this for another post, about the internal workings of React and the different rendering strategies: Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), and the new React Server Components (RSC).

React itself is just a client-side library, so you have to manage all the implementation to perform server-side rendering, as well as bundle compilation. Obviously, we're not going to reinvent the wheel (unless we see a valuable opportunity), so the next step is to look for a tool that does it for you.

In this case, the best development environment for me to date, and for quite some time, is to use NextJS. So I want to share my experience with NextJS, all the good things it brings me, and why I chose it, but also everything they don't tell you, the problems you face in day-to-day development.

NextJS: the good and the bad

NextJS is a framework for creating web pages based on the React library. It's open-source and maintained by the company Vercel, which also offers hosting. This framework offers multiple advantages:

NextJS functionality

• Server-Side Rendering (SSR): improves SEO and initial loading speed.
• Static-site generation (SSG): allows you to generate static pages at build time, so you only have to serve static files. More efficient, cheaper, and ideal for pages that don't change frequently.
• Routing system: the folder structure allows you to create the routes of your website easily and flexibly. So far, I haven't encountered any problems.
• Data pre-fetching: improves the user experience by loading data before it's needed.
• TypeScript support. If you want typing, it comes by default.
• It's based on Node.js and allows you to add routes (/api) very easily.

The good of Next.js

• One thing I really like is the community. In the end, there are many people working with the same tool, encountering the same problems as you, which either allows them to be solved earlier or someone has already found a workaround.
• Working with "jsx" / "tsx" files is very convenient. Being able to have HTML along with Javascript / Typescript code makes development faster.
• The development environment and experience are well taken care of, they work fast, and they usually don't cause problems.
• It integrates many optimizations without you needing to know how to optimize the bundle, how to prefetch, image optimization, etc.
• It saves you from working with javascript files, connecting them with HTML, and managing bundling by yourself, which usually requires a lot of knowledge and, most importantly, time.
• Many people are testing and reporting bugs, so development is very active, and both errors are corrected and improvements are continually added.

React Server Components

Recently, React Server Components have been released, which I will explain soon what they are and why they are interesting, and NextJS is the only framework today that implements them since, so to speak, React only defines the interface but leaves the implementation to third parties.

The idea behind RSC is simple: to render on the server everything that can be as server-components, which act as an HTML template and do not send javascript code to the browser. This way, you can use client-components where you need interaction with the user, reducing the bundle size and page load (and interactivity) time.

Basically, what you can achieve with technologies from 20 years ago like php / python with tools to create html templates with a touch of javascript. Although it is true that Nextjs offers many advantages so that you don't have to worry about managing user interaction, that is, all the javascript part comes "out-of-the-box".

Everything they don't tell you

When there are so many people and companies using NextJS after several years, I think they must be doing something right for so many people to continue using it, like myself, for example.

"Not all that glitters is gold," and when I encounter problems, I consider how easy it could be to do the same things with an HTML template. In fact, I have some projects with static generation or with native HTML templates, and working with js and html is much more tedious than jsx. Or perhaps I have just gotten used to this ecosystem, which is more comfortable for me.

In any case, I'll tell you the things I don't like:

• Using server-side rendering is computationally expensive. The renderToString function (or the new renderToNodeStream) is CPU intensive, and if you have a lot of traffic, it's convenient to have a caching layer well configured.
• If you deviate from the "happy paths," there are usually problems. Whenever I've needed to do something more complex or outside the norm, I encounter various issues.
  • For example, you can't access the URL you're rendering on the server and need a workaround to have the path https://github.com/vercel/next.js/issues/43704
  • NextJS middleware is designed for a edge runtime, so you can't do much logic here and have to delegate it to some API.
  • If you need multi-language support, you'll add complexity to your codebase although you'll get it to work as you want.
• Problems are solved with workarounds. Luckily someone has already encountered the same problem as you, and there is usually a thread in GitHub issues on how to solve it. Although often, these workarounds have their disadvantages.
• The whole new part of React-Server-Components is green, and you encounter errors. In my case, I've had to redesign some parts of systems I have in production due to bugs in the current version.
• Many times I wonder if there's a better alternative when I encounter all these problems, but for now, I haven't found it.
• If you need to add a fairly large layer of customization, such as custom code, it's usually quite complex or not possible to use it.

Conclusion: why I keep using NextJS

Despite all the bad, I know very well how NextJS and React work, I've studied the different details, the problems that arise, how to solve them... and in the end, this, along with the comfort of jsx/tsx and the development experience, allows me to move fast.

It has everything I need to build a simple, functional, and efficient product, which is ultimately what one seeks. And if I encounter problems over time, I can always redesign parts using other technologies.

In the end, my advice and learning in this sector is that, in general, technology is secondary. Choose the one you like the most, the one you're best at, the one that allows you to go faster, and start building and iterating on your product.

As it grows, there will be parts that you'll have to redesign, and here you can consider using other tools for specific problems that you really have, avoiding adding complex solutions for problems that don't exist today or you don't know if you'll have them.

And hey, I'm not saying we shouldn't think about what we want to build and design it well from the start, common sense always, please.

So choose a tool, learn it well, and start building, otherwise, you'll spend your time learning tools and refactoring code.