Next.js 15's release candidate (RC) brings several new features and improvements to enhance developer experience and boost application performance.
The Next.js Release Candidate lets you try out the newest features before the stable release hits. If you're eager to test the latest and stay in the loop, you're in the right spot! Let's dive in!
to try it out: npx create-next-app@rc
Here's a rundown of the key updates:
React 19 RC:
Now includes support for React 19 RC, the experimental React Compiler and improvements to hydration error handling.
Meta's React team introduces an experimental compiler designed to deeply understand your code's JavaScript semantics and React's principles. This understanding enables automatic optimizations, reducing the need for manual memoization with functions like useMemo and useCallback. As a result, code becomes simpler, easier to manage and less error-prone.
To enable the React compiler in Next.js
Install babel-plugin-react-compiler:
npm install babel-plugin-react-compiler
To enable this feature, simply add the experimental.reactCompiler option to your next.config.js file.
If desired, you can configure the compiler to operate in "opt-in" mode using the following configuration.
Currently, you can only use the React Compiler in Next.js by adding a Babel plugin, which might slow down the build process.
Hydration error improvements
In Next.js 14, error messages and hydration errors were enhanced. Next.js 15 takes this further by introducing an improved hydration error view. Now, hydration errors provide the error's source code along with suggestions to resolve the issue.
Here's an example of a previous hydration error message from Next.js 14:
In Next.js 15 RC, this has been improved to:
Caching:
Fetch requests, GET Route Handlers and client navigations are now no longer cached by default.
The Next.js App Router initially came with pre-set caching defaults, aiming to offer the best performance out of the box while still allowing customization when needed.
With Next.js 15, its adjusting the default caching behavior for fetch requests, GET Route Handlers and Client Router Cache. Previously cached by default, they will now be uncached by default. However, if you prefer the previous behavior, you can still choose to opt into caching.
fetch Requests are no longer cached by default
fetch('https://...', { cache: 'force-cache' | 'no-store' });
no-store: Always fetch the resource from the remote server without updating the cache.
force-cache: Fetch the resource from the cache if available, or from the remote server if not and update the cache.
In Next.js 14, if no cache option was provided, force-cache was the default, unless a dynamic function or dynamic config option was in use.
In Next.js 15, if no cache option is provided, no-store is the default. This means fetch requests won't be cached by default.
GET Route Handlers are no longer cached by default
In Next.js 14, Route Handlers employing the GET HTTP method were cached by default, unless they utilized a dynamic function or dynamic config option. However, in Next.js 15, GET functions are no longer cached by default.
To enable caching, you can still opt in by using a static route config option such as export dynamic = 'force-static'
Client Router Cache no longer caches Page components by default
In Next.js 15, the client router cache no longer caches Page components by default, with the default staleTime set to 0. This means that during app navigation, the client will always show the latest data from the active Page component(s). However, certain key behaviors will remain the same:
- Shared layout data isn't refetched to support partial rendering.
- Cache is utilized for back/forward navigation to retain scroll position.
- The Loading.js file is cached for 5 minutes or based on the configuration in staleTimes.static.
To revert to the previous Client Router Cache behavior, simply configure the following setting:
Partial Prerendering (Experimental):
Introducing a new Layout and Page configuration option for gradual adoption.
In Next.js 14, developers introduced Partial Prerendering (PPR), an optimization that blends static and dynamic rendering on a single page.
By default, Next.js employs static rendering, except when dynamic functions like cookies(), headers() or uncached data requests are utilized. These APIs switch the entire route to dynamic rendering. With PPR, you can encapsulate dynamic UI components in a Suspense boundary. When a new request arrives, Next.js promptly serves a static HTML shell, then proceeds to render and stream the dynamic parts within the same HTTP request.
To facilitate gradual adoption, we've introduced an experimental_ppr route configuration option. This allows you to selectively enable PPR for specific Layouts and Pages.
To use the new option, you’ll need to set the experimental.ppr config in your next.config.js file to 'incremental':
Once all segments have PPR enabled, you can confidently set the ppr value to true, enabling it for the entire app and all upcoming routes.
next/after (Experimental):
A new API that allows code to run after a response has completed streaming.
When handling a user request, the server typically focuses on tasks directly related to generating the response. However, you might also need to perform tasks like logging, analytics, or syncing with external systems.
Since these tasks don't impact the immediate response, users shouldn't have to wait for them to finish. Yet, in serverless environments, computation halts as soon as the response closes, making it tricky to defer such tasks.
The new experimental API, after(), tackles this challenge by allowing you to schedule tasks to run after the response has finished streaming. This enables secondary tasks to proceed without blocking the primary response.
To utilize after(), simply add experimental.after to your next.config.js file.
Then, import the function in Server Components, Server Actions, Route Handlers or Middleware.
create-next-app Update:
In Next.js 15, developers have refreshed create-next-app with a fresh design.
When you run create-next-app, you'll now encounter a new prompt asking if you want to activate Turbopack for local development, with the default option set to No.
The --turbo flag can be used to enable Turbopack.
For even smoother project initiation, the CLI now includes a new --empty flag. Enabling this flag removes any additional files and styles, giving you a minimal "hello world" page to start with.
Bundling External Packages (Stable):
New configuration options for the App and Pages Router for more flexibility.
Bundling external packages can speed up your application's initial loading. By default, the App Router bundles external packages, but you can exclude specific ones with the new serverExternalPackages configuration option.
In the Pages Router, external packages aren't bundled by default. However, you can specify packages to bundle using the existing transpilePackages option. With this, you need to list each package explicitly.
To simplify configuration between the App and Pages Router, a new option, bundlePagesRouterDependencies, is introduced. This aligns with the App Router's default bundling behavior. You can then use serverExternalPackages to exclude specific packages if needed.
Summary
With these cool new things on the way, Its going to be a game changer in web development. Now you know a bit about them, you can try using them in your own projects. Just keep in mind that the Next15 is still in progress before its final release. For a detailed breakdown of all changes, refer to this source .
Thank you for reading my article.
Have a great day!
Happy coding!