Next.
js 15 RC
new changes!
Created by JS Mastery -- Visit [Link] for more
[Link] 15
The [Link] 15 Release Candidate (RC) is now
available.
Do note that, RC stands for Release Candidate,
meaning it will move to GA, or General Availability,
later this year while they wait for React 19 to be fully
supported.
[Link] JavaScript Mastery
[Link] 15
Here are the major changes:
React
Support for the React 19 RC, React Compiler
(Experimental), and hydration error improvements
Caching
fetch requests, GET Route Handlers, and client
navigations are no longer cached by default
Partial Prerendering (Experimental):
New Layout and Page config option for incremental
adoption
next/after (Experimental)
New API to execute code after a response has finished
streaming
[Link] JavaScript Mastery
[Link] 15
create-next-app updates
Updated design and a new flag to enable Turbopack
in local development
Bundling external packages (Stable)
New config options for App and Pages Router
[Link] JavaScript Mastery
...before you go
Do you want to see & learn how features like PPR,
next/after, and React 19 work in real projects?
Then our special course on [Link] has got you
covered.
The Ultimate
Next 14 Course
It teaches everything from the ground up, giving you
hands-on practice and a strong foundation in each
concept that goes beyond the basics.
Check it out and take your skills to the next level
[Link] JavaScript Mastery
Changes
React 19 RC
The [Link] App Router is built on the React canary
channel for frameworks, enabling developers to use
and provide feedback on new React APIs before the
v19 release.
The [Link] 15 RC now includes support for React 19
features, such as the `use` hook (which replaces many
other hooks) and the long-awaited ability to pass `ref`
as a prop.
It also includes support for new features for both the
client and server like Actions.
Read the [Link] 15 upgrade guide, the React 19 upgrade guide,
and watch the React Conf Keynote to learn more.
[Link] JavaScript Mastery
Changes
Experimental React Compiler
The React Compiler is a new experimental compiler
created by the React team at Meta.
The compiler understands your code at a deep level
through its understanding of plain JavaScript
semantics and the Rules of React, which allows it to
add automatic optimizations to your code.
The compiler reduces the amount of manual
memoization developers have to do through APIs such
as useMemo and useCallback - making code simpler,
easier to maintain, and less error prone.
With [Link] 15, they’ve added support for the React
Compiler.
[Link] JavaScript Mastery
Changes
Hydration error improvements
[Link] 14.1 improved error messages and addressed
hydration errors. Building on this, [Link] 15 introduces
an enhanced hydration error view for better clarity.
Hydration errors now display the source code of the
error with suggestions on how to address the issue.
For example, this was a previous hydration error
message in [Link] 14.1:
[Link] JavaScript Mastery
Changes
[Link] 15 RC has improved this to:
[Link] JavaScript Mastery
Changes
Caching updates
The [Link] App Router launched with opinionated
caching defaults, designed to offer the most
performant option by default while allowing
developers to opt out when necessary.
The [Link] team re-evaluated the caching rules and
how they work with features like Partial Prerendering
(PPR) and third-party libraries that use fetch.
With [Link] 15, they’re changing how caching works
for fetch requests, GET Route Handlers, and Client
Router Cache. Before, things were cached by default,
now they won’t be unless you choose to. If you prefer
the old way, you can still pick it.
[Link] JavaScript Mastery
Changes
fetch Requests are no longer cached by default
[Link] uses the Web fetch API cache option to
configure how a server-side fetch request interacts
with the framework's persistent HTTP cache:
no-store - fetch a resource from a remote server
on every request and do not update the cach
force-cache - fetch a resource from the cache (if it
exists) or a remote server and update the cache
In [Link] 14, force-cache was used by default if
a cache option was not provided, unless a dynamic
function or dynamic config option was used.
[Link] JavaScript Mastery
Changes
In [Link] 15, no-store is used by default if
a cache option is not provided. This means fetch
requests will not be cached by default.
[Link] JavaScript Mastery
Changes
GET Route Handlers are no longer cached by
default
In Next 14, Route Handlers that used the GET HTTP
method were cached by default unless they used a
dynamic function or dynamic config option.
In [Link] 15, GET functions are not cached by default.
You can still opt into caching using a static route
config option such as export dynamic = 'force-static'.
Special Route Handlers like [Link], opengraph-
[Link], and [Link], and other metadata
files remain static by default unless they use dynamic
functions or dynamic config options.
[Link] JavaScript Mastery
Changes
Client Router Cache no longer caches Page
components by default
In [Link] 14.2.0, they introduced an experimental
staleTimes flag to allow custom configuration of
the Router Cache.
In [Link] 15, this flag still remains accessible, but they
are changing the default behavior to have
a staleTime of 0 for Page segments.
This means that as you navigate around your app, the
client will always reflect the latest data from the Page
component(s) that become active as part of the
navigation.
[Link] JavaScript Mastery
Changes
However, there are still important behaviors that
remain unchanged:
Shared layout data won't be refetched from the
server to continue to support partial rendering
Back/forward navigation will still restore from
cache to ensure the browser can restore scroll
position
[Link] will remain cached for 5 minutes (or the
value of the [Link] configuration).
[Link] JavaScript Mastery
Changes
Incremental adoption of Partial Prerendering
In [Link] 14, they introduced Partial Prerendering
(PPR) - an optimization that combines static and
dynamic rendering on the same page.
[Link] currently defaults to static rendering unless you
use dynamic functions such as cookies(), headers(),
and uncached data requests.
These APIs opt an entire route into dynamic rendering.
With PPR, you can wrap any dynamic UI in a Suspense
boundary. When a new request comes in, [Link] will
immediately serve a static HTML shell, then render and
stream the dynamic parts in the same HTTP request.
Learn more about Partial Prerendering.
[Link] JavaScript Mastery
Changes
Executing code after a response with next/after
When processing a user request, the server typically
performs tasks directly related to computing the
response.
However, you may need to perform tasks such as
logging, analytics, and other external system
synchronization.
Since these tasks are not directly related to the
response, the user should not have to wait for them to
complete.
Deferring the work after responding to the user poses
a challenge because serverless functions stop
computation immediately after the response is closed
[Link] JavaScript Mastery
Changes
after() is a new experimental API that solves this
problem by allowing you to schedule work to be
processed after the response has finished streaming,
enabling secondary tasks to run without blocking the
primary response.
[Link] JavaScript Mastery
Changes
create-next-app updates
For [Link] 15, there’s an updated create-next-app
design and an option to select Turbopack as a
bundler in dev mode.
[Link] JavaScript Mastery
Changes
Optimizing bundling of external packages
Bundling external packages can improve the cold
start performance of your application. In the App
Router, external packages are bundled by default, and
you can opt-out specific packages using the
new serverExternalPackages config option.
In the Pages Router, external packages are not
bundled by default, but you can provide a list of
packages to bundle using the existing
transpilePackages option.
With this configuration option, you need to specify
each package
[Link] JavaScript Mastery
Changes
To unify configuration between App and Pages Router,
we’re introducing a new option,
bundlePagesRouterDependencies to match the
default automatic bundling of the App Router.
You can then use serverExternalPackages to opt-out
specific packages, if needed.
Learn more about optimizing external packages.
[Link] JavaScript Mastery
