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.

[aiiiden]

@leerob Thanks for answer! In the end I am familiar with app router now. I understand your efforts.

[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.

[leerob]

Thanks for sharing!

The concept of server-side rendering in 2024 feels outdated given the advancements in average internet speeds and hardware capabilities of modern devices

I am not following this part, what is the alternative to this that you're proposing – static rendering?

[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 :)