What’s New in Next.js 13? [UPDATED for Next.js 13.5]

Summary

• Next.js brings us layouts, Turbopack, advanced caching, and many more goodies, including the (theoretical) reduction of client-side JavaScript thanks to the new app router;
• The new approach to structuring your Next.js apps is opt-in, and can be adopted incrementally, for a smooth adoption;
• New features will make developing performant web apps easier;
• Next.js 13 comes with Server Components enabled by default;
• Is Next.js 13 worth the upgrade? Yes.
• We updated the post to include the changes from Next.js 13.4 & Next.js 13.5.

Updated for Next.js 13.5: Faster & More Performant Dev Experience

With Vite taking over the JavaScript world, we must admit, the Next.js developer experience isn't the best in comparison with Astro's or Vue's. Reloads are slower, startups are slower... Even though Turbopack might change that completely, the stable version is still some time away. That's why we were rejoiced to learn the new version starts the local server 22% faster, Fast Refresh is 29% faster, and memory usage is 40% smaller, when using next start.

One user even reported 87-92% faster compilation (!).

Updated for Next.js 13.5: next/image Improvements

The image component we know and use got a bit of an improvement. You may now take advantage of image optimization without using the <Image /> component by using the new, experimental, unstable_getImgProps() function.

The new functionality will be welcome with open hands by web developers, because thanks to the new, experimental, functionality, websites should be much faster.

Update: Caching in Next.js Apps Explained

One of the key features that make Next.js applications incredibly fast is its advanced caching mechanisms. Let's dive into how Next.js caching works and how it can automatically boost your app's performance.

What is Caching in Next.js?

Caching in Next.js is designed to enhance your application's performance and reduce operational costs by storing rendering work and data requests. This means that instead of fetching data or rendering pages from scratch every time a user visits, Next.js can retrieve the stored version, making the process much faster.

Key Caching Mechanisms in Next.js:

1. Request Memoization: This mechanism allows the server to remember the return values of functions. If the same data is requested multiple times in a React component tree, Next.js will use the stored data instead of fetching it again. This is particularly useful when the same data is required in different parts of a page, ensuring that multiple network requests for the same data are avoided.
2. Data Cache: Next.js has a built-in Data Cache that keeps the results of data fetches across server requests and even deployments. This means that once data is fetched, it's stored and can be used for subsequent requests without having to fetch it again from the original source.
3. Full Route Cache: This mechanism caches the entire HTML and React Server Component Payload of a route on the server. This reduces the cost of rendering and enhances performance since the cached version of the route can be served to users.
4. Router Cache: On the client side, Next.js stores the React Server Component Payload for each route segment. This cache improves navigation experiences by storing previously visited routes and prefetching potential future routes.

How Does This Make Your App Fast?

By default, Next.js tries to cache as much as possible. This means:

• Routes are rendered and stored, so they don't need to be rendered from scratch for every user.
• Data requests are stored, reducing the need to fetch the same data repeatedly.

For instance, when a user visits a statically rendered route for the first time, the route is fetched and stored. On subsequent visits, instead of rendering the route again, Next.js serves the cached version, making the page load incredibly fast.

Update: The New app Router is Now Stable

We had to wait for a while, but the new app router is now stable. That means that:

• React Server Components
• Nested Routes & Layouts
• Simplified Data Fetching
• Streaming & Suspense
• Built-in SEO Support...

...are now deemed stable enough for the wider use. Now that we know that, we encourage companies of all sizes, who already are using Next.js, to give the the new router a shot. If your company does not already use to at least consider giving it a try. The server components are a massive change, that could enable you to build faster apps.

Be careful, however. If, for any reason you need to include Client components, then the JavaScript bundle can be bigger than it used to be with the pages router.

Update: Server Actions

Sometimes, it's impossible to not opt into the client component. If you so much as need to use "useState", react to something, etc, then you must use "use client." Then you have to wrap your head around how to fetch data from the parent component, except you can't pass functions from the parent to the child, if the parent is a server client, and the child is a client component.

Server Actions are here to make client components better. You will be able to call server code from client components. How?

async function create(formData: FormData) {
	'use server';
  	
    const user = await prisma.user.create({
    // please note, that this is for sure NOT a production ready code snippet ;)
    data: {
      name: formData.get('name'),
      email: formData.get('email'),
      password: formData.get('password')
    },

  })
}

export default function Page({ params }) {
  return (
    <form action={increment}>
    	<input type="text" name="name" />
      <input type="text" name="email" />
      <input type="password" name="password" />
      <button type="submit">Register</button>
    </form>
  );
}

The possibilities are endless with this one, although some are concerned.

Update: Metadata API

Properly setting the metatags for SEO was challenging if you used the new, experimental way to build apps. You had to create special files (head.js) which was rather cumbersome. The new approach revolves around exporting objects (for static metadata) or functions (for dynamic metadata).

//https://nextjs.org/blog/next-13-2#built-in-seo-support-with-new-metadata-api
// Static metadata
export const metadata = {
  title: '...',
};

// Dynamic metadata
export async function generateMetadata({ params, searchParams }) {
  const product = await getProduct(params.id);
  return { title: product.title };
}

That is a major quality of life improvement for developers working on projects of all sizes.

Update: API routes for the app directory

One missing piece that the new way of writing Next apps was missing was API routes. They allowed you to use Vercel's framework as a truly full-stack framework. You kept intensive tasks running on the server-side, keeping only the necessary bits on the client.

Of course, you could create API routes in the old pages folder, but that was not an ideal solution. Sure it worked, but the new router not supporting one of the most important features was just not ideal to say the very least.

The Next.js team delivered in the update.

Not only are the API routes now available, but they even updated them.

Now, you may only respond to one HTTP method, easier than before. Furthermore, the "Route Handlers" are based on what we all, web developers, know: the standard Web APIs such as Request and Response.

Here's how you would set cookies:

import { cookies } from 'next/headers';

export async function GET(request: Request) {
  const cookieStore = cookies();
  const token = cookieStore.get('token');

  return new Response('Hello, Next.js!', {
    status: 200,
    headers: { 'Set-Cookie': `token=${token}` },
  });
}

Overall it's a big improvement. Here's how you would check for a POST request before:

export default function handler(req, res) {
  if (req.method !== 'POST') {
    res.status(405).send({ message: "some message here" });
    return;
  }
  // do something here...
}

Update: Statically Typed Links

A big quality of life improvement.

You now get statically typed links in the app directory. What does it mean? Imagine you have a route such as "/marketing-pricing." You use a link in your app, but instead of correctly typing the link, you write "/marketing-price." You deploy to production, aaaaand... Google complains to you that you have a broken link. Oops.

What happens now is that you would actually get an error, thus saving you from making this silly mistake.

Maybe it's not a big deal, however it's a great addition to the framework.

Heads up: if you are not already using TypeScript, you will have to start using it to benefit from this.

Update: Turbopack Improvements

Turbopack, the newest bundler, and successor to webpack did not start off too strong. Too many things were missing. That's why, since the last release, the Next.js team added these features:

• Support for next/dynamic
• Support for rewrites, redirects, headers , and pageExtensions in next.config.js
• Support for 404s and errors in pages
• Support for CSS modules composes: ... from ...
• Improved Fast Refresh reliability and error recovery
• Improved CSS precedence handling
• Improved compile-time evaluation

Additionally, it is now in the Beta status.

Update: Caching

They say the most difficult aspect of programming is caching... It's perhaps good, then, that you get an easy caching mechanism out of the box, that's easy to understand, and make use of. Most importantly, the new mechanism controls the caching rules on the side of the app, which differes a bit from how caching usually works. Usually it's the APIs that dictate for how long you may cache.

// https://nextjs.org/blog/next-13-2#nextjs-cache
export default async function Page() {

  const [foo, bar, baz] = await Promise.all([
    // Cached until manually invalidated
    fetch(`https://...`),
    // Refetched on every request
    fetch(`https://...`, { cache: 'no-store' }),
    // Cached with a lifetime of 10 seconds
    fetch(`https://...`, { next: { revalidate: 10 } }),
  ]);

  return 
...
;
}

On the 25th of October, people all around the world tuned in to watch Next.js conf – the conference where developers found out what the developers of the most famous React framework prepared for them. All who turned up for the stream or the in-person event witnessed the presentation of the next major version of the framework – Next.js 13. The view was quite something – the new version is much different in many ways than its predecessor. It changed so much in so many ways – the company itself claimed the update will be the biggest change to Next.js ever. Was it? We watched the full conference for you, but if you want to watch it yourself first, you may find the video below. Otherwise, read on.

Lastly, Vercel, called the new version “dynamic without limits.” This perhaps refers to the removed limitations connected to the app sizes. Previously, you had to choose carefully what you enabled your users to do, and what not to do, as new possibilities often meant more and more data users had to pull. Now, that worry is not at the back of developers' head anymore: websites will remain fast unless you make them slow, and heavy on purpose.

The New Way to Build Next.js Apps

Some Context

Reinventing React was the topic of recent months. The topic? Fetching data and removing the tons of JavaScript we ship to users around the world. For one, it made users’ experience much worse. Moreover, it had an adverse effect on Earth – all data sent across the internet = emitted carbon (perhaps reducing emissions is just a side-effect, though it’s sure a nice outcome). Another problem was the problem of waterfall fetching. In short, instead of fetching data in parallel, browsers fetched data in sequence (one after another).  

The first React framework (or the first mainstream framework) to solve the problem of both waterfalls, and too much client-side JavaScript (both at the same time) was Remix. It became an internet hit. The creation of the React Router team was web-standards first, and enabled developers to create React websites that were lighter and rendered quicker on top of that. Another selling point was the unique approach to fetching data, but that’s another story, for another article.

Remix’s approach was picked up by the Next.js team, and in May 2022, they have announced requested feedback on their new proposal: “Layouts”. The change was called the biggest one to date, and it sure was. A big portion of why developers all around the globe waited  

Pages vs App

The groundbreaking features that Next 13 brings are entirely opt-in. We are not sure for just how much longer the legacy, and the new approach will be supported at the same time, though at the time of writing they are.  

Putting your code in the pages folder is the old way of writing full-stack apps you know and are used to. Nothing changes about the core process here, and if you want to stick to the old ways, then you may skip this section, and move to the “Turbopack” one.

If you are ready for the new (and slightly untested), put your code in the app directory, and read on. Vercel promised a dramatic reduction in client-side JavaScript... and they delivered! Previously, a simple “Hello, World” app would require sending over 70kB of data just to have a div. Now, if you don’t need interactivity, the only thing we get is HTML, and CSS. No JS WHATSOEVER. Of course, if you need interactivity, JS will appear, and we are not talking about the full React + Next package.  

Loading States, Layouts

The worst part of the web experience is waiting for something to load while having nothing to look at. One talk during the presentation of React 18 already mentioned that and touched on the importance of introducing loading states with Suspense.

Next.js 13 delivers an improved version of the mechanism. You may now create a function called “Loading” that users will see until data fetching for your page is complete.  

The upgraded Layouts solve the problems of all Next releases up to date. Previously, creating reusable foundations for pages was slightly problematic. One had to use a quick and a somewhat improvised way to go about things, but not anymore. We may now create a file called “layout.tsx” that components will use to build a user interface.

Server Components

Server Components enable massive savings in the bundle size. They are a bit of a shakeup in the front-end world as well. React used to be a client-side library only. As we wrote before, that changed recently, with the addition of this new type of a building block. Next.js now uses them, and uses them by default to help you make faster apps.  

The new components might make GraphQL and other libraries even more popular. How so? GraphQL is heavy. @apollo/client is ~42kb by itself (minified; version 3.7.1). If you now keep everything on the back-end, then no single byte is included in the client bundle. For smaller teams there is a benefit as well. You may now even call Prisma directly inside your components (even though you don’t really want to do that).

There are a few drawbacks, however.

Many third-party components will have to be wrapped in a component that will tell Next that it’s a client component. It’s a bit of additional work; busy work that nobody likes. You are not able to add any interactive elements, too. To do that, you must use Client Components.

Furthermore, calling fetch from Client Components is not supported currently. As the docs say:

fetch is currently not supported in Client Components. Although it is possible to fetch data in Client Components by, for example, using a third-party library such as SWR, you might run into performance issues when doing so.

Streaming

Traditionally, users had to wait for all the page to generate before they received any of it. Not anymore. Server will now send the UI to the client in small bits, as they get created. This means larger chunks will not block the lighter ones. Of course, this feature is currently supported only in the app directory, and it does not seem as if it might change.  

People with fast Wi-Fi or with access to a good internet connection aren’t going to benefit from this new addition as much as the ones with slower connections. There are more people like this than you would have thought. It’s great that we may now improve the experience for them – they may be customers you could have had if your webpage loaded faster.

Turbopack

Turbopack is the successor to Webpack. Vercel, having hired Webpack’s creator, had the possibility to write a faster, better tool than Webpack. It’s much faster, that’s certain, though it’s not all great. For one, you now have to author plugin using Rust, instead of JavaScript. The subset of JavaScript developers having working knowledge of the systems language is much, much smaller, than the set of JS devs.  

That’s a trade-off, though. We now have a tool that’s lightning fast and will heavily decrease build times for large apps. The change is aimed at enterprises. For small teams, the change is nice, but won’t change much, realistically. Enterprises will now build their apps in a much shorter time and having to hire Rust developers is not a big deal for them.  

Furthermore, developers’ favorite, Tailwind CSS, does not really work with Turbopack now. It was a big misstep from the bundler’s creators, though we don’t think it won’t be remedied soon.

The speed

Turbopack is blazingly fast. We are not sure whether the trade-off of faster vs losing many existing plugins is worth it in the end. It also remains a question why the development team behind the framework did not choose to use Vite. Surely, some of the existing Webpack plugins will be made compatible with Turbopack, though Vite has a sea of them already, AND it’s blazingly fast as well. A bundler monopoly is not something anybody wants, on the other hand.

New next/image, @next/font, and improved next/link

There are new packages coming your way, that will make your images & fonts load faster, as well as some improvements to how links work in Next.js 13. They work the same in the app and the pages directory.

next/image

The new helper is designed to make pictures load even faster. This release brings us some improvements. Firstly, it now helps you to speed up the Largest Contenful Paint (LCP). LCP is the largest element one sees on a page. If it’s an image, then Next.js will tell you to add a special priority attribute to the picture, so the framework can prioritize the loading of said block.  

From other noteworthy additions, now the alt attribute is required, which means you will have to add it to all your images. Quite frankly, you should have done that already, so that is a non-issue.

@next/font

Fonts are some of the heaviest things to load on a site. Vercel teamed up with the Chrome team to deliver the best experience. The library allows you to load fonts from Google (downloaded at build time) or load local fonts, from your server. In case you worry loading fonts from the company from Mountain View will expose your users, worry not. Users don’t connect to the servers of the search engine company at all.

next/link

The solution for enabling client-side navigation has changed a bit. As the documention says:

The <Link> Component no longer requires manually adding an <a> tag as a child. This behavior was added as an experimental option in version 12.2 and is now the default. In Next.js 13, <Link> always renders <a> and allows you to forward props to the underlying tag.

@vercel/og

Setting a dynamic Open Graph (OG)/Twitter image used to be a challenging task. There was a repository on GitHub, courtesy of Vercel, where the task was made significantly easier for you. All you had to do was clone the code, make changes, deploy the service, and, in a few hours, you were done. Now, you may be done in less than an hour.  

The way it works is you create a React component, which is then transformed into an image. Sounds simple, and it is. There are some limitations as to what CSS properties are supported, though don’t worry about that one bit. The possibilities are still wide open for you to create stunning OG images

Breaking Changes & Migration

We will start with the one breaking change everybody is happy to see. INTERNET EXPLORER ISN’T SUPPORTED ANYMORE 🎉.

Further, what you need to keep in mind is:

• The minimum version of React is now 18.2.0, up from 17.0.2. If you need a refresher of what version 18 changed, look here;
• We said goodbye to Node 12, so you need to upgrade your containers/change your environment, and (at least) embrace Node 14;
• Minifying by SWC is the new default;
• The next/image you were used to is now next/legacy/image. To migrate to the new next/image run the codemod;
• The new next/link automatically adds an achor tag, where previously you had to have one as a child;
• There are some changes in the functionality of navigation hooks. For more details, go here.

Conclusion

To sum up, the benefits of Next.js 13 are worth the upgrade. Furthermore, the additional packages, such as @vercel/og or @next/font are worth adopting along with the new app directory. Of course, you don’t need to migrate all pages right away. You may upgrade incrementally, one page after another. This was always Vercel’s philosophy with the framework. This is perhaps the reason why the biggest companies feel safe using Next.js in production. If you want to have your app migrated to Next.js 13, want a new site running on the most popular React framework, or want to have a chat about building your web app, feel free to contact us here.

‍