Next.js 14 released as Vercel aims for “dynamic at the speed of static” – but are new features really stable?

Next.js 14 released as Vercel aims for “dynamic at the speed of static” – but are new features really stable?

Vercel has released Next.js 14 with performance improvements, stable Server Actions, and a preview of a feature called partial prerendering which combines static and streaming content.

According to Next.js inventor and Vercel CEO Guillermo Rauch, speaking at the Next.js Conf, in San Francisco and online yesterday, “Next.js 14 comes with no new APIs.” The main changes are performance improvements in the Turbopack bundler, a replacement for the widely used Webpack, and that Server Actions, experimental in Next.js 13, are now declared to be stable.

Server Actions are an additional feature of React Server Components. Server Components render HTML with dynamic content on the server instead of relying on JavaScript running in the client to retrieve dynamic content. Server Actions are defined in Server Components and called from the client, for purposes including form submissions, data updates and cache revalidation. A critical feature is that “Mutating data, re-rendering the page, or redirecting can happen in one network roundtrip, ensuring the correct data is displayed on the client, even if the upstream provider is slow,” according to the Next.js 14 introductory post.

The claim that Server Actions is stable is curious, in that they are not stable in React, on which Next.js is based. They require the Canary release channel in React, explained by the React team as an officially supported channel for “new features as soon as their design is close to final, before they’re released in a stable version.” The Next.js claim rests on the React team saying that “React Server Components are ready to be adopted by frameworks” even though they are not in the React stable release channel. Server Actions now have the same status.

Guillermo Rauch on stage at the Next.js Conf yesterday

The React team said on X this week that “Server Actions are now in React Canary, ready for frameworks and libraries to adopt.” In practice though, this seems to mean, ready for Next.js. The Next.js framework has a de facto special status in React, with references to the Next.js documentation in place of React documentation in some cases. Some are unhappy about this. A comment to the React team on X said “You are not Next.js. Come back to yourself.”

In some cases the React documentation simply references Next.js documentation

Server Components and Server Actions use a feature of Next.js called the App Router. This is an alternative to the older Pages Router and the documentation states: “The Pages Router is still supported in newer versions of Next.js, but we recommend migrating to the new App Router to leverage React’s latest features.” The migration to App Router is a fundamental change that gives Next.js a different architecture.

The reason for these changes is to give developers flexibility over what is rendered on the client and what is rendered on the server. Rauch said that the original concept of sending static content to the client alongside a big JavaScript bundle that then retrieved dynamic content was flawed, since the dynamic content retrieval could spoil performance. A new feature, now in alpha, called Partial Prerendering is the latest effort to improve this. The goal, said Rauch, is “dynamic at the speed of static.”

This new feature uses an existing feature of React called Suspense, elements which display temporary content such as a loading message or busy icon, until the final content appears.  Partial prerendering serves static HTML content immediately, and uses streaming to add dynamic content within Suspense elements, in the same HTTP request as the static content. Partial Prerendering is a “compiler optimization for dynamic content with a fast initial static response”, the aim being to improve performance without requiring the developer to learn new APIs.

Next.js 14 also improves the performance of the Turbopack bundler, the claim being up to 53.3 percent faster local server startup during development, and up to 94.7 percent faster code updates using a hot reload feature called Fast Refresh. Turbopack though is still not stable, currently passing 90 percent of integration tests. “Once we hit 100% of tests passing, we’ll move Turbopack to stable in an upcoming minor release,” the team states.

Unlike Next.js 13 released last year, which introduced the App Router, version 14 is an incremental improvement which does not require rethinking application architecture. That makes it a strong release; though developers remain concerned about some aspects of the framework. One common report is that Next.js works best when hosted by Vercel, which is understandable but problematic for those who do not want to be hooked to one hosting vendor. Another is the cosy relationship between React and Next.js. “I would feel more comfortable if React belonged to an open foundation. But short of that, it would be nice at least if they were more collaborative than they’ve been since joining Vercel,” said React trainer Kent C Dodds in a post on “Why I won’t use Next.js”. Dodds also questioned Vercel’s claims of “stable” when using canary releases of React. “I’ve heard from a lot of people who have tried that their experience with Next.js’s App Router has been far from positive and I think it’s largely because of its incompleteness. They’re the canaries,” he said.