Next.js Tip: Active state for navigation links When you change routes, update the background color of a navbar item by looking at the current URL. Server components 🤝 client components

✨ Introducing Typescript support for next.config.js in Next.js 15 h/t to @devjiwonchoi for his first major ship as a member of the Next.js team. What an exciting start! ◆ Native support for next.config.ts (and other TS file extensions). ◆ HMR on config changes. ◆ Available soon on next@canary and the next Next.js 15 RC.

Next.js Tip: Route Groups Display one layout for most of your app (like this dashboard) but eject from the layout to style other routes differently (like /login). ↳ app/layout.tsx ↳ app/login.tsx (ejected) ↳ app/(dashboard)/layout.tsx ↳ app/(dashboard)/page.tsx

WorkOS incrementally migrated their Next.js SPA from Pages → App Router. They didn't move everything to RSC. Instead, they kept using React Query. They shifted auth / feature flags to RSC to remove loading states and layout shift. Best of both worlds!

Here's where we're headed with caching in Next.js. Last month, we shipped a release candidate for v15, which starts to address some of the community feedback on caching. tl;dr many parts are no longer cached by default. In Next.js 15, if I make a fetch to some API, or make a database query, the result is not cached. This is something dynamic. If you want to cache the data, you can opt-in to this behavior. You need to be explicit. I've seen a few questions floating around that I'd like to clarify 😁 What is prerendering? Prerendering is where we try to generate a static HTML page during `next build`. This is separate from caching data fetching or database queries. Today, there's "all of nothing" prerendering. Either your entire page is static, or it's dynamic from using a function that reads the incoming request. Ideally, we could have both together: send the static parts of the page to all users, while streaming the dynamic parts that are unique to the user. Why is local development different than production? When you're running your local dev server, and you reload the page, your components fetch new data—the results are not cached. You expect to see fresh data. In production, you might want to prerender the entire page to HTML and serve the same rendered page to all users. When you create a production build, Next.js tries to prerender the application routes (since Next.js 9). In the Pages Router, this happens automatically when you don't use `getServerSideProps`. You can do additional data fetching for a static route using `getStaticProps`. Using `getServerSideProps` will opt you into dynamically rendering the route. In the App Router, and with Server Components, you can fetch data from components. But just because I'm fetching data, doesn't always mean I want that component to be dynamically rendered. Some of my Server Components should be able to be prerendered to static HTML. This isn't as explicit as the Pages Router APIs. Your page only becomes dynamically rendered when you read something from the incoming request. For example, reading `searchParams`, `cookies`, or `headers`. Doing a `fetch` does not automatically make the page dynamic today, because you might want that component to be prerendered. Why not prerender in local development? We believe the local dev experience should be as "lazy" as possible. Pages should compile on demand; you wouldn't want to wait for every single route to compile before you can get started. Prerendering every route on save would be slow, which goes against our ambition to keep improving Fast Refresh times. With Fast Refresh, you can make a change to your code, hit save, and see the application update near instantly without losing your current client state. I understand the desire to know whether the page will be prerendered or not during local dev, though. We used to show an icon in the bottom right of the screen, if the page would get prerendered. We're bringing this back! Where are we headed with Next.js? With the v15 stable release, we'll be writing more in the blog about our plans for the future. Our goal is to make all async operations (like doing a `fetch`) opt into dynamic rendering, similar to how using `headers` opts into dynamic rendering. We believe Partial Prerendering will become the default way of building Next.js applications. In this world, routes can be both static and dynamic. Even if the majority of your application is dynamic, you can still have a "shell" of your application that gets sent to the browser immediately, and then have the rest of your page (the dynamic parts) stream in parallel. This shell could even only be the link preload headers, for example. If you want more of the route to be included in the prerender, you can wrap the dynamic parts of your page in React Suspense to define a fallback state. Next.js can then prerender up to that Suspense boundary as part of the build process. When serving the page, the user is immediately shown the prerendered HTML while simultaneously streaming the dynamic parts of the route. Partial Prerendering is fully supported with `next start` (the production Next.js server) and is experimental today. When can I try this out? Next.js v15 stable will be released soon, which includes the previously mentioned default caching changes. Either in v15.0.0 or in a minor version soon after, we'll allow you to try the vision above for where we're headed behind an opt-in flag. We're taking time to validate these early features with our own applications, some early partner customers, and the community to ensure they're well tested in large Next.js applications. We're also working on simplifying the existing caching APIs and building DevTools for Next.js, which we feel are important pieces for completing the vision. More on this soon! In conclusion, with Next.js 15: • `fetch` requests are no longer cached by default • Route Handlers are no longer cached by default • Client-side navigations will no longer keep a cached version of the last page for 30 seconds when using `<Link>` or `useRouter` We'll also make it easy to keep the existing behavior, if you prefer, in the upgrade guide. Okay, that's all for now!

Next.js: Authentication ※ Best practices for Server Components, Server Actions, and Middleware ※ Patterns like Data Access Layers, API Minimization, and Data Transfer Objects Also, aside from headshots, this video is entirely built in React 🤯

Next.js 15 RC ◆ React 19 + React Compiler support ◆ `fetch` and Route Handlers no longer cached by default ◆ Incrementally adopt Partial Prerendering ◆ New `create-next-app` design ◆ next/after (Experimental) nextjs.org/15-rc

100% readiness on turbopack, the new @nextjs Rust-based compiler-transpiler 😁

Companies using RSC in production

React Compiler 🤝 Next.js We've landed an option that automatically configures the React Compiler. Supports: ◆ App Router ◆ Pages Router ◆ Webpack ◆ Turbopack Instructions have been updated in the official docs: react.dev/learn/react-compil…

Turbopack is now passing 5918 tests for `next dev --turbo`. 🚨 1 remaining for 100%: areweturboyet.com

Okay, we're joining the fun. nextjs.org/?uwu

We’ve open sourced a new quickstart to help you build with the Assistants API and @nextjs. It comes with sample code for creating a chat interface with streaming, and using tools like function calling, code interpreter, and the new file search. github.com/openai/openai-ass…

VS Code now supports custom editor labels. If you want to change the display of `page`/`layout` (or other Next.js file conventions) you can modify your `settings.json` to change the tab title. code.visualstudio.com/update…

Next.js 14.2 ◆ Turbopack (RC): 99.8% of tests passing for `next dev --turbo` ◆ Build / Production Improvements: Reduced memory usage ◆ Caching Improvements: Configurable client-side cache revalidation ◆ Errors DX: Better hydration mismatch messages nextjs.org/blog/next-14-2

Next.js now has 1 million monthly active developers. 80% of Next.js applications are now on v13 or later. We’ll be releasing v14.2 very soon with further improvements. Thank you for your continued trust and support.

Introducing morph: a fully open-source AI-powered answer engine with a generative UI. Built with @vercel AI SDK, it delivers awesome streaming results. 👇 More details

Forms load 180x faster using @nextjs React server components and form actions instead of HubSpot iFrame embeds. On 3G Fast throttling speeds, I can fill out the new form and submit it before the old one would even load. Can't wait to ship this

Turbopack is now passing 5834 tests for `next dev --turbo`. 26 remaining for 100%: areweturboyet.com ████████████░ 99.6%

Next.js AI Chatbot 2.0 ◆ AI SDK 3.0 with React Server Components ◆ Generative UI support ◆ Updated Shadcn UI and Next.js ◆ Simplified deployment vercel.com/changelog/next-js…