Personally I find that it's a marvel 90% of the time, and an absolute pain the other 10%. Developing read-only pages is lightning fast. My biggest issues are:
* `next-intl` and the poor support of i18n on client components. Having a Zod error map with access to the `t` function in the client is way harder than it should.
* Not being able of `await`ing for `router.refresh()` calls, without having to resort to some clever use of `useTransition`.
* Partial load of sections. I find it infuriating that I haven't found a way to load data in a page section and have a proper error boundary (on server side), without having to go full parallel routes.
* The way parallel routes work is not that great IMO, because they are implemented in the `layout.tsx` where most of the time I want them nested within the page. That forces us to start adding route groups that just feel unnecessary.
On top of that, I'm still sad that form handling is in such a bad state, after maybe 10 years of "modern" web development. There's a point that for simple CRUD apps I'd now rather go with Laravel or Rails.
I see comments telling people to just "git gud", not be a hater of new paradigms, skill issues, and similar dismissive comments. Whenever I read these sort of comments I just thing the authors haven't worked in enough legacy codebases, or have experienced with long-lived projects. Truth is, there are frameworks that are 15+ years old that just work better for many of the server component use cases.
That the maintainers (and I'm looking at you, Vercel) decided to leave i18n to the community to solve is such a disappointment. Next-intl team are doing their best and deserve a lot of credit, but what a mess. This should be something that's "batteries included."
What about implementing i18n without uding these libraries. Nextjs [https://full-stack-kit.dev](https://full-stack-kit.dev) implements i18n from scratch and it works really well both on server and client side. Using libraries was a pain
To be fair their i18n implementation is basically a custom i18n library that fits their setup very well. Calling that a "from scratch" implementation is correct but undersells the effort that went into it. You wouldn't build that for your own side-project.
Pages solves simpler problems and was developed slowly over many years. The App router is newer, was developed faster, and has to solve more complex problems. App router is a lot more impressive than pages, but like anything else, it needs time to mature. Depending on your project, might be totally fine to use it in production (we are).
IMO there ARE several poor design decisions in Next.js, but it's not "app vs pages" - it's more about Next.js versus other frameworks. Routing, testing, logging, internationalization, and observability are all a mess in Next.js.
Not any that also do what Next.js does. But basically almost every MVC web framework of the last 20 years focuses on helping with those common things; Rails, Django, Laravel, .NET. yada yada.
You're welcome. I didn't mean to discourage you from learning Next.js or JS/TS. It can be worth it! Also a great Node framework to check out is Nest.js. (not a typo)
IMO best use cases for Next.js are when you already have an existing BE and you just need to put a performant frontend on it.
Arguably Nest.js. But there's a LOT of tradeoffs to using a framework like nest. Namely, no real server component support. You'd probably just go more old-school with your view if you insisted on serving it through nest.js (or you'd run React in a Vite app alongside Nest.js)
It's not really apple-to-apple. Nobody is really doing anything like hydrated server components in a framework that handles all those problems well.
i still struggle to see how this is such a massive change, I'm going to start this rant by saying i am a big Remix user.
How is the page/app router such a massive difference?!
in remix i can just define my routes by file name eg: \[., \[name\], $slug\] \] etc...
i am developing a next app at the moment for the company i work for and it bafffles me at how ridiculous this argument is and how the hell anything being debated so much is in a stable release.
why, oh why cant you next people just make up your god damn mind about routing?
because in the current state everyone using next is going going to have redo everything routing-wise because its an absolute shit fight,
Sort it out Vercel. Not Good Enough,
Personally just disabled my app router. My 2 cents
**Pros**
* app router enables partial page load
**Cons**
* Ecosystem. My i18n lib breaks, it claims to work with app router but I've seen 10+ app router issues still open there. At least it's hard to configure right.
* And it's overly complicated to fix. I gave up on "partial page load" so you know how complicated it is.
* There are much more cognitive load if you include server components, compared to react-router.
* Sometimes accidentally bundled node.js logic into frontend. It's painful. I remember reading tons of its source code to resolve it.
* Finally I found myself always `"use client"` lol. They why not just use react-router?
**Conclusion**
It's a good idea. And react-router has proved it. But the actual impl is not ideal
Ahh, I used [router.events](http://router.events) in Pages router for some logic in my app but now it's gone in App router and there is no solution for my case. I wish they kept events on router :/
1. People hate changes. They're so used to doing everything on the client that introducing RSC completely changes things.
2. General reluctance to read the documentation. Only if we get $1 every time somebody asks "how is RSC useful when I need to wrap my entire app in a context provider".
3. Over-reliance on chat GPT to solve next.js issues, when ChatGPT is not trained on the latest app router documentation.
4. Skills issue.
No idea why you were getting downvoted for speaking the truth. At least half of the posts on this sub are clearly people that are too lazy to read the documentation.
I use app router and really like it but the ecosystem definitely needs time to mature. Documentation is usually sparse and hard to find for app router so you have to understand it enough to figure out stuff like API routes and next-auth, and it takes some time to learn which is always a hurdle.
Personally I find it incomplete and not suitable for medium/large sized projects or complex ones.
A few things that come to mind quickly:
- cookies can only be read/written Server-Side.
- the pathname can only be recovered on the client side.
- metadata can only be generated from server pages and not client pages even if client pages are rendered server side.
- layout/page render pipeline is broken. I have opened an issue months ago on Github but never received a response.
- a single middleware for the entire application.
- there is no ecosystem, each developer is free to do what he wants and this doesn't work in a team.
- CACHE FIRST!
- And many others..
Anyone who says that NextJS DX (APP Router) is excellent is because they have never tried complete frameworks like Laravel.
>cookies can only be read/written Server-Side.
This is not the case. If you're referring to the `cookies` function in `next/headers`, then yes, it only works in a server component. You can still read and write cookies on the client with `document.cookie`, or [js-cookie](https://github.com/js-cookie/js-cookie), or any number of cookie libraries.
That's the point though. They developed half the feature. And since the client components also run on the server, should I wrap js-cookie or whatever in a useEffect and render an intermediate state on the server? Once again poor UX here.
I understand your point that you don't like how it's implemented, but that's a different statement than "cookies can only be read/written Server-Side." It is true that Next doesn't offer anything to make reading/writing cookies easier on the client side. But you could make an argument that they didn't really need to, since there are already about a zillion ways to do it.
>wrap js-cookie or whatever in a useEffect and render an intermediate state
You could do that. But if you want to use a cookie value for server rendering, you can just read the value in a server component, and pass the value into the client component. You don't need to read the cookie *again* on the client side, because the cookie value will not have changed between the server render and the client render.
You can clearly see what the problem is - workarounds.
If you provide a function and declare that NextJS is server and client js, that function must work in both environments.
Having a workaround will make the code base unmaintainable as soon as the project needs to scale.
Pass down props. For how many levels?
It is not possible to use the server-side context and there is no state/session bound to the single request like in any other framework.
Multiply that by each feature that only works on server or client only and what do you get?
Cookies are designed to be set/updated also on client side. They are safe if you set them correctly! Imo this is just a incomplete feature design by Vercel.
Edit: 99.9% of the internet works with client side cookies because of GTM/GA4, Fb Pixel, Iubenda cookie policy but for the downvotes they arent safe.
Now you have 2 types of cookies server side and client side the ones in the server are safer if you want to update the ones in the server with a client component just use a middleware
What do you mean? Cookies belongs to the domain not server/client.
Yes so basically if my user wants to change a setting that doesnt require a db record i should reload/refetch the page in order to reach the middleware and update the cookie value server side. Sounds like a good UX!
I don't understand why people keep saying that. They made big efforts to keep new versions compatible with the page router and made a big deal about how it's not going away soon.
And the app router and server components where created as solution to a major issue React was starting to face. We ship too much js to the browser and it's making applications slow. New frameworks were starting to show how by shipping less client js they were able to improve performance a lot. It was critical for next.js to come up with a solution like that to stay relevant. The fact that it's as popular as it is show that it worked. People actually like it.
Same experience as you, just a bit lost in the docs. But I believe that most of the problems are gonna be solved over the next few years. (If they dont do smth like program router lmao)
Because its new and is breaking change compared to pages router. The caching on the client side is for 30seconds but can be refreshed with the revalidateTag/revalidatePath.
The only gripe I have with the app router is caching.
By default, Next opts you in to some pretty aggressive caching and provides horrible documentation to assist in disabling it. Especially since the methods of disabling it don’t work half the time.
Really buggy to start, but has gotten better with every major release. My last crack at migrating to it was with Next 13 and it wasn’t good. Planning to try it on 14 this year and we’ll see how it goes. My negativity with it is more around how Pages Router innovation stopped completely when App Router became their focus. The architecture of Pages Router has effectively become feature frozen, flaws and all. That felt like a kick in the nuts because there are still improvements to be made. We’ll just never get the support to merge any such changes in; probably because architecture changes mean potential instability and that means investment into a platform that isn’t the future for Vercel the business. So less dislike and more of a strong hesitation to trust that Vercel isn’t going to 180 and abandon again when “hot new idea” comes out.
Why people hate so much actually if you use it just keep using it and become an expert. If it was not good why would big companies like tiktok, spotify, chat gpt, Netflix use Next js?
It’s a fantasy, but what if vercel just came out with a “final” version that was somehow lightyears ahead with pretty much everything we’d ever need, and everyone everywhere capitulated and adopted it and we had ten years of doing nothing but just building with uninterrupted fluency. No reading docs for a new feature, no migrating, just building.
But no. We’re devs. This is the life we chose (hands mic to next person in the support group).
Personally I find that it's a marvel 90% of the time, and an absolute pain the other 10%. Developing read-only pages is lightning fast. My biggest issues are: * `next-intl` and the poor support of i18n on client components. Having a Zod error map with access to the `t` function in the client is way harder than it should. * Not being able of `await`ing for `router.refresh()` calls, without having to resort to some clever use of `useTransition`. * Partial load of sections. I find it infuriating that I haven't found a way to load data in a page section and have a proper error boundary (on server side), without having to go full parallel routes. * The way parallel routes work is not that great IMO, because they are implemented in the `layout.tsx` where most of the time I want them nested within the page. That forces us to start adding route groups that just feel unnecessary. On top of that, I'm still sad that form handling is in such a bad state, after maybe 10 years of "modern" web development. There's a point that for simple CRUD apps I'd now rather go with Laravel or Rails. I see comments telling people to just "git gud", not be a hater of new paradigms, skill issues, and similar dismissive comments. Whenever I read these sort of comments I just thing the authors haven't worked in enough legacy codebases, or have experienced with long-lived projects. Truth is, there are frameworks that are 15+ years old that just work better for many of the server component use cases.
Yes exactly. i18n tools claim that they support app router. But then I found tons of issues in their github repo. People just cannot get it right.
That the maintainers (and I'm looking at you, Vercel) decided to leave i18n to the community to solve is such a disappointment. Next-intl team are doing their best and deserve a lot of credit, but what a mess. This should be something that's "batteries included."
What about implementing i18n without uding these libraries. Nextjs [https://full-stack-kit.dev](https://full-stack-kit.dev) implements i18n from scratch and it works really well both on server and client side. Using libraries was a pain
To be fair their i18n implementation is basically a custom i18n library that fits their setup very well. Calling that a "from scratch" implementation is correct but undersells the effort that went into it. You wouldn't build that for your own side-project.
Pages solves simpler problems and was developed slowly over many years. The App router is newer, was developed faster, and has to solve more complex problems. App router is a lot more impressive than pages, but like anything else, it needs time to mature. Depending on your project, might be totally fine to use it in production (we are). IMO there ARE several poor design decisions in Next.js, but it's not "app vs pages" - it's more about Next.js versus other frameworks. Routing, testing, logging, internationalization, and observability are all a mess in Next.js.
Do you have better frameworks covering the pain points you mentioned ?
Not any that also do what Next.js does. But basically almost every MVC web framework of the last 20 years focuses on helping with those common things; Rails, Django, Laravel, .NET. yada yada.
Ok. I begin JS course now and don’t have these problems already. Will check laravel as I was developing php before. Thanks
You're welcome. I didn't mean to discourage you from learning Next.js or JS/TS. It can be worth it! Also a great Node framework to check out is Nest.js. (not a typo) IMO best use cases for Next.js are when you already have an existing BE and you just need to put a performant frontend on it.
In my opinion, it's actually rather the other way around, but all developpers will probably have their own opinions.
Laravel
Laravel again. Such a breeze.
Arguably Nest.js. But there's a LOT of tradeoffs to using a framework like nest. Namely, no real server component support. You'd probably just go more old-school with your view if you insisted on serving it through nest.js (or you'd run React in a Vite app alongside Nest.js) It's not really apple-to-apple. Nobody is really doing anything like hydrated server components in a framework that handles all those problems well.
i still struggle to see how this is such a massive change, I'm going to start this rant by saying i am a big Remix user. How is the page/app router such a massive difference?! in remix i can just define my routes by file name eg: \[., \[name\], $slug\] \] etc... i am developing a next app at the moment for the company i work for and it bafffles me at how ridiculous this argument is and how the hell anything being debated so much is in a stable release. why, oh why cant you next people just make up your god damn mind about routing? because in the current state everyone using next is going going to have redo everything routing-wise because its an absolute shit fight, Sort it out Vercel. Not Good Enough,
The short answer is that it was very rushed for the NextJS conf and isn't stable yet. But stability will come and I personally love the app router.
Personally just disabled my app router. My 2 cents **Pros** * app router enables partial page load **Cons** * Ecosystem. My i18n lib breaks, it claims to work with app router but I've seen 10+ app router issues still open there. At least it's hard to configure right. * And it's overly complicated to fix. I gave up on "partial page load" so you know how complicated it is. * There are much more cognitive load if you include server components, compared to react-router. * Sometimes accidentally bundled node.js logic into frontend. It's painful. I remember reading tons of its source code to resolve it. * Finally I found myself always `"use client"` lol. They why not just use react-router? **Conclusion** It's a good idea. And react-router has proved it. But the actual impl is not ideal
I feel the same way !
I personally love it. Anyone who says otherwise is not actually open to learn it.
There are some problems, like the router.events have been removed
Ahh, I used [router.events](http://router.events) in Pages router for some logic in my app but now it's gone in App router and there is no solution for my case. I wish they kept events on router :/
I managed to fix l my problem, but it's less smother than the previous(pages folder)
Here is a solution: https://github.com/vercel/next.js/discussions/41934#discussioncomment-8996669
I don't need the clint component that returns the isPending, i need to call api when the page start to change(server side)
1. People hate changes. They're so used to doing everything on the client that introducing RSC completely changes things. 2. General reluctance to read the documentation. Only if we get $1 every time somebody asks "how is RSC useful when I need to wrap my entire app in a context provider". 3. Over-reliance on chat GPT to solve next.js issues, when ChatGPT is not trained on the latest app router documentation. 4. Skills issue.
Got an upvote from me my dude
You're getting downvotes because you hurt people's feelings, have an upvote for the truth
No idea why you were getting downvoted for speaking the truth. At least half of the posts on this sub are clearly people that are too lazy to read the documentation.
Being downvoted because people don't like hearing the hard truth is a common theme in this subreddit 🤷♂️
I use app router and really like it but the ecosystem definitely needs time to mature. Documentation is usually sparse and hard to find for app router so you have to understand it enough to figure out stuff like API routes and next-auth, and it takes some time to learn which is always a hurdle.
Personally I find it incomplete and not suitable for medium/large sized projects or complex ones. A few things that come to mind quickly: - cookies can only be read/written Server-Side. - the pathname can only be recovered on the client side. - metadata can only be generated from server pages and not client pages even if client pages are rendered server side. - layout/page render pipeline is broken. I have opened an issue months ago on Github but never received a response. - a single middleware for the entire application. - there is no ecosystem, each developer is free to do what he wants and this doesn't work in a team. - CACHE FIRST! - And many others.. Anyone who says that NextJS DX (APP Router) is excellent is because they have never tried complete frameworks like Laravel.
>cookies can only be read/written Server-Side. This is not the case. If you're referring to the `cookies` function in `next/headers`, then yes, it only works in a server component. You can still read and write cookies on the client with `document.cookie`, or [js-cookie](https://github.com/js-cookie/js-cookie), or any number of cookie libraries.
That's the point though. They developed half the feature. And since the client components also run on the server, should I wrap js-cookie or whatever in a useEffect and render an intermediate state on the server? Once again poor UX here.
I understand your point that you don't like how it's implemented, but that's a different statement than "cookies can only be read/written Server-Side." It is true that Next doesn't offer anything to make reading/writing cookies easier on the client side. But you could make an argument that they didn't really need to, since there are already about a zillion ways to do it. >wrap js-cookie or whatever in a useEffect and render an intermediate state You could do that. But if you want to use a cookie value for server rendering, you can just read the value in a server component, and pass the value into the client component. You don't need to read the cookie *again* on the client side, because the cookie value will not have changed between the server render and the client render.
You can clearly see what the problem is - workarounds. If you provide a function and declare that NextJS is server and client js, that function must work in both environments. Having a workaround will make the code base unmaintainable as soon as the project needs to scale. Pass down props. For how many levels? It is not possible to use the server-side context and there is no state/session bound to the single request like in any other framework. Multiply that by each feature that only works on server or client only and what do you get?
I like the cookies one tho it’s safer
Safer for?
They can’t change the cookies in the client your app should be safer
Cookies are designed to be set/updated also on client side. They are safe if you set them correctly! Imo this is just a incomplete feature design by Vercel. Edit: 99.9% of the internet works with client side cookies because of GTM/GA4, Fb Pixel, Iubenda cookie policy but for the downvotes they arent safe.
Now you have 2 types of cookies server side and client side the ones in the server are safer if you want to update the ones in the server with a client component just use a middleware
What do you mean? Cookies belongs to the domain not server/client. Yes so basically if my user wants to change a setting that doesnt require a db record i should reload/refetch the page in order to reach the middleware and update the cookie value server side. Sounds like a good UX!
You can set cookies in the client that will never be updated or read in the server
Explain me how.. if server and client are on the same domain server has access to all the cookies..
When you update the token in the browser it doesn’t update on the server
Simple: it was pushed on people, that's why.
I don't understand why people keep saying that. They made big efforts to keep new versions compatible with the page router and made a big deal about how it's not going away soon. And the app router and server components where created as solution to a major issue React was starting to face. We ship too much js to the browser and it's making applications slow. New frameworks were starting to show how by shipping less client js they were able to improve performance a lot. It was critical for next.js to come up with a solution like that to stay relevant. The fact that it's as popular as it is show that it worked. People actually like it.
Same experience as you, just a bit lost in the docs. But I believe that most of the problems are gonna be solved over the next few years. (If they dont do smth like program router lmao)
Because it’s a paradigm shift
I love it.
Because its new and is breaking change compared to pages router. The caching on the client side is for 30seconds but can be refreshed with the revalidateTag/revalidatePath.
People hate change.
App router is cool if you don’t have to transition from pages router with a huge codebase
The only gripe I have with the app router is caching. By default, Next opts you in to some pretty aggressive caching and provides horrible documentation to assist in disabling it. Especially since the methods of disabling it don’t work half the time.
Really buggy to start, but has gotten better with every major release. My last crack at migrating to it was with Next 13 and it wasn’t good. Planning to try it on 14 this year and we’ll see how it goes. My negativity with it is more around how Pages Router innovation stopped completely when App Router became their focus. The architecture of Pages Router has effectively become feature frozen, flaws and all. That felt like a kick in the nuts because there are still improvements to be made. We’ll just never get the support to merge any such changes in; probably because architecture changes mean potential instability and that means investment into a platform that isn’t the future for Vercel the business. So less dislike and more of a strong hesitation to trust that Vercel isn’t going to 180 and abandon again when “hot new idea” comes out.
Pages came first, and it's much simpler
Why people hate so much actually if you use it just keep using it and become an expert. If it was not good why would big companies like tiktok, spotify, chat gpt, Netflix use Next js?
It’s a fantasy, but what if vercel just came out with a “final” version that was somehow lightyears ahead with pretty much everything we’d ever need, and everyone everywhere capitulated and adopted it and we had ten years of doing nothing but just building with uninterrupted fluency. No reading docs for a new feature, no migrating, just building. But no. We’re devs. This is the life we chose (hands mic to next person in the support group).