Next.js 12 - 5 Changes You Should Pay Close Attention To
Tags: nextjs, javascript, programming, typescript
Published: 2021-11-05 09:00:46

---
title: Next.js 12 - 5 Changes You Should Pay Close Attention To
published: true
date: 2021-11-02 20:00:00 UTC
tags: nextjs, javascript, programming, typescript
canonical_url: https://www.itmagination.com/blog/next-js-12-release
---
![Next.js 12](https://global-uploads.webflow.com/601be0f0f62d8b2e2a92b830/6181642e80c4c99322bef67a_NextJS%2012%20Lighter%20Smaller-p-500.jpeg)

When developing a website, configuring your framework or library used to be a headache. You used to have to enable numerous crucial features manually, which took some time and a whole lot of patience.

Next.js was created to simplify the development process, and developers really appreciated that. It is the most popular framework in its category for React, and perhaps the most popular hybrid web framework in general. 

Last week, Vercel (the company behind Next.js) shared that they are releasing Next 12 — the next major upgrade. There are a few features that should make the Developer Experience (DX) even better, while there are also some novelties that allow for entirely new solutions to be developed.

## Rust Compiler
Compiling a big website can take a lot of time. Vercel realized it, and introduced a new compiler written in Rust, which is faster than the predecessor. Based on SWC this move is a part of a broader movement towards tools written in Go (e.g., esbuild), and Rust (the aforementioned SWC), as you can easily compile code in these languages to lightning-fast WebAssembly.

The speed is something to admire. The company shares that Fast Refresh is now three times as fast, while builds take five times less time. Comparing SWC to Babel alone, the Rust-based tool is a staggering 17 times quicker. In case you were wondering what codebase was, the benchmark run on, the results were “from using the new Rust compiler with large Next.js codebases.”

## Middleware
A new introduction to Next.js, Middleware, gives you an opportunity to call code before a request is completed. Thanks to that, you may modify the response by “rewriting, redirecting, adding headers, or even streaming HTML.”

This gives you a lot of space to maneuver in, and a chance to do a lot, including: 

- A/B testing
- Bot protection
- If your site is non-compliant with GDPR, you may restrict traffic from the EU
- Analytics on the server side
- Much, much more

It all works out of the box, of course, and Middleware will work on the Edge as well, with few restrictions on what is available in this environment for you. For details, please refer to this page from the official documentation.

### What Exactly Does “Edge” Refer To?
Speaking of the Edge (no, not the guitarist from U2): in the simplest terms, it’s computing done near the request to cut down on latency.

## Native ES Modules Support
ES Modules are nothing new. In fact, they were introduced all the way back in 2015. It took a while to adopt them, however. Node.js started to natively implement ES Modules in March 2021! Browsers were a bit faster. Firefox was the last major browser to adopt them in 2018 with Firefox 60.

The new modules are a big deal because they enable developers to ship less code, making your apps snappier. ES modules also run in the “strict” mode, outputting some smaller errors that otherwise JavaScript would not mind. When using CommonJS modules, developers had a choice whether to use it or not. There are of course many other benefits of using ES Modules over CommonJS; however, an in-depth look is beyond the scope of this article.

## Dynamic URL Imports
At the first glance, many will miss this new feature. Seemingly unimportant, this does change a lot in the JavaScript & TypeScript ecosystem. While NPM as a central store for JS packages worked, and works, some developers might opt out of its monopoly, preferring to store their packages elsewhere. Here is where Content Delivery Networks (CDN) come in. 

In short, instead of pulling packages from the centralized store, you may now install them from wherever you want. Next.js then caches them, and they are ready to go.

The only requirement is for you to let the framework know what is the domain of the CDN you want to use, and it’s done!

This is how to do it:
![Dynamic URL config](https://global-uploads.webflow.com/601be0f0f62d8b2e2a92b830/618160fdba0da58faf5bc49e_Ma4efwZLMhJrvAGBlLdZursPedrCPZQrmNBAKWTcLxS3yyKeemgI-KswjArnmUcpKjJt-49pBr3IpuPm_g5IBKbqKPoYLwF-2siEoBpzasKP2g2Ukyf6eS5uEHDvqR97kREmxC7l.png)

## Preparing for React 18
React 18 will bring numerous new features including Server Components, Concurrent Rendering, and Automatic Batching. All three of them aim to make React snappier, and lighter; the opponents of the library often said that Facebook’s (Meta’s) creation is too heavy and too slow for what it’s doing.

If you want to take a look at the new features of React 18, go to our GitHub repository.

### React Server Components
Perhaps the most “cryptic” change coming to the newest major update of the front-end JavaScript library are the Server Components. Vercel also mentioned them in their presentation as one of the main features. Why? What are the benefits? There are many. First, they reduce the bundle size. By quite a lot, actually. Let’s say you want to render markdown on your website. Simple enough. You need to sanitize markdown, and then render it. For markdown, we have “remark”, and for sanitation, we either have “sanitize-html” or “dompurify.” That used to require additional ~29 to ~66kb. With the server components, the additional JS size goes down to zero. 

Additionally, we can load data directly from the server. We don’t have to wait for the client to request some data, and later to load it. Web apps will become faster and respond quicker. This is a win for the internet. 

Although Server Components sound like Incremental Static Generation that Next.js allowed for, for some time now, ISR will most likely not get deprecated, and the two APIs will coexist together.

## Breaking Changes
As is sometimes the case with major updates, there are some breaking changes the team behind Next.js decided to implement. Luckily, more often than not, they are not going to cause any problems to developers. 

The one change that might become an issue is updating Webpack from 4 to 5. As the team wrote on their blog, they have “worked closely with the community to ensure a smooth transition to webpack 5.”

A few minor changes that should not impact you too much is that there is no need to set target in next.config.js anymore. The option had been introduced in Next 8, though the team quickly realized it was not ideal, creating @vercel/nft. It detects what code is necessary, automatically.

The other two breaking changes is that next/image now uses a span as the wrapping element instead of a div, and the minimum Node.js is now 12.22.0. This is due to the native ES modules support.

One thing that was not mentioned, is the breaking change in removing the possibility to switch React for Preact. It used to work without a problem in Next 11, while in Next 12 it may cause cryptic 500 errors. We do not recommend doing that, anymore.

## Conclusion
Next.js enables developers to write quality React apps quicker. The new major update won’t disappoint React developers, and it will most likely be accepted with open arms. Should you want to try out some new features yourself, we have a project you can clone in no-time. Visit our repository by clicking this link.

## Like developing React apps? We're hiring!
Do you like writing React apps, and think you are one of the best in the area? Do you like new technologies? See our [open jobs](https://www.itmagination.com/open-jobs) — we work with the biggest companies in the world to deliver great web apps.