The Future of Next.js Pages Router

[aiiiden]

Hello, I've been working on completing and maintaining the products at the company I'm currently with, using the page router. I find great joy in creating products through the page router and, additionally, I'm excited about the possibility of server-side rendering (SSR). Utilizing features like getServersideProps allows for sufficient implementation of server-side actions.

However, as I migrate to the app router this time, I have some concerns. Firstly, given the substantial volume of products I develop and the fact that I work with a small team, the most realistic thought that came to my mind is, "Will this page router soon be deprecated, no longer supported?"

I should stick to the main point, but it seems I've added a bit of my opinion. I'm curious about the future of the page router in the current situation. Will it truly disappear or be deprecated later on? Or is there a parallel route where both app router and page router can be used? I'm interested in that future. It will help me decide whether I should work overtime or not 🤣

[sergeushenecz]

I have the same quetion and i would understand about future page router

[christianjuth]

I think it's really important that this question is answered even for projects migrating to app router. Realistically it's going to take me awhile to fully migrate from pages to app router. I would like to know if the long term plan is to push everyone to app router or to support both pages and app router.

Even if pages router isn't actively developed moving forward, will it still get bug fixes?

[wunderbarr]

Same concern. Any developer in Next could answer? @timneutkens @ijjk

[4ydx]

I would also like to know if page routing will be kept for years to come or not. I don't like that App Router forces a node backend.

[benalexb]

Bump on this question. I share similar concerns.

[ahmafi]

I think there are scenarios that page router is better and kinda the only option, like using the same code for web pages and mobile app with Capacitor.js.

[leerob]

👋 Hey, sorry I didn't see this discussion until now!

In short, we're committed to supporting the Pages Router for many years in the future. And then maybe longer even. We believe backwards compatibility is incredibly important, which is why the same features from Next.js 1.0 work in Next.js 14 today (through the Pages Router).

You don't have to move to the App Router. We believe it has features that are beneficial, of course, but all new things take time to mature and bring the community along for the ride. If you're not wanting to try things out just yet, no worries at all.

Further, we're still making Next.js improvements that apply to both routers, like adding Turbopack (through next dev --turbo) to speed up your local development environment.

Hope this helps.

[mashwishi]

Looking forward.

[baranelitez]

im going to be funny and nitpick here: even mentioning "backwards compatibility" in the first sentence sets the tone hahahah

[daveycodez]

TBH I won't really enjoy using the App Router as long as all the pages and routes are required to be named "page.tsx" and "route.tsx" makes the tabs kind of confusing in VS Code.

[xdajay]

@daveycodez I had the same initial impression. While your page.tsx or route.tsx can be .js, I would highly recommend going with .tsx as projects grow larger. Type safety and IDE pre-compilation really help keep projects stable, and components built for reusability benefit massively from type safety.

The problem is that online examples often show types in React as more complicated than they actually are in practice. Another argument is "type gymnastics," but this is really a skill issue where developers add unnecessary type checks even for simple logic.
I hope this helps!

[daveycodez]

@xdajay I wasn't referring to the extension .tsx, but the filename requirement of "page". It makes all of the tabs "page". Instead of "home.tsx", "about.tsx", etc.

The pages directory structure is far superior and clean compared to the app folder.

[xdajay]

@leerob, I have faith in Vercel's ability to maintain backward compatibility. I've been building on top of Next.js for the past 4 years, and while the advancements are impressive, not all apps require the app router or React Server Components (RSC). Many developers, including myself, don't feel the need for server-side rendering except for SEO pages. Mixing frontend and backend logic is still crucial for many use cases. While some see a return to a PHP-like environment as beneficial, others, like me, do not.

For the first time in years, I'm consistently exploring alternatives to Next.js. The concept of server-side rendering in 2024 feels outdated given the advancements in average internet speeds and hardware capabilities of modern devices. If this were 2014, I would be fully onboard with server-side rendering. While RSC makes sense for SEO-heavy consumer platforms like e-commerce and marketplaces, it doesn't seem necessary for SaaS or business applications.

I hope the Vercel team gives equal importance to both the page router and the app router. The page router should not be treated as a second-class citizen, with significant features being rolled out only for the app router.

Thanks.

[xdajay]

I’m proposing that developers should not be penalized for using the Page Router by exclusively building new Next.js features for the App Router only. Depending on the use case and target audience, static rendering, CSR, or RSC might be appropriate. I am not debating which approach is best; both have their pros and cons.

If Vercel is fully committed to the App Router and will only ship new features exclusively for it, this should be clearly communicated to the developer community. This way, developers can gradually migrate to the App Router or consider switching to a different framework. For instance, Vercel’s own font is still not supported in the Page Router (vercel/geist-font#59).

Thanks.

[leerob]

I agree that we should also release new bug fixes and improvements to the Pages Router. We plan on doing this, with the active workstreaming being Turbopack.

It is not possible to simply add RSC support to Pages Router – we do not plan on doing that. If you need RSC support, you will want to move to the App Router, which has been designed to support the latest React features and APIs for the server.

It's worth noting that many of the features released in React 19 apply to client-only React apps, as well as the Pages Router. For example, client actions and the various hooks for working with forms.

[xdajay]

Thanks, Lee🙏
I really appreciate your understanding. It’s such a relief :)

[xdajay]

Just an update: We have successfully migrated to the App Router in production - with hundreds of components and API routes. We didn't have to change any core logic of code; components and routes from a year back still work. All we had to do was make changes to route handler methods and add 'use client' for client-side pages.

We used incremental migration, where we migrated pages and API routes to the App Router one by one. The entire process took over 1 week for a project size of about 100k+ lines of code.

If you want to offload some of your heavy rendering to server-side, or you have a ton of stuff that benefits from SEO, RSC, or want PPR for better performance, moving to the App Router is worth it.

[leerob]

That's awesome to hear, thanks for sharing.

[Dupflo]

Hello @leerob

I have been working on a full upgrade from the pages directory to the app directory for a couple of months now, and I feel the app router is bringing more complexity and risk to my team’s product. Let me explain.

Our project is a fully statically page router generated website (using getStaticProps and getStaticPaths) based on Strapi CMS. With webhooks, we have the ability to revalidate pages. One trick we found was to generate static files for layouts (such as Header, Footer, Translations, etc.) to avoid API consumption when rebuilding or revalidating each page. It worked well, and the app directory looks like a solution to stop using static files and replace this system via Next.js tags. However, with the current system, the CMS can be shut down and the website will still work.

Our app is also running on three different Azure instances, so we use Azure Bus to display messages to trigger revalidation on our Next.js app. The flow is not bad: We create/edit a page, send a message to the Azure Bus, our Next.js app reads it and triggers res.revalidate(path), it calls the CMS, and then the page is now live and updated on all three instances (no need to visit).

Today, with the app directory, I don't understand why the revalidation is based on the "next visit" of the page to trigger, which causes a major problem for me. In my previous scenario, if I edit the page and my webhook invalidates the cache, if the CMS shut down one of that instance has never been visited, some users will see a 404 page while others will see the cached page. In pages dir, if the CMS is down on revalidation, it will show a previous page version and not a 404. I feel this "visitor" dependency is problematic today because it create a sort of "time depedency" of the pages. Am I the only one thinking this risk?

I feel like the risk is really minor, but It exist now

[vallamost]

The flow is not bad: We create/edit a page, send a message to the Azure Bus, our Next.js app reads it and triggers res.revalidate(path), it calls the CMS, and then the page is now live and updated on all three instances (no need to visit).

Maybe the issues are caused by Azure? This design sounds kind of weird to me. Why not try your own secure web sockets (see socket.io) as a way to broadcast data in real time as a fall back or primary method with Next.js?

[Dupflo]

Hello @vallamost, the fact that we use an Azure does not have any impact, we use a bus because of the multi instance. Using a bus insure that if we revalidate (regenerate) a static page, this page will be updated on all instance.

Without instance, the system is kind of basic : Update a page on CMS -> Send a webhook message to Next.js (via a route api call /api/revalidation) that trigger the revalidation function of Next.js

By say "not try you own secure web sockets", you mean sending message from the CMS to Next.js via this system ? What will be the interest rather than using native CMS Webhooks ?

[vallamost]

Azure Bus has no SLA on delivery times, some messages can take up to 20 seconds to get through under peak loads but they’ll get through eventually. If you are seeing your system desync at times this can be a big reason why. Socket servers of your own that are with your web servers won’t have these delays.

[parlay96]

Is there an official response: Which is better, app router vs page router? Is there accurate data to support the explanation?

[k1rana]

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.

Source: https://nextjs.org/docs/pages

[erikdemarco]

I dont understand why this question can exists. You can just answer it yourself.

You should just put your perspective on vercel's point of view don't just see it from yours. First you should know page router is mostly client component and app router mostly for server components

For Vercel, static site (client) features doesn't bring much money than server/backend features. People who use nextjs with page router mostly just wants to export static site without server component, Vercel spent a lot of money for nextjs. Of course they want to make it more hard for people to use nextjs outside vercel and wants to force feature that makes a lot of money for them (server components)

https://www.epicweb.dev/why-i-wont-use-nextjs

Just imagine you spent large budget for nextjs, but all people just use it to export static page and host it on netlify (main competitor). How would you feel? If you can answer this question then you can grasp the concept of their decision making process. this concept mostly align with all past decision they took. So you can already make a prediction what will they do next.

Even big company like Chatgpt move out from nextjs recently.

[aiiiden]

Yes,

the initial question is about whether there will be continued maintenance for the Page router in the future. If many features have already been developed using the Page router, it takes considerable time to transition to the App router, which is "where they can make money." Therefore, the question is to understand to what extent meaningful maintenance can still be expected.