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 believe it's supposed to 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]

#65958

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

[vitali-bc]

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.