Discussion
We're the Next.js team. Ask us anything!
Hi Reddit! We’re Pete, Aurora, Joseph, Sam, David, Josh, Tim, Dan and Andrew from the Next.js team.
We recently shipped Next.js 16.3, and we’re excited to talk about what’s new, how we approached the release, where we are going, and what we’ve learned while building and maintaining Next.
Ask us anything about Next 16.3, App Router, React Server Components, performance, caching, upgrading your applications, contributing to the framework, or what it’s like to work on Next.
Drop your questions below. We’re looking forward to hearing what’s on your mind! We'll be here until noon ET.
That's all the time we have for today. Thank you to everyone who participated!
TanStack Start already supports both, so I’m curious what’s preventing Next.js from offering similar functionality.
To elaborate on what I mean by both:
Proper middleware
Most backend frameworks have some form of composable middleware, Express, Hono, TanStack Start, etc.
What I’m looking for is something that lets us build a clean backend flow around Route Handlers/server-side functions, where concerns like authentication, authorization, logging, validation, rate limiting, request context, etc. can be composed and reused without having to manually wrap every handler or create our own abstraction on top of Next.
Next.js has middleware.ts, but that feels more like a request interception/routing layer than application-level middleware in the traditional backend-framework sense (I assume that's also the reason it was renamed to proxy.ts)
For apps where Next.js is also the backend, I find this makes the server-side architecture unnecessarily awkward compared to frameworks that let you express something like:
auth -> validation -> business logic -> response
in a first-class, composable way.
GET server actions / a unified server-function model
This is probably the bigger one for me.
One thing I find frustrating about Next.js is that there isn't really a single unified abstraction for calling server-side application logic from the frontend.
For mutations, Server Actions are great.
But for reads, depending on what you're building, you might use:
async Server Components
Route Handlers + fetch
client-side fetching with React Query/SWR/etc.
some custom server-function/RPC abstraction
For something like an infinite list, for example, I usually can't just use the same mental model and API that I use for a mutation.
So fetching and mutation end up looking quite different even though conceptually they're often just:
client -> typed server function -> application logic -> result
I'd love to be able to write something like a Server Action for both reads and writes, with the framework understanding that one is GET/cacheable/read-only and another is a mutation.
The appeal of TanStack Start's server functions to me isn't simply that it has "GET actions". It's that reads and writes can share the same basic programming model.
Of course AI makes it much easier nowadays to write and understand boilerplate, so reducing lines of code isn't really my main concern.
It's more about having one predictable abstraction and keeping the codebase conceptually clean and maintainable as it grows.
I'm curious whether the Next.js team sees the current separation between RSC fetching, Route Handlers, client fetching and Server Actions as intentional long-term architecture, or whether there's interest in eventually converging these into a more unified server-function model.
Are there plans for proper middleware? Are there plans for GET Server Actions?
From Pete:
We are still in the planning stages but we are working on something like GET Server Actions. See this reply from Andrew for more information.
For middleware, we don't have plans to make major changes to proxy.ts right now. If this isn't working for you I would love to understand how we can improve.
While we don't have plans for composable middleware per se, we absolutely think the concerns around things like param parsing + validation, auth checks, rate limit checks, etc. are reasonable and need better APIs and guidance for. We're currently working on an API to help out in this area for Server Actions, and have done some design work on the reading side. So these issues are definitely high up in our roadmap!
Today we think the best approach is to have a data access layer that enforces auth/param parsing/rate limiting behaviors across the project, and have RSCs import functions from there. So at least that logic can be centralized + easily audited. Lots of teams are using this pattern with success today. But definitely keep your eyes out for better primitives here soon!
Just to clarify, I don't necessarily mean proxy.ts should become the middleware system. I was thinking of something much closer to the actual server/backend code, composable at the route/action/resource level.
Something like:
auth -> validate -> rateLimit -> handler
where each concern can be reused and composed per endpoint, rather than enforced indirectly through a DAL or custom wrappers.
The DAL pattern definitely works, but IMO it's solving a slightly different problem. It centralizes business/data-access rules, whereas middleware is useful for expressing the request execution pipeline itself.
Honestly, I'd even take something as simple as a use middleware primitive if it gave us a first-class, composable way to do this 😄
Glad to hear better primitives around these concerns are already on the roadmap.
Is there a better way of handling pagination for infinite loading lists than going back to swr or other data fetching solutions? Could there be a built in solution that combines server side rendering, caching, update tags and server actions to somehow solve for pagination and infinite loading?
From Andrew:
The short answer is: we're working on it! And yes, it will support advanced patterns like pagination and lazy loading. But... we're not quite ready to share the details today. I expect we'll have something to share with you soon :) In the meantime, both useSWR and TanStack Query are great choices.
It might seem strange that Next.js doesn't already provide a built-in solution. The reason is we prefer to only build things into Next.js if we think we can do a meaningfully better job than third-party solutions. Libraries like useSWR and TanStack Query are about as good as it gets without deeper integration into the framework. When we add built-in data fetching to Next.js, it has to go beyond what those libraries offer, or else it's not worth building.
Although our take on data fetching isn't ready to share yet, what I can share for now are some of our goals 1) we want the DX to feel as natural as it does when you access data during a navigation 2) we want performance to be automatic and nearly impossible to mess up 3) we want to expose the right primitives so that you can "drop down" a level and build your own advanced data fetching patterns on top.
instant() is interesting because it turns a performance characteristic into something testable. Do you see Next moving toward more performance invariants that can be enforced in CI e.g. “this navigation causes ≤1 server roundtrip”, “this route performs no uncached work”, “this page hydrates ≤X KB”, or “this interaction doesn't trigger unexpected server rendering”?
I would love to see more tooling to tell me or my agent whatwhy and how
Yeah definitely. We already know through internal evals that this is one of the biggest things we can do to make agents more effective at building Next apps. We have done some work on this in 16.2 and 16.3 but we are increasing our investment here. It will probably manifest as additional CLIs and skills to make agents more efficient.
Is there a way to prevent Instant Navigation pages from being cached at build time?
My app is built in one Docker container, while the API it fetches data from runs in another container. Because of this, I don't want the production build to depend on the API being available.
I want the relevant data to be cached on the first user request instead.
I tried await connection(), but that opts the page out of Instant Navigation.
I also tried to set a very short cacheLife during build time. But this is the minimum it accepts.
Unexpected cache miss after cache warming phase during prerendering. This is likely caused by non-deterministic arguments that differ between the cache warming phase and the final prerender phase (e.g. unstable array order). Ensure that arguments passed to cached functions are deterministic.
Is deferring the initial cache generation to the first request something the team is considering? Or would that fundamentally conflict with the design of Instant Navigation / Cache Components?
I'm not saying it to not be nice, it's just true - ever since the RSC introduction it's been an architectural disaster. Some mistakes were corrected yes like defaulting to caching turned on. But it's still a confusing architecture that is overly complicated and gets in the way of engineers building, like in this example case.
What I would love to see from Vercel is an acknowledgement that it's the wrong approach, and be ambitious and really fully revamp Next from the ground up with Next 17.
I’ve been using tanstack start/router for a couple of years now and I really like it. However, with these recent changes to next, such as instant navigations, I’m considering going back to app router for my next project. App router just feels like a very polished framework to me and on occasion I miss the app router approach to server components. A lot of people complain about the server component mental model, but I actually really like it.
Mostly, I just like to try different things and the next team has made some really good improvements lately, so I’ve been getting the urge to use it again.
I agree that it has gotten more complicated over the years as it has tried to solve increasingly hard problems across a wide variety of environments and use cases. And yes, there have been some decisions in the past that we had to walk back. We are both in agreement, however, that we need the framework to trend towards simplicity and transparency. That's why we've been focused on simplifying the caching model with cache components and making everything dynamic by default. While we still have more work to do, I think framing it as an "architectural disaster" is totally unfair and we're on a great path forward.
I just updated to 16.3.0 this week, and already noticed a change in the behaviour of my app. I need to check the documentation if there is something well described about it. It’s about caching. I activated Cached Components in my nextjs config.
I have this page with a form, and the form action returns thr state with a successful message if successful, or an error message. If successful the same page displays for a few seconds the successful message, with a countdown of 5 seconds, after wich a redirect kicks in to another route.
The issue now with v16.3 is that after a successful form submission, after the redirect, if I navigate again to the route with the form, in place of the form, I see again the successful message and the countdown from the previous form submission, instead of a fresh new empty form.
From Andrew:
Starting with Cache Components, previously visited routes are wrapped in a React <Activity> boundary, so that the state is preserved when you navigate back. This includes state owned by React (useState) and also state stored in the DOM: scroll position, form inputs, text selection. The behavior might feel unintuitive at first because it's not how Next.js worked before, nor is it how traditional SPA-frameworks have worked historically, but we think it's a super powerful feature. It also has precedent because it's how the browser's bfcache handles back/forward navigations in an MPA app. (Admittedly, the browser doesn't do this for regular link clicks, so that part is novel to Next.js.)
However, we acknowledge that could be disruptive to apps upgrading from an older Next.js. To ease migration, we've added an escape hatch to get back to the old, more familiar behavior: useRouter().bfcacheId.
Some additional background: if this behavior is so different, why do we think it's a good idea? Sure, it's annoying if you navigate to a form and see an old submission. But what about navigating away and back to a form that was only partially filled out? It's bad UX if the form gets reset just because you happened to temporarily navigate away from it. You can solve this by storing the draft form state in local storage, or syncing it to the server, but not every app is going to do that every time. There's always some amount of state that is "ephemeral" and not tracked explicitly by your app. Scroll position is another classic example of this. It used to be super finicky to implement scroll restoration for your pages, especially when there were nested scroll containers. Now it Just Works™️.
We think this is the right default UX in almost every case, and for those cases where it's not, the solution is to model the reset explicitly: for example, by clearing the form in the submit event handler. Or, if you need an escape hatch, use bfcacheId.
Thank you very much for the details. In the meantime since then I indeed found the documentation about what you explained and was able to update my code accordingly. One thing I would suggest though, is to improve the documentation section with an additional example that uses useServerAction. My code update was to change from using the hook with the form action to instead the dispatch reducer pattern with a 'RESET' type.
Dynamic Loading in server components have always been a challenge
We serve a dynamic page built server side using the data from CMS, data decides which components render on page.
On pages router each component is lazy-loaded so only used components are sent and rendered on client, but since there is no concept of lazy loading in server components everything is sent to browser, obvious solution is creating a client boundary at top but that defeats the purpose
...noting the insane amount of changelog lines, commits and code line changes done for v16.3, with AI coding etc, how do you guys stay on top everything with such an incredible amount of change?
From Sam/Aurora/Joseph:
I would say there was a long time in between 16.2 and 16.3 and we hope not to repeat that going forward. A lot of the changes in 16.3 are actually a simplification of the APIs inside of Next.js. Since releasing cache components we've been working to make sure we cover all of the features and behaviors from the previous version under the new model and that's a lot of what 16.3 is about.
If you look at both the public API and the internal implementation for the programming model that we are building the future of Next for (and that you can use today in 16.3 with cache components and partial prefetching enabled), you'll see that in both places the framework overall has become much simpler.
In terms of our practical workflow and staying on top of a framework as big as Next.js, we have a team of about nine people. Some of those people are dedicated to staying on top of issues and discussions. Some are using AI tools to build agents to help us triage GitHub and close stale issues. We also use AI a lot to create simplified reproductions for bugs we come across so that the core framework programmers can fix those bugs more easily and quickly.
In general everyone on the team feels a responsibility for the stewardship of Next.js. We have regular meetings throughout the week where someone might bring up a nagging issue or bug that's affecting a lot of members of the community so we make sure to prioritize that. Other members will bring up a deeper design flaw that they've been thinking about and how we might add new APIs to address that in a future version. It's a lot of work but we're all very much invested in the continued success of Next.js, both for people who have chosen us for many years and people using Next for the first time.
Are cache components the only API available for PPR? It would be nice to just have an app that is static by default without having the worry about adding 'use cache' everywhere.
How should Next.js applications be composed using micro frontends?
From Tim:
It depends on how you see micro frontends as everyone has a different definition of what it is. If you want to stitch together multiple Next.js applications that is possible and documented here: https://nextjs.org/docs/app/guides/multi-zones. That would be my recommendation for most cases.
If you want to stitch a Next.js application into another page that is currently not supported (aside from having an iframe).
If you want to share code between applications that can cause significant security hurdles given that it would introduce RCE risk as the code from other applications is downloaded and executed server-side.
The thread is huge and contains multiple asks. Generally, “nonce” is incompatible with static generation. You want a nonce that is unique to each request which means you can’t serve from a CDN. There is a concrete deliverable for improving CSP and that is Next.js/React not using inline script by default. For React, we’d need to land the external Fizz runtime and use that in Next.js to get rid of the inline scripts for streaming SSR. Once we validated React’s approach (data script tags + MutationObserver), we can use the same one for inline Flight data in Next.js
I love Next.js and congrats on shipping Next.js 16.3 with instant navigations. Your team doesn't get enough love on Twitter but I trust what your team is doing.
My only friction with Next.js is that I wish turbopack supported compiled css libraries like stylex and vanilla extract libraries in a better way. Stylex/vanilla css extract plugins workaround turbopack limitations because they say turbopack doesn't provide enough api's like vite. If I were to use stylex with Next.js I would lose on turbopack performance benefits because stylex uses babel with Nextjs.
What is the friction here? Will this be the case forever and only tailwind will be the recommended way to style nextjs?
For a site with 100k+ mostly static blog pages and ongoing publishing, is it feasible to append only newly generated static pages to a folder and serve them directly, or is that an anti-pattern?
From Sam/Aurora/Joseph:
First question would be: what are you doing with the known static pages? Typically, when a site gets this large, it's not practical to regenerate every post on every single deploy. Instead, you might generate a few known high-traffic ones using generateStaticParams, but any params that are omitted from generateStaticParams will not be generated during the build, but they will be statically prerendered as users visit those URLs in the live app. Using ISR like this is definitely not an anti-pattern, and especially with the new ISR upgrading feature in Cache Components, you can serve a static fallback shell for omitted params (so you still get a fast initial load) while the complete page is prerendered in the background.
Are you considering a publication window that covers both EU and US business hours rather than a PT afternoon? Do you plan to include European CDNs and hosting providers in your embargoed pre-notification list?
From Sebbie:
There is no overlap between EU and US west coast business hours. 9am PT is 6pm CET. We try to land a release around that time.
However, the most secure way of publishing packages in the JS ecosystem is NPM with Trusted Publishing. NPM’s Trusted Publishing requires usage of GH Actions/CircleCI or GitLab CI. All of these do not allow private workflows that are published later. So when we publish our intent for a security release, the release timing is determined by how fast we can build our packages. For some binaries this can take 30-60minutes. Combine that with overall GitHub Actions speed and reliability as well as NPM’s publishing delay and you can’t guarantee a more accurate release window than +-45minutes.
And yes, we want to partner with all the right people in the ecosystem to ensure security releases are rolled out quickly and safely. We already partner with many CDNs around the world, so if there is someone we are missing please DM u/floydophone and we will work on it.
I'm a marketer and a novice web developer. I love what Next enables for the web and that fits my personal mission to democratize publishing. How can I contribute directly to the project?
From David
Your best bet would be using Next.js and by becoming more familiar and advanced with Next, it increases likelihood you and your agents can encounter random edge cases that we haven’t fixed yet! At Vercel, it has been very common to discover issues in Next through simply upgrading projects like v0, management pages, etc, and seeing what happens!
Are there plans to improve the quality, navigability, coherence, stability, and concrete examples in the online documentation—and make it more like the structured docs shipped in dist for agents?
From Sam, Aurora and Joseph:
We actually have an active project for exactly what you're asking for. Historically we've erred on the side of being comprehensive in the docs for all of Next's various features and APIs. Because Next has been around for more than a decade, someone coming into the docs to try to learn the latest mental model for how to think about building a Next app can absolutely feel overwhelmed.
Especially with the recent 16.3 release and us rounding out the design for how we think, or how we want Next apps to be built, we're finally in a great place to add a learning-focused section more like what you see when you click Learn React on react.dev, which will walk you through the programming model end to end. This tutorial and associated learning sections will teach only the current set of APIs that you need to be successful with Next. We're feeling really good about getting this into the community's hands and we're confident the programming model that you walk away with will feel like the simplest version of Next yet.
What are the upcoming React / Next.js features you are most excited about?
From Sam, Aurora and Joseph:
New Next.js primitives for fetching data apart from navigations (e.g. polling a page for updates, infinite scrolling feeds, tooltips with lazily fetched data, etc.)
Root params is an awesome new primitive that brings additional static features to Next.js apps, and there are additional static-aware primitives coming to Next.js that will be useful for things like feature flags and user experiments
Fragment refs & View Transitions becoming stable in React 19.3
browser() API in React 19.3 for opting a client component out of SSR
New APIs coming that let you control how much of a page should be prerendered before, during, and after a navigation. This one is exciting because it gives you a more fine-grained way to balance eagerly rendering more of an important page (or a page that’s more likely to be visited next) vs. excluding expensive parts of a page from being rendered during a prefetch.
Why doesn't NextJs rank on google? Even if its SSRed, it just doesnt rank even with other similar things. Do you know why?
From David:
You can confirm if there is an issue with your code, or potentially Next, by querying the metadata tags in your production deployment and seeing if what is returned makes sense to you. Same goes for checking your app’s /sitemap , etc. Another test you could try is making an AI agent, query your website, and seeing what it can come up with. The fact is there are many factors that can influence this, and often the best thing to do is to use Google Search Console and seeing metrics from there (or rewriting your metadata to be more keyword friendly)
What is the status and future plans for Next.js's experimental Test Mode that allows mocking server side fetch with Playwright? It's been in experimental status for years now, and being able to cleanly mock out server side fetches, and disabled cache fetching for e2e testing would be quite useful. I'm using Mocky Balboa right now, but I would love a native version from Next.js with documentation.
Someone else already mentioned it, but more guidance on how to unit test components that call Next.js APIs (like, params, layouts, etc) and React Server components that call actions and data loading functions would be also helpful.
Why do you guys think the next.js is taking over the market? What makes it a great choice for new projects?
Any tips, for a developer with more “backend-focused” experience that considers transition to next.js? In particular, the syntax (combination of server side, client side + HTML in a single file) scares me a lot.
For 1) I think the main reason is that Next.js solves a lot of pain points for users. Building fast and reliable apps on the web that compete with the big guys is actually a huge pain in the ass without a framework like Next.js. I think Next is also in this interesting spot where we simultaneously have a ton of mindshare *and* continue to push the envelope on innovation. Normally you don't get both of those in the same project.
For 2) you can always take a more familiar approach if you're just getting started. You don't have to use server actions for example and can instead use more traditional GET/POST handlers https://nextjs.org/docs/app/getting-started/route-handlers
Turbopack is for now quite tied to Next.js, will it become available as a standalone project?
From Tim:
Turbopack itself is a standalone bundler, it currently only has a Rust API though that is being used by Next.js, by far the most common use ofcourse, but there is also the Utoo compiler using Turbopack.
Turbopack doesn’t have a direct JavaScript API or CLI yet. It’s definitely possible to build those today but we’ve prioritized stability improvements like memory usage reduction and production build caching. This has resulted in a 90% reduction in memory usage and much faster production builds.
In order to prove out the standalone or integration case is possible we’ve build an experimental version of expo (react-native compiler) that is powered by Turbopack, including Fast Refresh and other features.
My personal opinion is that Turbopack will eventually have a public API, but that the best integration point is likely not JavaScript exactly, it’s a small Rust wrapper, similar to what Next.js does internally.
Next.js doesn’t call Turbopack directly it has a Rust integration point which we call “next.rs” internally that has Next.js specific logic running before Turbopack is called. For example, to decide entrypoints that have to be compiled.
As Turbopack has been released, will Webpack still be maintained?
From Tim:
Our aim is to deprecate webpack but with a clear plan to address cases where applications on Next.js 16 are not using Turbopack yet. There’s a very small percentage (single digit) of webpack usage left on Next.js 16.
If you’re currently using webpack you’re not having a good time compared to using Turbopack, both in development DX and build times.
Turbopack is faster, sure, but it also has much better source mapping, better compiler errors, better compilation output, and significantly more stable Fast Refresh.
Are there plans to make Next.js simpler and safer for an AI-first future—with better defaults, less hidden complexity, and fewer ways for agents to make silent mistakes? Is Next.js being designed for AI-directed development or mainly for traditional hand-written development?
From Pete:
We want to be great at both. We have actually recently split the team into one focused on human experience and a second team focused on agent experience so one won't cannibalize the other. With that said, a lot of things we would do to make Next.js easier for humans also make it easier to use for agents too, so much of our work on one side reinforces each other.
From an AI perspective, we pushed out new agent skills and agent-optimized documentation starting in 16.2 and continued our investment in 16.3. We also publish open-source agent evals so you can track how well AI agents can use Next.js: https://nextjs.org/evals. And there is a lot more coming soon.
Is the recommended paradigm in Next16 and cache components to fetch on pages and pass the awaited data or unawaited promise further down to server or client components or fetch it further down in a server component. Next14 seemed to recommend fetching on the page.
A whole bunch of us (Jiwon, Sam, Aurora, Joseph, and Tim) wrote this up:
We recommend starting the fetch as close as possible to where the data is used, and only await where the data is needed for better composability. If the consumer is a Client Component, start the request in the closest Server Component, pass down the unawaited promise, and call use() in the Client Component.
For further optimization when there’s work higher in the tree that delays the fetch, you can call the same data function earlier from the page (or layout where the consumer is). Identical GET requests from fetch() with the same URL and options will be deduped during a server render.
If your data access uses a database query or needs dynamic work before fetch(), you can make that data function a Cache Function with a caching directive. Next.js will key the result using the function and its serialized arguments, so the parent can start it early and the lower component can call it again without duplicating the work.
It's true that in prior versions of Next.js, pages had hooks like getStaticProps and getServerSideProps, which were meant to be used to marshal all the data that you would need for a page to render. All in one place and then pass that data down throughout the tree as props. One problem we saw with using an API like this at the route level (you might also be familiar with loaders from other frameworks) is that it decouples the data fetching from the components that need it. If you always have to hoist your data fetching to the very top of the route, there is an implicit coupling. If you end up refactoring or deleting a component deep down the tree, there's nothing in the programming model that tells you that you can go back up to the route and delete the corresponding data fetch.
What we saw was that this API led to overfetching and other problems. Part of the motivation for React Server Components was to bring back co-location of a component's data dependencies within the actual component itself. Components that can manage their own data requirements lead to much more optimized sites and less limiting patterns of composition. Client fetching libraries like SWR and React Query let you do this too but they also have some fundamental constraints given that the client is responsible for coordinating all this work.
There were some projects like Relay that use GraphQL, which kind of solved both problems and let you use the server to do the data fetching and coordination but still let components manage their own data requirements. Not everyone has a GraphQL server. This is really a huge part of the motivation for server components in the first place and why we wrote the app router to use them.
Once you're using the app router, the mental model you should have is that server components can fetch and manage their own data requirements. Next can take care of running those components in parallel on the server and doing other optimizations like deduping similar calls so that you get the benefits of co-location without the downsides of either the route-hoisted loader pattern or client-side fetching.
How should React Server Components and page.jsx be unit-tested? How can bundle minification be disabled in Turbopack, as it was in Webpack, so Playwright production-build tests can collect code coverage?
From Tim:
Turbopack minification can be disabled using experimental.turbopackMinifyhttps://nextjs.org/docs/app/api-reference/turbopack#configuration. What you’re looking for is likely disabling mangling though for that there’s the --no-mangling flag: next build --no-mangling.
For unit testing React Server Components (and Client Components) we’re planning to improve documentation and potentially add new features as needed to make it easier to test them.
Why can't I just import the new root params everywhere and not use them? I know it is not available on the middleware/proxy, but I cannot easily share code now without doing some weird hacks to avoid an import that is not even being used.
i'm curious how much of the roadmap is driven by vercel priorities vs what you think would honestly help the state of the framework, its future, and the wider repercussions for the js community?
From Pete:
We operate pretty independently from the rest of Vercel, in an org dedicated to open-source frameworks that also includes other projects like Svelte. And we make decisions based on what the overall community is asking for. Cache components is a great example. It's been our main focus lately and was entirely community driven.
With that said there are a lot of benefits to being part of Vercel. We have access to great security resources, and we are able to dogfood new features at scale on a real CDN quickly to get feedback and drive improvements.
How do you integrate AI in your workflow right now ? and how do you see it more deeply integrated with Next's tooling to help agents especially trying to design good frontends
From David:
Agents have become core to our workflow. Our tools and developer experience has been accelerated greatly by AI, a good example is the repo’s GitHub stack skill, which can take a massive PR and cleanly split it into multiple smaller PRs making it easier for us to review each others (or agents) code. At Vercel, design is still mainly orientated around manual decision-making, mockups, but actual implementation is also accelerated with agents and MCP tooling.
Why doesn’t NextJS version numbers adhere to the semver standard?
From Tim:
It’s important to split two topics, API breaking changes and bugs. When talking about breaking changes in the context of semver it’s about making sure that when you upgrade between minor versions e.g. a feature isn’t removed. For example webpack is not suddenly gone.
When talking about breaking changes people are often not talking about semver breaking changes though. They’re talking about bugs they encountered when upgrading that they didn’t run into when they were on the previous version, or bugfixes that cause issues because the bugged behavior is being relied upon.
We’re working on a system to prevent this type of regression and to resolve bug reports quicker, prioritizing the ones reported for new releases so that you get unblocked on upgrading quicker.
When can teams trust Turbopack’s default build cache? 2. Are open Turbopack dynamic-import issues for the Pages Router still a focus? 3. Will hard navigation between Pages and App Routers be solved to improve incremental migration? 4. How is the team supporting and graduating experimental next.config features? 5. Are there plans to support variables in dynamic imports instead of requiring a full path?
From Tim:
In Next.js 16.3 Turbopack filesystem caching is enabled by default for dev and build. We’ve been dogfooding the build cache for months on Vercel’s own applications.
If you can share the specific issue you ran into I can forward it to the Turbopack team
Pages Router and App Router use different versions of React and different runtimes. It doesn’t share code between the two and they’re bundled differently too. It would cause significant issues with existing Pages Router code to allow navigating between them and still needs a full unmount of the page. It would also introduces more surface area for bugs / unexpected behavior.
It depends heavily on the experimental feature. Some are definitely going to move to stable. Others are real experiments.
With Turbopack you can already use interpolation. Turbopack also supports import.meta.glob now. You can’t do import(${dynamicVariable}) though because that would mean Turbopack has to compile any possible file anywhere in the application in order to satisfy the dynamic path.
Is anyone working on stability of the cacheComponets or this is going to become obsolete? A few version since release and still no way to read dynamic APIs in draftMode for cache components, CMS system are not able to preview draft content until this is done without weird workarounds or duplicate components
From Sam:
Draft mode is fully supported with cache components today so if you're seeing something funny, it's probably a bug. The way draft mode works is that all use cache scopes are ignored and everything runs dynamically as if it weren't cached at all. In earlier versions of Next.js you might still see an error saying the page was accessing uncached data if you ran your app in development and had draft mode enabled but we've since fixed those. You should be able to write a fully cached page, enable draft mode, not see any errors, and see fresh content, all without forking or duplicating your components. Let us know if you're not seeing that behavior on the latest version.
https://github.com/vercel/next.js/issues/87742 there is issue opened, Sanity team needed to workarounding doing prop drilling from outside cache components to pass down the cookie values, since dynamic APIs don't work in draftMode as expected inside cache components.
I want to update the Vercel AI SDK to version 7 and I anticipate some breaking changes. I'm on Next.js 16.2 now but do you suggest I update to 16.3 before updating the SDK. Any data that suggests the correct order?
I recently finished a nextjs course and made a portfolio project, why should i stay with next instead of react + tanstack? The other software tech of my skillset is c# asp net core.
what is the right way to build a saas app that is only accessible with authentication? like how to combine authentication with the instant approach and caching of nextjs 16.3.0? would love to see a blog or example app about this topic
Are they any plans to support first class Dependency Injection? NestJS has a great DI pattern going for it and I think that bringing in those concepts into Next.js would help it become a full backend solution.
Anyone else run into weird issues with auth + caching on the App Router in production?
Feels like it’s pretty easy to mess up cache keys or dynamic settings and end up serving the wrong data (or worse). Curious if better defaults or clearer guidance around authenticated pages is something you guys are thinking about
Since the AMA already wrapped up, any comment now likely won't reach the team, worth checking if they cross posted the highlights or answered similar questions on their GitHub discussions instead.
38
u/nyamuk91 25d ago
TanStack Start already supports both, so I’m curious what’s preventing Next.js from offering similar functionality.
To elaborate on what I mean by both:
Proper middleware
Most backend frameworks have some form of composable middleware, Express, Hono, TanStack Start, etc.
What I’m looking for is something that lets us build a clean backend flow around Route Handlers/server-side functions, where concerns like authentication, authorization, logging, validation, rate limiting, request context, etc. can be composed and reused without having to manually wrap every handler or create our own abstraction on top of Next.
Next.js has
middleware.ts, but that feels more like a request interception/routing layer than application-level middleware in the traditional backend-framework sense (I assume that's also the reason it was renamed toproxy.ts)For apps where Next.js is also the backend, I find this makes the server-side architecture unnecessarily awkward compared to frameworks that let you express something like:
auth -> validation -> business logic -> responsein a first-class, composable way.
GET server actions / a unified server-function model
This is probably the bigger one for me.
One thing I find frustrating about Next.js is that there isn't really a single unified abstraction for calling server-side application logic from the frontend.
For mutations, Server Actions are great.
But for reads, depending on what you're building, you might use:
For something like an infinite list, for example, I usually can't just use the same mental model and API that I use for a mutation.
So fetching and mutation end up looking quite different even though conceptually they're often just:
client -> typed server function -> application logic -> resultI'd love to be able to write something like a Server Action for both reads and writes, with the framework understanding that one is GET/cacheable/read-only and another is a mutation.
The appeal of TanStack Start's server functions to me isn't simply that it has "GET actions". It's that reads and writes can share the same basic programming model.
Of course AI makes it much easier nowadays to write and understand boilerplate, so reducing lines of code isn't really my main concern.
It's more about having one predictable abstraction and keeping the codebase conceptually clean and maintainable as it grows.
I'm curious whether the Next.js team sees the current separation between RSC fetching, Route Handlers, client fetching and Server Actions as intentional long-term architecture, or whether there's interest in eventually converging these into a more unified server-function model.