An honest opinion about the App vs Pages router

[RemyMachado]

I want to share my honest opinion about the direction that Next.js has been taking with the App router, because I really care about this project.

I have been a user of Next.js since version 10 and have been stunned by this framework capabilities. I used Next.js (Pages router) with my clients and with my personal projects and it was always a great experience. It solved with consistency and simplicity most of the use cases and sometimes just a little configuration was enough to solve edge cases.

Now, I have been using the App router since a year for one of my new clients and let me say that it's still a good tool, but the complexity that came with this new router is disappointing.

I'm glad the Pages router is still maintained to this day, but I'm afraid it would eventually become deprecated.
It's obvious to me that the previous router had a far better developer experience.

I'm wondering if I'm an ousider or not and curious to know what the Vercel team thinks about it and what feedback they received apart from this discussion.

Also, I understand that the new router supports new react features (e.g., server components), but is it enough?
I found one advantage of the Pages router is to be clear and unambiguous about how to do server vs client side instructions. The App router on the other hand seems to erase the border between these two and I find it hard to implement the simplest things.

Thank you for hearing my opinion, and I'd be glad to hear yours.
With respect to all contributors,

[christianjuth]

I appreciate making this a poll, but I'm not sure I can simplify my opinion to app router or pages router.

I was really excited for app router but there is a lack of documentation (for common use cases), performance, and stability around Next.js 13 and 14.

In it's current state I am extremely disappointed with the app router. However, I could see myself being happy with app router if Next.js stops working on new features and spends the next year+ solving performance, stability, and documentation (videos, podcast, more example apps, etc.).

For example: there seems – to me – to be a lack of documentation on handling/sharing authentication between server components and client component when using an external API that was not build through Next.js. Should I just not use server component for any api endpoint that is authenticated? Are server components best when only used for public routes? I love the simplicity of data fetching within server components, but once a request requires an auth token this all becomes way more confusing.

Pages to App router (with server component) is such a huge shift in how React works. I'm sure there are a lot of implications here that the community is lacking clarity on. I would really love some more help on understanding best practices moving forward. I fear Next.js team is moving so fast they don't even know what the best practices are anymore.

[MuhmdAjeer]

I agree with your point on authentication,with app router and an external api using cookie based authentication its way more complicated and didnt found no way to handle this issue.

[marmikmewada]

not sure about external api, however with app and new auth v5 you are already storing cookie both in server side & client side by using callback jwt strategy with any credentials & providers. you just need to wrap layout.js with session provider to use session object in client side components for server side components you can use exported auth signin signout function from auth.js & instead of configuration of middleware just export the auth.js as middleware & utilize its object in each Components which will give you seamless usage of session object. other than that i still prefer using api handlers instead of siblings action.js server actions as from client components making fetch calls is so easy especially using hooks. performance in app and page seens same to me nothing changed but vercel should stop bringing in update every 5 mins. or else people will move back to laravel which stays stable for long

[bilalmohib]

Hi @RemyMachado You are absolutely right sir I am using NextJS since start and I became fan of it when it supported server side rendering. I was previously using React but when I learned React dosent have SSR then I searched for further frameworks and found NextJS to be highly beneficial in that case.
In my opinion only pages router is one capable of supporting SSR and while whenever you are going to use use client at the top of app router you are going to fail your seo and its worse. I dont know why Vercel team is behind focusing and recommending app router. I swear if one day they are going to make pages router deprecated I am the first one to leave using NextJS and I know there will be many millions of people using NextJS will be affected.

Here are some of the very important points which @rauchg sir please consider.

1. @vercel Says that App Router supports SSR which is one of the major features and the only feature which attracts to use NextJS instead of ReactJS but this is a big lie. App Router dosent support SSR. I recently worked on a client project it was previously in React and only reason I was shifting to NextJS was because client wanted better SEO and wanted to render html in page source which happens in ssr but believe App router completely failed here.
2. I tried every solution and the thing is when I have used useState or useEffect it said you must use 'use client' at top of the component or page making it completely inaccessible for SEO benefits.
3. @rauchg please if you want to save @nextjs to be deprecated among developers please make app router deprecated or work on a solution which makes app router support ssr always without making it client component and if your team is incapable of doing that then stop using this bad app router client component approach.
4. I tried app router and its not fast even and at the end I had shifted to pages router and I got everything what I wanted.
5. @rauchg please consider my request. Its very sensitive topic and NextJS must consider it for the sake of its life.

[bilalmohib]

@RemyMachado I just found a way using app router to utilize ssr I will soon be posting tutorial to have ssr fully using NextJS soon.
I have found the solution and I can say that yes NextJS app router supports SSR. The problem only comes when you dont know how to utilize App Router Correctly.

[markoleavy]

I confirm app router do support SSR.

[marmikmewada]

the method is different - app router does support ssr its just they made it more usecase oriented. we can use interractive components as client components except marking whole pages as csr using props. it literally destroys the external libraries for state management almost in most real life scenarios but improves performance extremely because of high usage of ssr capabilities even for not public routes

[bilalmohib]

@RemyMachado I just found a way to use App Router in NextJS with SSR always and here is an article.
https://www.linkedin.com/pulse/using-app-router-nextjs-right-way-achieve-ssr-always-muhammad-bilal-sw8ye/
Using SSR Always in NextJS App Router

[markoleavy]

I recently migrate to next app router. I'm quite satisfied with it (I'm also happy with the dev experience, though it was a big confusing at the beginning), I got slightly better performance, but I had to stay with the 13.4.12 to avoid LCP high values.
My question is: was it necessary? Good 'client' react apps perform great even on old devices.

[bilalmohib]

Hi Devs I think now app router is full stable the only problem is most developers dont know how to use it properly.

…

On Tue, Mar 12, 2024 at 5:03 AM hi ***@***.***> wrote: Hello, devs As you can see we have to build the app with App router. App router has a lot of useful functions but it has yet some problems. Because it is on growth now. But I believe Vercel will make perfect App router!. ❤️ — Reply to this email directly, view it on GitHub <#59373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOEOKDOROPCGQSRWZO6H42TYXZH7NAVCNFSM6AAAAABALLLNIKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONJSHEZTS> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>

[maxratajczak]

[ParfectShot]

Exact Same story. I'm quite happy with pages router and don't want to break what is already working. I'm getting crazy performance in pages routes and SEO is working perfectly for Marketing team so don't want to mess that up.

Landed on this discussion as I was starting on a new project and it confirmed my earlier decision that pages router is the way to go

[Kaleshe]

Wish I saw this before I decided to go down the app router route 😢

[j2is]

There is no page transition support in the app router for a year now, so definitely pages for me

[fikriwildannugraha]

Multi-language in App router much more difficult to implement than on page router 😢

[chozzz]

Interesting, I didn't face this challenge at all while migrating from v12 pages router to latest app router with react-i18next.
In fact, its more stable to have locale under directory root, which can support more sophisticated layout in my use case.

[aphougat]

you would need to change the project structure if you were using i18 config in next.config in page router. App router has a strict mapping to folder stricture so create a [lang/locale] folder under app and move everything inside it. Now in middleware simply set the pathname with a locale in the beginning if its missing.

[markoleavy]

I've just written a guide on a strategy to implement server-side i18n on app router with nexti-intl! Take a look!

[zakidze]

just add passing data to root layout and share data between server component and pass data to layouts and server component will much better

[mfa777]

When they strongly recommend using app router, it means that the page router is likely to be deprecated or undergo major changes in future versions.

Even if the page router can still be used currently, for projects that do not require an app router, especially those new projects with their own backend API, it may be worth considering an alternative framework as a better choice.

[cuongzdn]

I noticed that the App router is slower than the Page router even though both are newly created. The App router has a response time of 80ms-130ms, while the Page router only takes 14ms

[ArifAA14]

App router is terrible and if you are using a Windows machine, it gets worse than that.

Its been so much of a bother recently that I have started leaning towards Remix because the app router is just not stable enough. The developer experience has gone down drastically compared to the Pages router. The build and load times have gone through the roof in development and lets not forget the biggest issue - App router hot refresh isn't HOT at all. The documentation is extremely poor and incomplete. Its a disappointment to say the least since NextJS used to be my go to tool for any kind of web work.

Its all good though, we get cool landing pages and billboards!

[Umamad]

Hi everyone, I hope you are doing well.
I've been tracking things that go along with the app router and I'm looking for an opportunity to switch to the app router. However, the app router only brings limitations for me and I can't handle things freely within it. Things like multi-language support, separate server and frontend in one file, etc., really create quite a mess in the app router.

In conclusion, I have preferred the page router for almost 2 years now and I'm certain to continue with the page router. If the page router gets deprecated, I will switch to Remix or Laravel. I hope the Vercel team understands the priorities for developers.

[maxratajczak]

Same here, if it gets deprecated I'll be looking for something else.

[vintageplayer]

Same Here. I've continued sticking to Page Router. It's super convenient. I'll switch to a different framework if I don't get the same development experience as Page Router.

[m-mudassar]

App router is just a mess created by vercel team. I just used int a project and it is confusing everytime with client or server components.

1. My team usually used Next Js as our frontend part of the application and use multiple backend services. We were used to directly calling the apis from the client side. Now we have to do a whole lot of mess to do just the API call.

2. There is an overhead to making API calls to the backend part which is build on the laravel or any other backend language. Now we have to first GET it on the Next js server and When posting back we have to again POST back to laravel e.g. pagination.

3. We were supposed to save the token in HTTP only cookie for authentication which is a whole mess in App router.

There are more use cases like this.
App router is just limiting my team to think.

[akhrarovsaid]

I've really tried to love the app router... I just can't support a framework that releases version after version filled with problems.

Do you know how terrifying it is to build out a beautiful application only to discover a critical error, leading you to a closed GitHub issue with 50 comments in it. You'd think the issue being closed would mean there's a solution right? Nope. Some problems have been unsolved for years, and all the issues around it are closed because the Next team claimed to have either solved it, or the stale-bot closed it after two weeks of inactivity.

So... you can build a whole app, discover some critical error, and now what? You can try switching Next versions, but where one problem gets solved another one manifests. On some versions build fails with cryptic errors, on another build works but in production all your images are broken, or your instance has symptoms of a memory leaks caused by them.

I am completely turned off by Next v13+ and I avoid App router like the plague and will not migrate to 13+ until these issues are solved. I no longer use Next as part of my go-to stack. Incredibly disappointed.

[vitalijalbu]

### Too painful the app dir... switching to pages

read-more
I know SSR can be a "faster" solution but maan, I spent a week and still cannot create a simple datatable with dummy JSON (using rc-table)... page is server side, buttons to edit must be client, datatable component also must be client 😅... if you have a modal to edit and save, it's a suicide...
if you want to create re-usable components app dir is not the solution...

no comment... maybe I'm wrong, but show me a real world example with complete SSR 👀

[morgan2893]

Which is better to use for performance: app-based routing or page-based routing?

[ghost]

in my opinion, pages is the most beautiful and faster way to make apps.

[Ashish-Ban]

Using page router is simplicity in terms of developer experience and time to build the entire application, using app directory makes things more complex, like using authentication systems, intermixing of client components and server actions, all just makes development really worse and too much time consuming, taking away most of time focusing on the framework complexity instead of focusing on features and getting things done. I hope that vercel team will make things simpler for app directory or fallback to page router. As of now I go through app directory docs, lot of places app directory docs still have references or example from page router, which itself makes learning difficult. Not having proper docs takes away lot of time, with page router we have proper docs, easy to learn and use.

[Ashish-Ban]

For those who are confused on usage I hope this will help you.

1. 'use server' and 'use client' are used to decide where the actions will run but it does not matter or does not affect where it renders. If you use 'use server' or 'use client' in both cases it will be rendered on server only (SSR). Actions !== Rendering

2. In case of authentication you can use next/cookies to get the cookies on server side and similarly use some libraries to get the cookie in frontend also. For more proper auth implementation you should research a bit on specific authentication which you are using so you get clarity on the workflow of authentication, then look at next/cookies and next-auth or any other auth libraries, then you can easily implement.

3. Which ever authentication you have, and how you used to do it in a normal react app using vite react or cra app same principles can be used here also but those client actions should be marked with use client. For functions which require session or cookie or jwt in backend mark those with use server. Just by doing these you can follow rest of the things as if you were to do in a normal vite react or cra app.

4. When ever you need user interaction or you need to use useEffect/useCallback/useMemo or any hooks etc then it should be marked with 'use client' and it is mandatory

Please read this and also keep this note as a reference and when ever you feel confused just read and go through this note and it will help you clear some confusing concepts of next.js. These are somethings I realized after spending some hours through all the docs, to get a project working with app directory and authentication ( using next auth and also without using next auth ).

[MrVibe]

My app is stable, working great. I am sticking with Pages router.
I just can not find the time or the motivation to re-build everything again, it seems such waste of time.

[pdparchitect]

Page Router is like 100x simpler and more convenient than the App Router.

The App Router is just constant influx of problems. It is constantly breaking with every minor release. New errors and performance degradation issues arise at unexpected pace. All the talk of the App Router being more performant is a complete nonsense as that will entirely depend on the application type and its data access patterns. The whole idea of splitting everything into tiny files and scattering it all over the filesystem reminds me a lot of Java - more unnecessary cognitive load. Sometimes you need to create just wrapper components to satisfy some 'use client'/'user server' warning. Honestly it is not worth it. If you value your sanity stick to the Page Router.

A fork of NextJS will be imminent if the page router gets deprecated.

[truong0vanchien]

I really regret to start my project with Nextjs. Could the team please make the compile process faster? How can I develop a webapp with this kind of slow?

[tecknovice]

In my opinion, the moment when the react server component was born marks the end of SSR framework like NextJS. So the NextJS team has to find a way to survive a little more time by introducing APP ROUTER

[kaylarose]

Apologies in advance to the dev team, but this is the harsh truth IMHO: Why the hell would (should) anyone need to go through these hoops to build a legitimate production project in 2025?

Stability && Documentation => Dev Experience => Framework && Business adoption => More adoption and more money for Vercel and Next.js team. However as @akhrarov @pdparchitect and many others have said above (and all over reddit, stackoverflow, medium, etc), there seems to be a disconnect. The core team seems to be stuck in the past, stuck in a bad architecture, or both? All the while not listening to many many many developers asking for stability of very basic features (I encourage a quick google - this thread alone started in December of 2023, and is still getting comments from last week!).

Vercel is a is great and and makes bootstrapping something with Next.js a 5 minute/few-click process, but is an untenable for anything more serious than (maybe) a quickly deployed SSR Hello World hobby SPA (of which there are many simpler solutions now). And forget it if you want to package it as anything for other platforms if there is any actual dynamic functionality, or if you want an actual team of multiple developers to maintain any production project at scale....

As a fullstack engineer experienced with shipping large scale projects while working through (and being very forgiving of) the rough edges and imperfectness of evolving JS frameworks, React and React native, Flutter, Ionic, native, Node, Flask, RoR yadda yadda. and all the various big PaaS providers - all of which still have their own their own headaches (and some of which I have actually been an employee of) - the only one I regret using to bootstrap a project is the Next.js, React & Vercel combo.

The Next.js & Vercel coupled architecture, poor and outdated documentation, constant regressions, and hand-wavy responses to community concerns, PRs or Issues (if there is any response at all) is a deal breaker. Next.js is overcomplicated for what it want's to be (a "faster" web-only/static SPA framework? ala 2016...?) which often doesn't work if you want to do anything remotely normal like i18N, SSO Auth, supporting dynamic routing for use with a native wrapper ala Capacitor, etc. without massive workarounds and hacks. These basic things have been a solved problems in many other fullstack solutions for many years now, but having core developers themselves ack but do nothing about for years, while also not providing guidance to the community or even accurate documentation or when many people hit the same wall is the biggest concern.

[kaylarose]

PS I wanted to love this stack. So much potential.

[Badestrand]

is an untenable for anything more serious than (maybe) a quickly deployed SSR Hello World hobby SPA

Ok that's absolute hyperbole. Next.js gets used for serious and widely used websites. One of my own has a million views per month and performs super well. I worked on another that gets doezens of millions of views per month. The tech is solid, even though I am also very critical about the transition to the app router, IMO that was the wrong direction and now just VERY frustrating to develop.

Next.js is overcomplicated for what it want's to be

Yes, IMO that's at the center of things; but to me it feels less like a team stuck in the past and more some devs fresh from university came in, started to hyper-optimize everything and are happy to sacrifice backwards-compatibility and understandility for it.

[Ashish-Ban]

Actually when people search about react framework for SEO or in general best framework for SEO Nextjs pops up and it says Nextjs simplifies and saves a lot of time of developer when working on SEO. But in reality it seems like we have to keep hitting our heads on the wall forever as we are always with one issue or the other with next. If this many issues were there I really would have preferred to use plain old react and do the entire SSR thing and that wont take much time compared going through this bs.

[Strangersknowme]

I usually worked with the pages router and since I was starting a new project as part of a bigger project as a seperate service, I decided let's give app router a try as that makes data fetching easier and so I started building with it.

After using it for 2 months, I can definitely say that app router has the worst DX ever. I use a DRF api as my backend service that I fetch for content. I will list all the problems that I have encountered so far:

Let's start with the most basic one, the middleware - it doesn't have caching. For so much talk of caching with nextjs you would assume that the middleware would have such a basic thing locked down right? WRONG. I already have an api endpoint, to go around this, I had to create a seperate api endpoint in the app folder which fetched the data from my backend service then served it to the middleware to be able to use caching.

Loading states, they are the worst and finicky piece of software that I have ever encountered, you click a button to navigate to a new page, it takes a long time to even tell you if it is even navigating to the page or not even. It waits a while then shows us the loading page for the particular page. Shouldn't that be instant? I click to go to another page, it should show the loading page immediately, but no. Since, as I discovered on an issue, all this communication happens using rsc with your server then it shows the loading page because your server has no idea of your page navigation. Just great.

Another thing is that using client components in server components sometimes cause weird mounting issues with using useEffect hooks, it doesn't run at all sometimes.

I only shifted to the app router because I had a need for layouts but all the work that I did, I have to refactor again to use with pages router now because it is so slow and the DX is just worse.
I am not touching app router again. Pages router is just perfect, if they added layouts to it, we wouldn't even need all this extra crap of app router.

rant over.

[orlein]

I love app router. Whatever haters going to say, it becomes a new standard for the latest next.js projects. I can pick what to cache or what to render dynamically. It's so intuitive!

[Badestrand]

I just want to say that even now on my 4th project on app router I still find it confusing; client components are supposed to be rendered in the browser but are actually also often SSR, except if you use useSearchParams, even though that should also be accessible on the server. To me the line between SSR and CSR seems so blurry, just confusing. There seem to be 3 tiers of rendering (SSR, maybe-SSR-maybe-CSR and strictly CSR). The App router was a mistake and I think that's also why they don't deprecate the Pages router.
Plus, it's so much harder now to find answers on the web because you also have to figure out first whether what you found is for your own router type. Similar disaster as with Python 2 and 3.

[LarsFlieger]

I think the App Router is absolutely the right direction for Next.js. When building web products, the top priority should be delivering the best possible experience for the end user.

While SSR and the Pages Router improved FCP and SEO, rendering static content in the browser, especially on mobile, is inefficient and unnecessary. React Server Components solve this elegantly, enabling fast, battery-friendly experiences.

That said, the developer experience still needs improvement. From my teaching experience, many developers struggle to grasp how RSC works, even after working with Next.js for a while. Clearer, simpler documentation and educational materials would go a long way in helping devs understand and adopt this new paradigm.

[Badestrand]

RSC itself are great. The problem is that they overhauled the whole framework instead of fitting the Server Components into the Pages Router. They changed just enough to make everyone super confused, introduce severe limitations, chose a confusing architecture and very difficult mental model and also didn't document it well.

They should have provided a useServerData hook or similar to components that do the server-side data fetching, instead of 'use client/server' and work from there. And maybe NOT change the entire interface of how to interact with the next.js core.

[Strangersknowme]

Thank you for saying this. This is what I have wanted for RSC as well. RSC is great. I don't understand why did they decide to rebuild everything with a new architecture and way to do things instead of just being able to use them in the existing almost perfect pages router. There is only one thing missing in pages router and that is layouts. When you have complex apps like an ecom storefront, it makes sense to have different nested layouts where you don't have to recreate the page with the same layout which is what we currently have to do in pages router.

I came from python world(read Django), so I only understood server centric features which is what RSC is trying to do, they are going backwards now. You can't build complex interactive apps with sever side frameworks, it just doesn't make sense.

I love pages router and I will keep cursing the next.js team, time and time again imo for their stupid decision to go RSC first.

[PerlBug]

I have been using NextJS since 2018 and every new update seemed like a good step forward until app router.
I have tried to use the App router but the added complexity is not worth it for the very marginal gains in supposed performance.

I would not recommend the use of App router at this stage. The company I work at has a very large website and migrating it to app router has been a nightmare with many basic things supported in Pages router now not working easily in App router.

[vyatsun]

Next 13 Pages Router was a great product, but I'm amazed how bad it became with the Next 15 App Router. It takes 15-20 seconds for every page to reload on save on my Core i9 16GB RAM laptop with Turbopack enabled. This makes debugging virtually impossible. It's the worst thing that has happened in my developer career since the need to support the Internet Explorer browser. Working with Next became a sheer pain.