Why Next.js, Why Now?
The calculated risks and benefits of moving from React to Next.js
In the ever-evolving world of web development, making the right choice of technology stack can significantly impact your project’s success. React has been a popular choice for building user interfaces due to its simplicity and flexibility.
However, can it get even better, especially when it reaches a certain complexity? Are the technical pros and cons the only relevant concern when deciding whether to move to another technology or to stay with the current one? This is where Next.js, a powerful framework built on top of React, comes into play.
In this article, we’ll explore why transitioning from React to Next.js can be a game-changer for your web development projects.
The Rising Popularity of Next.js
I’m Roy Kass, a Tech leader at Tikal, with more than 16 years of experience in the Frontend industry.
Before diving into the technical benefits, let’s talk about the buzz around Next.js.
The frontend ecosystem is fiercely competitive, and popularity can often signal a framework’s staying power. I overviewed the importance of this in my previous article — Fear Driven Development, which I urge you to read.
If you look at npm trends, you’ll see a consistent rise in downloads for Next.js, while GitHub stars and community engagement continue to soar. Next.js isn’t just a trend — it’s becoming a standard.
Its competition (Remix), while existent, functioning and developing, is not really on par in terms of popularity.
The Benefits
Server-Side Rendering (SSR)
One of the most compelling reasons to switch to Next.js is its built-in support for server-side rendering (SSR). While React renders components on the client side, Next.js allows pages to be rendered on the server before being sent to the client. This results in faster page loads, improved SEO, and a better user experience. SSR can be particularly beneficial for content-heavy websites and applications where initial load time is critical. The performance boost is well felt, when compared with profiling tools like lighthouse.
Static Site Generation (SSG)
Next.js also supports static site generation (SSG), enabling you to pre-render pages at build time. This approach combines the benefits of static websites (speed and security) with the flexibility of dynamic content. By generating static HTML files for each page, you can serve them directly from a CDN, significantly reducing the load on your server and ensuring rapid content delivery.
Next.js automatically detects which pages can be statically generated.
Server Actions
Next.js simplifies the creation of backend APIs, by using a unique kind of magic. Instead of defining an API route and creating code that handles it, you just create a file that has “use server” on top and exports only async functions.
Both server code and client code can use those functions. When they are called from the client side, the whole API routing is generated for you, and your code just calls a “server function”.
In my opinion, this feature alone is an enormous upgrade to your developer experience.
Improved Development Experience
Next.js emphasizes developer experience. It uses a SWC (Speedy Web Compiler) Rust compiler, just like in Vite, but modified. Since Next.js isn’t an SPA, it doesn’t need to load all the code in advance, just a very particular subtree of it. To support that, it has a very strong automatic code splitting, which also enables hot module replacement for development purposes. Next.js also has a convention over configuration approach, making most of your development decisions quite easy and well constructed — a clear signature of a framework. In addition, Next weaves together the server/client code in a very streamlined way.
SEO and Performance Optimization
Out-of-the-box SEO optimization is another significant advantage of using Next.js. By rendering pages on the server and providing better control over meta tags and headers, Next.js ensures that search engines can effectively crawl and index your content. Additionally, features like automatic image optimization, built-in analytics, and AMP support help you deliver high-performance, search-friendly websites.
File Based Routing (App Router)
Instead of configuring the routes as an object, or a list of components, Next.js leverages a highly standardized file base routing system to implement routing. This takes care of layouts, pages, errors (including not found and other), loading and more. From my experience, this actually simplifies your code and orders it in a very clear manner. It also enables the partition of the application per page, reducing size tremendously.
It is important to note that about a year ago, Next.js made the transition from the more complicated-to-use Pages Router to the more streamlined App Router, making server components much easier — and enabling the use of server actions.
Better Software Security
Having part of your code on the server side, unlike in a SPA, makes your code more secure, because it’s not exposed to the client. If you only use React, you will have to have all this code exposed on the client side, even though it will be uglified and minified (as this is somewhat reversible).
It’s “Enhanced React”
Next.js has React inside it. You basically write React with a thin layer of Next.js framework around it. Making the transition easy and keeping most of your React expertise value.
There’s no need to learn a completely new technology from scratch.
A Framework, Not A Library
Unlike React, Next.js gives you a full stack and methodology to work with. Although some parts are interchangeable, the solution is somewhat holistic. This brings better standardization and allows for a much better scaling-up experience. For many, this is the real downside of vanilla React — it can never exist on its own, and it creates a jungle of some badly design architectures, without clear and standard best practices.
Even React has on its main page this quote:
“React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or Remix.”
Technological Readiness
Next.js is not like JSP or ASP. It’s a new-generation technology that does a lot for you. Unlike a regular MPA, the development experience is much more fluid and automatic, reducing the boilerplate code and letting you focus on what’s important. This wasn’t possible with SPAs and earlier MPAs.
Things to consider
Hydration Errors
Hydration errors are caused after nextjs bundles the SSR code and while it expects to render something, a whole different thing is rendered on the client side.
- You can either solve the actual problem (which is usually important, like a provider up the chain that couldn’t prefetch data, for example).
- Suppress them using suppressHydrationWarning (this is an element prop)
- Or even turn off the SSR for the relevant components (I don’t recommend this), by using:
const MyComponent = dynamic(() => import('../components/MyComponent'), { ssr: false })Window Does Not Exist Error
This usually happens because the client side is exposed to different things like window, document, local/session storage, etc — that are not exposed to the server. If your client component includes such things, an error that “window is undefined” will pop up while building. This can be addressed in several ways:
- Unlike
!window, this will not produce an error:
typeof window !== 'undefined'2. useEffect — code in a useEffect is client-only and doesn’t produce this error.
Two Debuggers Required
Unlike a SPA, which you debug on the browser only, a Next.js application has 2 parts — the client code, which you debug as usual using your browser developer tools — and a Node server, which you need to debug separately. Since the stitching together of client and server is done semi-automatically by Next.js, it’s sometimes harder to orient yourself, but this should improve with enough experience.
Caching and Optimizations on Production Build Only
When developing you will not enjoy some of Next.js most prominent features, which are aimed to dramatically speed up the application. This is probably to speed up build time during each change in development, but still — the application feels much slower in development than it will on production.
Fetch for Caching
It is also important to note that Next.js monkey-patched the native fetch for caching. This means that if you don’t use fetch, you won’t be able to enjoy a part of the caching done by Next.js. There are some solutions for Axios users that use Tanstack Query, and also some (experimental) solutions for Apollo GraphQL.
Bundling Time
For some reason, It’s very rarely mentioned, but for every page you ask, the Next.js bundles its content for you. This is done 17 times faster than a regular JS transpiler, as Next.js is using a SWC, but it still takes a bit on the first time.
Client Component Props
If you mark a component as “use client” and it is placed in a server component, it is expected that all the props of that component can be serialized. This is because in Next.js components are data — and these props are serialized to the client side. Therefore, the value of the props for these specific components can’t be functions (for example user interaction handlers like onClick), or non JSON objects (like objects that have a different prototype than Object, for example).
Black Boxed Magic
Some of the behaviors are heavily encapsulated within the framework, so it is harder to drill down to the root cause. Also, some code will already be heavily obfuscated when it reaches the browser.
This is the price you pay for the magic Next.js does for you, which is quite powerful.
Excellent Clean Slate Experience Vs Conversion
If you’re starting a new project- starting with Next.js is a no-brainer. The experience is very clean and streamlined.
However, if you are converting from an existing React project, the conversion might pose some challenges, as there are many moving parts in a React tech stack — and not all of them are Next.js ready from the box. It is, however, a feasible step. Take note that every major technological conversion is a challenge, for example — from a single repo to Nx.
Why Now?
To the best of my knowledge and for the time this is written, Next.js is currently in the early majority phase of the adoption curve.
This is a good timing to get into a frontend technology — you get fewer bumps than the innovators and early adopters and you get the most of out of the lifespan of the technology.
Next.js offers benefits that are well above what previous SSR technologies used to offer.
It is also positioned in the best position to inherit the current undisputed ruler of the frontend — React.
As with any technological choice, it is a choice that bears risks and rewards.
Saying that I believe that the risks are manageable and the rewards are great. More than that - taking no action at this phase will be missing an opportunity to adopt a promising technology at the optimal time to adopt it.
