What’s new in Next.js 13

As it was announced at Next.js Conf, Next.js 13 lays the foundations to be dynamic without limits:

• app/ Directory (beta): Easier, faster, less client JS.
  • Layouts
  • React Server Components
  • Streaming
• Turbopack (alpha): Up to 700x faster Rust-based Webpack replacement.
• New next/image (stable): Faster with native browser lazy loading.
• New @next/font (beta): Automatic self-hosted fonts with zero layout shift.
• Improved next/link: Simplified API with automatic <a>.

Update today by running:

npm i next@latest react@latest react-dom@latest eslint-config-next@latest

app/ Directory (beta)

One of the most-loved features of Next.js is our file-system router. Drop a file inside a folder, and you’re able to instantly create routes in your application. No configuration is required.

Today, they have improved the routing and layouts experience in Next.js with the introduction of the app/ directory (beta). This is the result of the Layouts RFC previously published for community feedback. The new router includes support for:

• Layouts: Easily share UI between routes while preserving state and avoiding expensive re-renders.
• Server Components: Making server-first the default for the most dynamic applications.
• Streaming: Display instant loading states and stream in units of UI as they are rendered.
• Support for Data Fetching: async Server Components and extended fetch API enables component-level fetching.

While you don’t need to use the app/ directory when upgrading to Next.js 13, the app/ directory can coexist with the existing pages directory for incremental adoption.

Layouts

The app/ directory makes it easy to lay out complex interfaces that maintain state across navigations, avoid expensive re-renders, and enable advanced routing patterns. Further, you can nest layouts, and colocate application code with your routes, like components, tests, and styles.

The app/ directory can be incrementally adopted from your existing pages/ directory.

Creating routes inside `app/` requires a single file, `page.js`:

// app/page.js

// This file maps to the index route (/)

export default function Page() {

return <h1>Hello, Next.js!</h1>;

}

You can then define layouts through the file system. Layouts share UI between multiple pages. On navigation, layouts preserve state, remain interactive, and do not re-render.

// app/blog/layout.js

export default function BlogLayout({ children }) {

return <section>{children}</section>;

}

Server Components

The app/ directory introduces support for React’s new Server Components architecture. Server and Client Components use the server and the client each for what they’re best at – allowing you to build fast, highly-interactive apps with a single programming model that provides a great developer experience.

With Server Components, they have layed the foundations to build complex interfaces while reducing the amount of JavaScript sent to the client, enabling faster initial page loads.

When a route is loaded, the Next.js and React runtime will be loaded, which is cacheable and predictable in size. This runtime does not increase in size as your application grows. Further, the runtime is asynchronously loaded, enabling your HTML from the server to be progressively enhanced on the client.

Introducing Turbopack (alpha)

Next.js 13 includes Turbopack, the new Rust-based successor to Webpack.

Webpack has been downloaded over 3 billion times. While it’s been an integral part of building the Web, it has hit the limits of the maximum performance possible with JavaScript-based tooling.

In Next.js 12, they began their transition to native Rust-powered tooling. They started by migrating away from Babel, which resulted in 17x faster transpilation. Then, they replaced Terser, which resulted in 6x faster minification. It’s time to go all-in on native for bundling.

Using the Turbopack alpha with Next.js 13 results in:

• 700x faster updates than Webpack
• 10x faster updates than Vite
• 4x faster cold starts than Webpack

Turbopack is our Rust-based successor to Webpack, with 700x faster HMR for large applications.

Turbopack only bundles the minimum assets required in development, so startup time is extremely fast. On an application with 3,000 modules, Turbopack takes 1.8 seconds to boot up. Vite takes 11.4 seconds and Webpack takes 16.5 seconds.

Turbopack has out-of-the-box support for Server Components, TypeScript, JSX, CSS, and more. During the alpha, many features are not yet supported. We’d love to hear your feedback on using Turbopack to speed up your local iterations.

<strong>Note:</strong> Turbopack in Next.js currently only supports next dev. View the supported features. We are also working to add support for next build through Turbopack.

Try out the Turbopack alpha today in Next.js 13 with next dev –turbo.

OG Image Generation

Social cards, also known as open graph images, can massively increase the engagement rate of clicks on your content, with some experiments showing up to 40% better conversions.

Static social cards are time-consuming, error-prone, and hard to maintain. Because of this, social cards are often lacking or even skipped. Until today, dynamic social cards that need to be personalized and computed on the fly were difficult and expensive.

They’ve created a new library @vercel/og that works seamlessly with Next.js to generate dynamic social cards.

// pages/api/og.jsx

import { ImageResponse } from '@vercel/og';

export const config = {

runtime: 'experimental-edge',

};

export default function () {

return new ImageResponse(

(

<div

style={{

display: 'flex',

fontSize: 128,

background: 'white',

width: '100%',

height: '100%',

}}

Hello, World!

</div>

),

);

}

This approach is 5x faster than existing solutions by using Vercel Edge Functions, WebAssembly, and a brand new core library for converting HTML and CSS into images and leveraging the React component abstraction.

Middleware API Updates

In Next.js 12, they introduced Middleware to enable full flexibility with the Next.js router. They’ve heard your feedback on the initial API design and have added some additions to improve the developer experience and add powerful new functionality.

You can now more easily set headers on the request:

// middleware.ts

import { NextResponse } from 'next/server';

import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {

// Clone the request headers and set a new header `x-version`

const requestHeaders = new Headers(request.headers);

requestHeaders.set('x-version', '13');

// You can also set request headers in NextResponse.rewrite

const response = NextResponse.next({

request: {

// New request headers

headers: requestHeaders,

},

});

// Set a new response header `x-version`

response.headers.set('x-version', '13');

return response;

}

You can also now provide a response directly from Middleware, without having to rewrite or redirect.

// middleware.ts

import { NextRequest, NextResponse } from 'next/server';

import { isAuthenticated } from '@lib/auth'; //

Limit the middleware to paths starting with `/api/`

export const config = {

matcher: '/api/:function*',

};

export function middleware(request: NextRequest) {

// Call our authentication function to check the request

if (!isAuthenticated(request)) {

// Respond with JSON indicating an error message

return NextResponse.json(

{

success: false,

message: 'Auth failed',

},

{

status: 401,

},

);

}

}

Sending responses from Middleware currently requires the experimental.allowMiddlewareResponseBody configuration option inside next.config.js.