Next.js 13: What Do The New Bleeding-Edge Features Actually Do?

You’ve heard that Next.js 13 is a gamechanger, but…why, exactly? Let’s take a practical, grounded look at what’s new, what’s changed, and what they mean for you as a developer?

Next.js 13 is the first across-the-board attempt to bring together React’s dual identities — The UI Library, and The Architecture. Overnight, all How To Build X With Next.js tutorials have become outdated.

Or have they…?

Actual breaking changes are surprisingly few. You’d only have to change a few lines of JSX and a couple imports for backwards compatibility. But if you want to take advantage of the shiny new features this release brings to the table, your mental model of how a Next app — scratch that, even a React app — works, will have to be updated.

And that’s exactly what we’re doing here, today. Not a mere rundown of beta features (you’ve seen a hundred of those already), but a practical guide that understands the realities and limitations of real-world webdev, and assumes you want to know :

  1. What each new feature in Next.js 13 actually does, beyond what they say on the tin.
  2. How you should lay out your architecture/roadmaps keeping that in mind.
“If you can make it here, you can make it anywhere.”

What’s New?

1. The /app directory

This is the rabbit hole, Alice.

There are considerable changes in how you structure your project going from 12 to 13, and the /app directory is here so you can incrementally adopt these changes. Zero destructive coding.

You can keep your existing /pages directory, but everything you put in /app uses Next.js 13’s beta features by default — server components, complex/nested layouts, streaming, extended fetch API for new & flexible ways to fetch data — and requires you to mind the new conventions.

2. Folder-based routing, and Layouts

One of Next.js’ most recognizable — and polarizing — features has been its file-based routing (as opposed to strictly client-side routing using react-router etc).

Now, it’s a folder-based hierarchy instead. You use folders to define routes, and special files with reserved names — layout.jsx, page.jsx, and loading.jsx — to define UI, with page.jsx being the minimum required.

If you prefer TypeScript, instead.

How does this work?

Let’s consider two scenarios :

  1. If the root of your project / was defined by /pages/index.jsx, now it’s app/page.jsx that exports a default function, Page()
  2. If you had a /pages/dashboard.jsx which imported additional components like Navbar.jsx, this is now /app/dashboard/page.jsx, and you can throw everything this route needs in the same subtree (components, stylesheets, storybook files, unit tests, MDX docs) without needing complex import statements or maintaining a separate folder of shared components.
Colocating related files to route folders.

What you need to know :

Pre-Next.js 13, your options for organized UI design via layouts was either ad-hoc wrapper components, or one global layout at _app.jsx.

Now, though, you have way more control. You can use a layout.jsx file to define the layout for an entire subtree, with a page.jsx for the actual UI. Each segment of your URL can now have different layouts without needing ad-hoc wrappers, or a single, rigid global layout.

To summarize, the exported component in your layout.jsx file contains UI that is:

  1. Shared by the route (every piece of UI you’ve defined in the same folder/subtree).
  2. Stateful, but intelligently avoids unnecessary re-renders when navigating between the route’s sibling URL segments
  3. Able to do data fetching by default. By getting needed data at the layout level for each route segment, you can resolve data waterfalls, or deliberately let them happen and handle optimizations server-side as you see fit. This is the first part of Next.js 13’s solution to the oft-painful waterfall problem (the second being Streaming, but we’ll get to that later. Patience, young padawan.)
Complex combinations of layout.jsx/tsx and page.jsx/tsx files for each route are now possible.

Overall, the developer experience is great if you build lots of Dashboard-y things with Next.js and thus need complex/nested routes with unique UI and fine-grained data fetching at each boundary, while avoiding bottlenecks.

3. Server (and Client) Components

Your mental model of how components work in Next.js has been turned upside down.

Instead of building components that run on the client and use getServerSideProps to implement server-side rendering (SSR), now every single component runs server-side by default (see: this React RFC), and you have to explicitly opt-in to have parts of your UI run client-side as and when you need/want them to — with a module pragma-like statement at the top level.

…to explicitly make sure Next.js sees it as a client component.

But there are plenty of gotchas to consider.

If everything is a server component by default, remember that you won’t be able to use hooks like useState/useEffect, event listeners like onClick() or onChange(), or browser APIs (canvas, fullscreen, clipboard, etc.).

But as an upside, this means you can freely do data fetching in these server components, or include anything that you’d normally have as backend-only code, but still render out UI as JSX as usual!

What you need to know:

1. You can now use JSX for templating.

Talk about a throwback to the PHP days!

Have your components run entirely on the server — reaping the benefits of faster fetches, fetches that start without waiting on JS to parse and render, and less JS shipped — and use JSX to render out their results, usinguse client to do fine-grained, precise opt-ins when you need a specific part of the UI to have interactivity.

💡 A<Container> of ToDos could be a server component, do data fetching on the server, and then use JSX to template each ToDo into its own <Card> client component with edit/delete/mark-as-complete controls.

2. Alternative patterns to the Context API.

No hooks in server components means no useContext. However, with the new features afforded to you by Layouts + Server Components, you might not need the Context API. Here’s a few patterns you can use instead:

Scenario A : Your layout.jsx can freely fetch data you need at a subtree/route segment level, and all children components/UI it wraps can access that data.

Scenario B : Embrace Prop Drilling. Seriously. It isn’t as much of an anti-pattern anymore in the world of Next.js 13, since you’re getting massive gains from having components rendered on your server, which is typically much faster than your client.

Scenario C : For state management, if you’re using a third-party library (like Redux) that needs to wrap the app with a <Provider>, just have your route’s layout.jsx be a Server Component that wraps your client provider…that wraps children/UI in turn.

3. Your favorite UI Library might not work.

Server Components currently do not support any CSS-in-JS, and unfortunately, this isn’t something that can be solved without their library maintainers updating these frameworks to support Server Components and Streaming SSR.

So stay tuned, but remember that in the meantime anything that uses emotion, styled-jsx, styled-components etc. under the hood will not work, and any UI libraries dependent on them will have to be limited to client components alone.

💡Pro tip: There has never been a better time to learn TailwindCSS.

4. Mutations (write operations) inside Server Components are currently iffy.

While data fetching (i.e. read operations) has an elegant, flexible solution in Next.js 13 Server Components, the other half of working with data, mutations (i.e. write operations; creates, updates, deletes) currently does not. Proposals for it are currently being worked on, but in the meantime, you’ll have to use the Next router and implement this hacky pattern:

An example to update a ToDo.

💡 Using refresh() does not affect browser history, but anything from the root layout down will be re-rendered. Any client-side state is not lost, however.

5. A good rule of thumb.

Use Server Components if:

  • You need to fetch data from an API/database and need to store access tokens/API keys for it.
  • You’re using tech that requires shipping heavy JavaScript bundles on the frontend — GraphQL clients are a very common example. These can just live on the server now, meaning users access your page much faster.

Use Client Components if:

  • You need interactivity. useState/useEffect, other custom hooks, event listeners, accessing the clipboard, and so on.
  • If you’re maintaining/incrementally updating a legacy app that still uses class components.

4. Streaming HTML

Exactly what it sounds like. You can ‘stream’, aka incrementally send UI from the server to the client, to enable progressive rendering of your components and pages. This way, expensive data fetching operations do not bottleneck the rendering of a responsive UI, and your users get much, much better UX.

How does this work?

Next.js 13 gives you two ways to implement streaming SSR.

The first is by using the /app directory again, specifically, one of those special, reserved files, loading.jsx. Just create one of those files per route segment/subtree, and have it export by default a component that shows some sort of loading state — a fancy spinner, skeleton, animation, or just some text — for the content (page.jsx) of that route.

A minimal example would be:

As you can tell, Next.js 13’s new ability to do nested routes/layouts mean you can define this with granularity for each route segment.

The real magic happens when Next.js 13 intelligently swaps the UI/JSX of this loading.jsx with that of the actual page.jsx for that route segment, as soon as all data fetching for that route segment has finished.

The second way is a little less bleeding edge: Suspense Boundaries.

A Suspense wraps JSX for some UI that needs data fetching. While the component that it wraps is fetching data, the JSX in the fallback prop is shown. When data fetching is complete and the component is ready to load, it is rendered instead of the fallback.

Here’s a minimal example:

layout.jsx and Suspense are two different ways of doing the same thing.

What you need to know :

Basically, streaming with layout.jsx or Suspense is a massive UI/UX win, as you simultaneously:

  1. Improve Time To First Byte/First Contentful Paint so your users interact with your app faster, and
  2. Make your app resilient to inconsistent network speeds, or unexpected errors on the backend.

However, you absolutely need to be aware of a significant drawback.

Streaming HTML directly without the need for getServerSideProps means returning HTML-spec compliant status codes for specific errors/redirects (like 307, 308 etc.) based on the data is no longer possible.

5. SSR/SSG/ISR with the extended fetch API

Server Side Rendering (SSR), Static Site Generation (SSG), and Incremental Static Regeneration (ISR) work better than ever in Next.js 13, boosted by a solution built on top of the good ol’ fetch()API.

How does this work?

Does your component need data? Extract data fetching logic to a function, then call that directly inside components with the necessary async/await boilerplate. It’s that easy.

For Server Components

You can fetch data directly in layout.jsx and page.jsx files, and it’s a simple pattern.

For Client Components

Client Components do not yet support the extended fetch() API. You could still use it, but you might get unintentional re-renders.

So you have two options here:

  1. Use SWR/react-query. These are fast, battle-tested third-party data fetching libraries with great developer experience, and probably the default solution you should consider these days.
  2. This is more getting into new, bleeding edge React features (and that’s a topic that will require its own article!), but….you could use the new, special ‘use’ hook that unwraps promises natively, can be used anywhere, and conditionally.

Wrap the new fetch() in a utility function, and use the… use hook, to wrap it.

For SSR/SSG/ISR :

No need for patterns like getServerSideProps, getStaticProps/getStaticPaths anymore. Fetch data inside the component that needs it, instead of passing data down as props to children. Behind the scenes, React and Next.js will cache and dedupe requests to optimize bandwidth usage, and your app performance.

You indicate whether you want SSR, SSG, or ISR with an options/config object tacked on to your fetch call.

SSR : cache: “no-store” indicates we want auto-caching turned off for this query, and want data fetched afresh every time we call it…aka, vanilla server-side rendering.
SSG : Simply take that cache config off at the end of your fetch call, and Next.js will automatically cache the data returned by fetchData until manually revalidated…aka, vanilla static site generation.
Also for SSG: getStaticPaths has been replaced by generateStaticParams, and is overall simpler to use.
ISR : Yet another options object to go along with your fetch call, this time { next: { revalidate: number_in_seconds }} for incremental static regeneration.

7. Turbopack

Put simply, the web is about to get much, much faster.

Webpack has enjoyed immense success over the years because it was the only bundler that supported CommonJS and code splitting equally well, making it a natural fit for React and React-based frameworks….but Next.js 13 introduces Turbopack, a drop-in replacement for Webpack. This is a shift away from the Javascript-based bundler to a native Rust-powered one, developed in collaboration with Webpack’s maintainer, and the benchmarks speak for themselves.

It is important to note that most of these wins are brought on by Turbo’s remote caching — meaning you will see massive performance increases in use-cases where optimizing caching would help, i.e. large projects with hundreds of modules, but less so in your basic ToDo apps. Manage your expectations accordingly!

If you want, try out Turbopack’s alpha release with the –turbo feature flag for next dev in package.json.

“scripts”: {
…
 “dev”: “next dev --turbo”,
…
}

Covering Turbopack in detail is outside the scope of this article, but feel free to read up on it here.

8. Other stuff

  • next/image — The new Next.js <Image> component, with better image optimization on-the-fly, better a11y because alt tags are now required by default, less client-side JavaScript shipped, easier and more intuitive styling/config, and native lazy-loading for your images without needing hydration. To update your <Image> tags for Next.js 13, check out this codemod that trivializes the process of fixing your imports.
  • next/link — The new Next.js<Link> component. Far more intuitive to use now, without needing that pesky nested <a> tag as a child. Again, you can use this codemod to make upgrading a cakewalk.
  • next/font — a brand new font system, delivering automatic font optimization, the possibility of easily including custom fonts, all with zero external network requests for improved privacy and performance.
These fonts will be downloaded at build time, and self-hosted with the rest of your static assets. No request to Google will be made by your app at runtime.

Now, for the moment of truth.

Should I Upgrade To Next.js 13?

If you mean actually using and taking advantage of all the shiny new features you now have…I’d advise waiting.

Next.js 13 is very, very early in beta to the point where it could almost be called an alpha. It extensively uses bleeding-edge features from new React that are barely out of the RFC stage, and often doesn’t even implement them fully. Developer Experience is, frankly, not great right now. The docs are nonexistent, there are bugs and nasty gotchas that can blow up your code, and error reporting isn’t quite there yet either.

If you mean playing around with it in your local machine though, go right ahead! This release is a little window into the future, and it makes Next.js even more of a “robust backend that just so happens to have a competent frontend” framework. As long as you manage your expectations about its current state.

The verdict? Don’t use it in production yet, but definitely try it out, and get hyped. There’s so much that’s exciting here, and I personally can’t wait for the stable release.

Build apps with reusable components like Lego

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

→ Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

→ Micro-Frontends

→ Design System

→ Code-Sharing and reuse

→ Monorepo

Learn more

Next.js 13: What Do The New Bleeding-Edge Features Actually Do? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.


This content originally appeared on Bits and Pieces - Medium and was authored by Prithwish Nath

You’ve heard that Next.js 13 is a gamechanger, but…why, exactly? Let’s take a practical, grounded look at what’s new, what’s changed, and what they mean for you as a developer?

Next.js 13 is the first across-the-board attempt to bring together React’s dual identities — The UI Library, and The Architecture. Overnight, all How To Build X With Next.js tutorials have become outdated.

Or have they…?

Actual breaking changes are surprisingly few. You’d only have to change a few lines of JSX and a couple imports for backwards compatibility. But if you want to take advantage of the shiny new features this release brings to the table, your mental model of how a Next app — scratch that, even a React app — works, will have to be updated.

And that’s exactly what we’re doing here, today. Not a mere rundown of beta features (you’ve seen a hundred of those already), but a practical guide that understands the realities and limitations of real-world webdev, and assumes you want to know :

  1. What each new feature in Next.js 13 actually does, beyond what they say on the tin.
  2. How you should lay out your architecture/roadmaps keeping that in mind.
“If you can make it here, you can make it anywhere.”

What’s New?

1. The /app directory

This is the rabbit hole, Alice.

There are considerable changes in how you structure your project going from 12 to 13, and the /app directory is here so you can incrementally adopt these changes. Zero destructive coding.

You can keep your existing /pages directory, but everything you put in /app uses Next.js 13's beta features by default — server components, complex/nested layouts, streaming, extended fetch API for new & flexible ways to fetch data — and requires you to mind the new conventions.

2. Folder-based routing, and Layouts

One of Next.js’ most recognizable — and polarizing — features has been its file-based routing (as opposed to strictly client-side routing using react-router etc).

Now, it’s a folder-based hierarchy instead. You use folders to define routes, and special files with reserved names — layout.jsx, page.jsx, and loading.jsx — to define UI, with page.jsx being the minimum required.

If you prefer TypeScript, instead.

How does this work?

Let’s consider two scenarios :

  1. If the root of your project / was defined by /pages/index.jsx, now it’s app/page.jsx that exports a default function, Page()
  2. If you had a /pages/dashboard.jsx which imported additional components like Navbar.jsx, this is now /app/dashboard/page.jsx, and you can throw everything this route needs in the same subtree (components, stylesheets, storybook files, unit tests, MDX docs) without needing complex import statements or maintaining a separate folder of shared components.
Colocating related files to route folders.

What you need to know :

Pre-Next.js 13, your options for organized UI design via layouts was either ad-hoc wrapper components, or one global layout at _app.jsx.

Now, though, you have way more control. You can use a layout.jsx file to define the layout for an entire subtree, with a page.jsx for the actual UI. Each segment of your URL can now have different layouts without needing ad-hoc wrappers, or a single, rigid global layout.

To summarize, the exported component in your layout.jsx file contains UI that is:

  1. Shared by the route (every piece of UI you’ve defined in the same folder/subtree).
  2. Stateful, but intelligently avoids unnecessary re-renders when navigating between the route’s sibling URL segments
  3. Able to do data fetching by default. By getting needed data at the layout level for each route segment, you can resolve data waterfalls, or deliberately let them happen and handle optimizations server-side as you see fit. This is the first part of Next.js 13’s solution to the oft-painful waterfall problem (the second being Streaming, but we’ll get to that later. Patience, young padawan.)
Complex combinations of layout.jsx/tsx and page.jsx/tsx files for each route are now possible.

Overall, the developer experience is great if you build lots of Dashboard-y things with Next.js and thus need complex/nested routes with unique UI and fine-grained data fetching at each boundary, while avoiding bottlenecks.

3. Server (and Client) Components

Your mental model of how components work in Next.js has been turned upside down.

Instead of building components that run on the client and use getServerSideProps to implement server-side rendering (SSR), now every single component runs server-side by default (see: this React RFC), and you have to explicitly opt-in to have parts of your UI run client-side as and when you need/want them to — with a module pragma-like statement at the top level.

…to explicitly make sure Next.js sees it as a client component.

But there are plenty of gotchas to consider.

If everything is a server component by default, remember that you won’t be able to use hooks like useState/useEffect, event listeners like onClick() or onChange(), or browser APIs (canvas, fullscreen, clipboard, etc.).

But as an upside, this means you can freely do data fetching in these server components, or include anything that you’d normally have as backend-only code, but still render out UI as JSX as usual!

What you need to know:

1. You can now use JSX for templating.

Talk about a throwback to the PHP days!

Have your components run entirely on the server — reaping the benefits of faster fetches, fetches that start without waiting on JS to parse and render, and less JS shipped — and use JSX to render out their results, usinguse client to do fine-grained, precise opt-ins when you need a specific part of the UI to have interactivity.

💡 A<Container> of ToDos could be a server component, do data fetching on the server, and then use JSX to template each ToDo into its own <Card> client component with edit/delete/mark-as-complete controls.

2. Alternative patterns to the Context API.

No hooks in server components means no useContext. However, with the new features afforded to you by Layouts + Server Components, you might not need the Context API. Here’s a few patterns you can use instead:

Scenario A : Your layout.jsx can freely fetch data you need at a subtree/route segment level, and all children components/UI it wraps can access that data.

Scenario B : Embrace Prop Drilling. Seriously. It isn’t as much of an anti-pattern anymore in the world of Next.js 13, since you’re getting massive gains from having components rendered on your server, which is typically much faster than your client.

Scenario C : For state management, if you’re using a third-party library (like Redux) that needs to wrap the app with a <Provider>, just have your route’s layout.jsx be a Server Component that wraps your client provider…that wraps children/UI in turn.

3. Your favorite UI Library might not work.

Server Components currently do not support any CSS-in-JS, and unfortunately, this isn’t something that can be solved without their library maintainers updating these frameworks to support Server Components and Streaming SSR.

So stay tuned, but remember that in the meantime anything that uses emotion, styled-jsx, styled-components etc. under the hood will not work, and any UI libraries dependent on them will have to be limited to client components alone.

💡Pro tip: There has never been a better time to learn TailwindCSS.

4. Mutations (write operations) inside Server Components are currently iffy.

While data fetching (i.e. read operations) has an elegant, flexible solution in Next.js 13 Server Components, the other half of working with data, mutations (i.e. write operations; creates, updates, deletes) currently does not. Proposals for it are currently being worked on, but in the meantime, you’ll have to use the Next router and implement this hacky pattern:

An example to update a ToDo.
💡 Using refresh() does not affect browser history, but anything from the root layout down will be re-rendered. Any client-side state is not lost, however.

5. A good rule of thumb.

Use Server Components if:

  • You need to fetch data from an API/database and need to store access tokens/API keys for it.
  • You’re using tech that requires shipping heavy JavaScript bundles on the frontend — GraphQL clients are a very common example. These can just live on the server now, meaning users access your page much faster.

Use Client Components if:

  • You need interactivity. useState/useEffect, other custom hooks, event listeners, accessing the clipboard, and so on.
  • If you’re maintaining/incrementally updating a legacy app that still uses class components.

4. Streaming HTML

Exactly what it sounds like. You can ‘stream’, aka incrementally send UI from the server to the client, to enable progressive rendering of your components and pages. This way, expensive data fetching operations do not bottleneck the rendering of a responsive UI, and your users get much, much better UX.

How does this work?

Next.js 13 gives you two ways to implement streaming SSR.

The first is by using the /app directory again, specifically, one of those special, reserved files, loading.jsx. Just create one of those files per route segment/subtree, and have it export by default a component that shows some sort of loading state — a fancy spinner, skeleton, animation, or just some text — for the content (page.jsx) of that route.

A minimal example would be:

As you can tell, Next.js 13’s new ability to do nested routes/layouts mean you can define this with granularity for each route segment.

The real magic happens when Next.js 13 intelligently swaps the UI/JSX of this loading.jsx with that of the actual page.jsx for that route segment, as soon as all data fetching for that route segment has finished.

The second way is a little less bleeding edge: Suspense Boundaries.

A Suspense wraps JSX for some UI that needs data fetching. While the component that it wraps is fetching data, the JSX in the fallback prop is shown. When data fetching is complete and the component is ready to load, it is rendered instead of the fallback.

Here’s a minimal example:

layout.jsx and Suspense are two different ways of doing the same thing.

What you need to know :

Basically, streaming with layout.jsx or Suspense is a massive UI/UX win, as you simultaneously:

  1. Improve Time To First Byte/First Contentful Paint so your users interact with your app faster, and
  2. Make your app resilient to inconsistent network speeds, or unexpected errors on the backend.

However, you absolutely need to be aware of a significant drawback.

Streaming HTML directly without the need for getServerSideProps means returning HTML-spec compliant status codes for specific errors/redirects (like 307, 308 etc.) based on the data is no longer possible.

5. SSR/SSG/ISR with the extended fetch API

Server Side Rendering (SSR), Static Site Generation (SSG), and Incremental Static Regeneration (ISR) work better than ever in Next.js 13, boosted by a solution built on top of the good ol’ fetch()API.

How does this work?

Does your component need data? Extract data fetching logic to a function, then call that directly inside components with the necessary async/await boilerplate. It’s that easy.

For Server Components

You can fetch data directly in layout.jsx and page.jsx files, and it’s a simple pattern.

For Client Components

Client Components do not yet support the extended fetch() API. You could still use it, but you might get unintentional re-renders.

So you have two options here:

  1. Use SWR/react-query. These are fast, battle-tested third-party data fetching libraries with great developer experience, and probably the default solution you should consider these days.
  2. This is more getting into new, bleeding edge React features (and that’s a topic that will require its own article!), but….you could use the new, special ‘use’ hook that unwraps promises natively, can be used anywhere, and conditionally.

Wrap the new fetch() in a utility function, and use the… use hook, to wrap it.

For SSR/SSG/ISR :

No need for patterns like getServerSideProps, getStaticProps/getStaticPaths anymore. Fetch data inside the component that needs it, instead of passing data down as props to children. Behind the scenes, React and Next.js will cache and dedupe requests to optimize bandwidth usage, and your app performance.

You indicate whether you want SSR, SSG, or ISR with an options/config object tacked on to your fetch call.

SSR : cache: “no-store” indicates we want auto-caching turned off for this query, and want data fetched afresh every time we call it…aka, vanilla server-side rendering.
SSG : Simply take that cache config off at the end of your fetch call, and Next.js will automatically cache the data returned by fetchData until manually revalidated…aka, vanilla static site generation.
Also for SSG: getStaticPaths has been replaced by generateStaticParams, and is overall simpler to use.
ISR : Yet another options object to go along with your fetch call, this time { next: { revalidate: number_in_seconds }} for incremental static regeneration.

7. Turbopack

Put simply, the web is about to get much, much faster.

Webpack has enjoyed immense success over the years because it was the only bundler that supported CommonJS and code splitting equally well, making it a natural fit for React and React-based frameworks….but Next.js 13 introduces Turbopack, a drop-in replacement for Webpack. This is a shift away from the Javascript-based bundler to a native Rust-powered one, developed in collaboration with Webpack’s maintainer, and the benchmarks speak for themselves.

It is important to note that most of these wins are brought on by Turbo’s remote caching — meaning you will see massive performance increases in use-cases where optimizing caching would help, i.e. large projects with hundreds of modules, but less so in your basic ToDo apps. Manage your expectations accordingly!

If you want, try out Turbopack’s alpha release with the --turbo feature flag for next dev in package.json.

“scripts”: {
…
 “dev”: “next dev --turbo”,
…
}

Covering Turbopack in detail is outside the scope of this article, but feel free to read up on it here.

8. Other stuff

  • next/image — The new Next.js <Image> component, with better image optimization on-the-fly, better a11y because alt tags are now required by default, less client-side JavaScript shipped, easier and more intuitive styling/config, and native lazy-loading for your images without needing hydration. To update your <Image> tags for Next.js 13, check out this codemod that trivializes the process of fixing your imports.
  • next/link — The new Next.js<Link> component. Far more intuitive to use now, without needing that pesky nested <a> tag as a child. Again, you can use this codemod to make upgrading a cakewalk.
  • next/font — a brand new font system, delivering automatic font optimization, the possibility of easily including custom fonts, all with zero external network requests for improved privacy and performance.
These fonts will be downloaded at build time, and self-hosted with the rest of your static assets. No request to Google will be made by your app at runtime.

Now, for the moment of truth.

Should I Upgrade To Next.js 13?

If you mean actually using and taking advantage of all the shiny new features you now have…I’d advise waiting.

Next.js 13 is very, very early in beta to the point where it could almost be called an alpha. It extensively uses bleeding-edge features from new React that are barely out of the RFC stage, and often doesn’t even implement them fully. Developer Experience is, frankly, not great right now. The docs are nonexistent, there are bugs and nasty gotchas that can blow up your code, and error reporting isn’t quite there yet either.

If you mean playing around with it in your local machine though, go right ahead! This release is a little window into the future, and it makes Next.js even more of a “robust backend that just so happens to have a competent frontend” framework. As long as you manage your expectations about its current state.

The verdict? Don’t use it in production yet, but definitely try it out, and get hyped. There’s so much that’s exciting here, and I personally can’t wait for the stable release.

Build apps with reusable components like Lego

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

→ Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

→ Micro-Frontends

→ Design System

→ Code-Sharing and reuse

→ Monorepo

Learn more

Next.js 13: What Do The New Bleeding-Edge Features Actually Do? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.


This content originally appeared on Bits and Pieces - Medium and was authored by Prithwish Nath


Print Share Comment Cite Upload Translate Updates
APA

Prithwish Nath | Sciencx (2022-11-08T12:05:27+00:00) Next.js 13: What Do The New Bleeding-Edge Features Actually Do?. Retrieved from https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/

MLA
" » Next.js 13: What Do The New Bleeding-Edge Features Actually Do?." Prithwish Nath | Sciencx - Tuesday November 8, 2022, https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/
HARVARD
Prithwish Nath | Sciencx Tuesday November 8, 2022 » Next.js 13: What Do The New Bleeding-Edge Features Actually Do?., viewed ,<https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/>
VANCOUVER
Prithwish Nath | Sciencx - » Next.js 13: What Do The New Bleeding-Edge Features Actually Do?. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/
CHICAGO
" » Next.js 13: What Do The New Bleeding-Edge Features Actually Do?." Prithwish Nath | Sciencx - Accessed . https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/
IEEE
" » Next.js 13: What Do The New Bleeding-Edge Features Actually Do?." Prithwish Nath | Sciencx [Online]. Available: https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/. [Accessed: ]
rf:citation
» Next.js 13: What Do The New Bleeding-Edge Features Actually Do? | Prithwish Nath | Sciencx | https://www.scien.cx/2022/11/08/next-js-13-what-do-the-new-bleeding-edge-features-actually-do/ |

Please log in to upload a file.



There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.

Related Posts