Technology Blog

Look deep into latest news and innovations happening in the Tech industry with our highly informational blog.

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.

Pic courtesy:


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.

Pic courtesy:

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.


The app/ directory introduces the ability to progressively render and incrementally stream rendered units of the UI to the client.

With Server Components and nested layouts in Next.js, you’re able instantly render parts of the page that do not specifically require data, and show a loading state for parts of the page that are fetching data. With this approach, the user does not have to wait for the entire page to load before they can start interacting with it.

Pic courtesy:

You can colocate your application code, such as components, tests, and styles, with your routes.

When deployed to Vercel, Next.js 13 applications that use the app/ directory will stream responses by default in both the Node.js and Edge runtimes for improved performance.

Data Fetching

React’s recent Support for Promises RFC introduces a powerful new way to fetch data and handle promises inside components:

// app/page.js

async function getData() {

const res = await fetch(‘…’);

// The return value is *not* serialized

// You can return Date, Map, Set, etc.

return res.json();


// This is an async Server Component

export default async function Page() {

const data = await getData();

return <main>{/* … */}</main>;


The native fetch Web API has also been extended in React and Next.js. It automatically dedupes fetch requests and provides one flexible way to fetch, cache, and revalidate data at the component level. This means all the benefits of Static Site Generation (SSG), Server-Side Rendering (SSR), and Incremental Static Regeneration (ISR) are now available through one API:

// This request should be cached until manually invalidated.

// Similar to `getStaticProps`.

// `force-cache` is the default and can be omitted.

fetch(URL, { cache: ‘force-cache’ });


// This request should be refetched on every request.

// Similar to `getServerSideProps`.

fetch(URL, { cache: ‘no-store’ });


// This request should be cached with a lifetime of 10 seconds.

// Similar to `getStaticProps` with the `revalidate` option.

fetch(URL, { next: { revalidate: 10 } });

In the app directory, you can fetch data inside layouts, pages, and components – including support for streaming responses from the server.

They have enabled ergonomic ways to handle loading and error states and stream in UI as it’s rendered. In a future release, they will be improving and simplifying data mutations, as well.

Pic courtesy:

They’re excited to work with the open-source community, package maintainers, and other companies contributing to the React ecosystem to build for this new era of React and Next.js. The ability to colocate data fetching inside components and ship less JavaScript to the client were two important pieces of community feedback we are excited to include with the app/ directory.

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

Pic courtesy:

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.

Note: 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.


Next.js 13 introduces a powerful new Image component, allowing you to easily display images without layout shift and optimize files on-demand for increased performance.

During the Next.js Community Survey, 70% of respondents told them they used the Next.js Image component in production, and in turn, saw improved Core Web Vitals. With Next.js 13, they’re improving next/image even further.

The new Image component:

  • Ships less client-side JavaScript
  • Easier to style and configure
  • More accessible requiring alt tags by default
  • Aligns with the Web platform
  • Faster because native lazy loading doesn’t require hydration

import Image from ‘next/image’;

import avatar from ‘./lee.png’;


function Home() {

// “alt” is now required for improved accessibility

// optional: image files can be colocated inside the app/ directory

return <Image alt=”leeerob” src={avatar} placeholder=”blur” />;


Upgrading next/image to Next.js 13

The old Image component was renamed to next/legacy/image. They’ve provided a codemod that will automatically update your existing usage of next/image to next/legacy/image. For example, this command would run the codemod on your ./pages directory when run from the root:

npx @next/codemod next-image-to-legacy-image ./pages


Next.js 13 introduces a brand new font system that:

  • Automatically optimizes your fonts, including custom fonts
  • Removes external network requests for improved privacy and performance
  • Built-in automatic self-hosting for any font file
  • Zero layout shift automatically using the CSS size-adjust property

This new font system allows you to conveniently use all Google Fonts with performance and privacy in mind. CSS and font files are downloaded at build time and self-hosted with the rest of your static assets. No requests are sent to Google by the browser.

import { Inter } from ‘@next/font/google’;

const inter = Inter();

<html className={inter.className}>

Custom fonts are also supported, including support for automatic self-hosting, caching, and preloading of font files.

import localFont from ‘@next/font/local’;

const myFont = localFont({ src: ‘./my-font.woff2’ });

<html className={myFont.className}>

You can customize every part of the font loading experience while still ensuring great performance and no layout shift, including the font-display, preloading, fallbacks, and more.


next/link no longer requires manually adding <a> as a child.

This was added as an experimental option in 12.2 and is now the default. In Next.js 13, <Link> always renders an <a> and allows you to forward props to the underlying tag. For example:

import Link from ‘next/link’

// Next.js 12: `<a>` has to be nested otherwise it’s excluded

<Link href=”/about”>




// Next.js 13: `<Link>` always renders `<a>`

<Link href=”/about”>



Upgrading next/link to Next.js 13

To upgrade your links to Next.js 13, they’ve provided a codemod that will automatically update your codebase. For example, this command would run the codemod on your ./pages directory when run from the root:

npx @next/codemod new-link ./pages

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(




display: ‘flex’,

fontSize: 128,

background: ‘white’,

width: ‘100%’,

height: ‘100%’,



Hello, World!





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 ={

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.

For more information and to develop web applications using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – or Skype us: “hkinfosoft”.

To develop custom web apps using React JS, please visit our technology page.

Content Source: