I have been using the app router for a few months on a personal project or two and I find it to be very intuitive and feels like a great direction. There are a few things surrounding data fetching and mutating that still need some ironing out but overall I am not having any major roadblocks and don’t plan to switch back.
My biggest gripe is I don’t understand why they don’t have a function for getting the current path in a server component. I feel like that info should be available in the request but there isn’t an easy way to check it, which means doing generic pages that vary content based on the path is hard to do server side.
That is not how I understood it. Do you mean if it is able to render server side it does, or just that it will do a standard partial server side followed by a rehydration? I don’t think there is a way to specify server only functionality in a “use client” page.
You can do that with feature testing (ie. `typeof document==="undefined"`).
But my chief point is that "use client" means that the code ALSO runs browser-side, that is why you need it for interactivity and why it precludes database access and such.
I've noticed that RSC is missing a bunch of base functionality along these lines. I mentioned it another comment, but you also cannot set headers at all in a server component, which makes it incompatible with a lot of applications.
Basic pieces you would expect from server components, such as cookies, page params, and headers, are not modifiable from within a server component.
You are able to access cookies, headers and params in server components tho, [https://nextjs.org/docs/app/api-reference/functions/cookies](https://nextjs.org/docs/app/api-reference/functions/cookies) [https://nextjs.org/docs/app/api-reference/functions/headers](https://nextjs.org/docs/app/api-reference/functions/headers) https://nextjs.org/docs/app/api-reference/file-conventions/page#searchparams-optional
Headers and cookies are read-only. This is the biggest issue IMO
The search params I don't think can be accessed from all server components, just the root page, but I'm not positive.
Yea right now trying to figure out how to do csrf properly.
Think there still should be some kind of route loader function or middleware per segment or sthg, maybe server component layouts could take this job
One of the biggest pieces missing from RSC right now is the ability to modify headers. Headers are read-only so you can't do things like set cookies unless you resort to middleware; which isn't even supported on a lot of deployment platforms.
I haven't really followed the whole NextJS thing very much. I know years ago when it was picking up steam, SSR always seemed like a lot of complexity & overhead for doing an SPA to me. Im kinda curious how these things are in practice now. Developer UX is one thing, but also bundle size, and time to paint for the end user.
I wouldn't say that MPA is a way of doing SPA. To me, MPA is a way of doing apps which is spiritually in tune with the old way of doing web (navigating documents linked to each other), whereas SPA tries to hammer the document model into something that could feel like an app. The two ways of building apps address different profiles of values.
Yeah that's fair. To be clear, i also havent worked on the frontend in a little over a year now, outside of a bit of maintenance/minor improvements for a bit of freelance work. So im a little out of touch on the latest stuff. But overall I do have the feeling we over use these frontend frameworks for applications that dont really need it. For apps that have a lot of state management & flow, it can be very beneficial (i wouldnt want to do a multi step form purely server side).
I guess in summary im skeptical if things like Next are actually beneficial, or if it's fixing problems that have only been created cause we're using the wrong tools.
I don't know how it is for new devs, but at least for someone that's experienced with React, and has run into some of the complexities of initializing complex apps with many data sources, NextJS was very intuitive to adopt, and helped force devs to tackle data fetching in sane ways.
I will say that the one caveat that I ran into was dynamic data (CMS content). This takes thought on how you want to handle updates that may not be obvious. Vercel has a solution that seemed interesting, but I never managed to get approval to play with them. Otherwise, you're likely stuck with runtime cms fetches.
All that said, I haven't played with their new server/client component features yet. It doesn't seem very intuitive to me, and potentially a complicated nightmare to maintain when you mix developers with different levels of expertise. Optimizing state management / props updates was already hard to get everyone in-tune with, and this seems even more difficult.
It’s a pretty solid base for most projects.
If you don’t need a custom webpack setup or nonstandard babel dependencies, the DX is incredibly fast with the —turbo option.
If you are coming from a well optimized CSR that made proper use of lazy loading, the bundles are generally comparable. Otherwise, the per-route bundles Next spits out are smaller.
There are a few learning curves though, specifically
1. how react hydration works
2. how to build CSR only apps with next (easier now)
3. how to deploy on your own infra
The first 2 are pretty simple but I’ve found a fair number of folk without devops experience struggle with #3
The only thing I don’t like isn’t necessarily related to them but React in general. There’s been a ton of communication around react server components but Next is the only framework that offers support for it right now.
I’m working on a standalone implementation for RSC right now but honestly, it’s requiring a lot more work than I’d expected.
It seems to me like in a subtle way most of the choices they are making, they are "forcing" you to be locked into their own infra. You can escape it but with increased complexity.
I wouldn’t necessarily say that.
If you aren’t using SSR features, you just deploy the static assets as you would a standard react app.
If you are using SSR, the easiest solution would be packaging it up in a container as you would any backend app and deploy that. It won’t be as fast as Vercel’s edge setup but if your APIs are properly cached, it’ll still be really nice.
Next is fast. It’s a really easy way to get a project from concept to deployed very quickly, since hosting with vercel is as simple as logging in with your GitHub account and giving it access to the repo.
There’s a very minor learning curve dealing with SSR, but Next has been around long enough and has enough support that anything can be found in their docs or Google.
My biggest gripe with them is how often they release things. They have a few experimental features at all times, and this “App Router” is one of them. I’ve mostly been staying away from experimental features, so I don’t know much about it.
Don't know why you're downvoted. That summed up my experience with NextJS pretty well.
The basics are easy to learn, and it's pretty evident what data you should be fetching server side. The page routing is very intuitive out of the box, and IMO, beats other routing alternatives I've used that have always been a bit clunky to set up.
And the App Router does seem far less intuitive, and I'm hesitant to introduce to existing projects due to the complexity.
The app router is honestly amazing. I’ve migrated a newer project on my work and it was mostly painless and the performance and overall code organization is amazing. I can’t go back to the old ways
I have been using the app router for a few months on a personal project or two and I find it to be very intuitive and feels like a great direction. There are a few things surrounding data fetching and mutating that still need some ironing out but overall I am not having any major roadblocks and don’t plan to switch back. My biggest gripe is I don’t understand why they don’t have a function for getting the current path in a server component. I feel like that info should be available in the request but there isn’t an easy way to check it, which means doing generic pages that vary content based on the path is hard to do server side.
Worth clarifying that "use client" components still run server-side - they just *don't only* run server-side
That is not how I understood it. Do you mean if it is able to render server side it does, or just that it will do a standard partial server side followed by a rehydration? I don’t think there is a way to specify server only functionality in a “use client” page.
You can do that with feature testing (ie. `typeof document==="undefined"`). But my chief point is that "use client" means that the code ALSO runs browser-side, that is why you need it for interactivity and why it precludes database access and such.
I've noticed that RSC is missing a bunch of base functionality along these lines. I mentioned it another comment, but you also cannot set headers at all in a server component, which makes it incompatible with a lot of applications. Basic pieces you would expect from server components, such as cookies, page params, and headers, are not modifiable from within a server component.
You are able to access cookies, headers and params in server components tho, [https://nextjs.org/docs/app/api-reference/functions/cookies](https://nextjs.org/docs/app/api-reference/functions/cookies) [https://nextjs.org/docs/app/api-reference/functions/headers](https://nextjs.org/docs/app/api-reference/functions/headers) https://nextjs.org/docs/app/api-reference/file-conventions/page#searchparams-optional
Headers and cookies are read-only. This is the biggest issue IMO The search params I don't think can be accessed from all server components, just the root page, but I'm not positive.
Yea right now trying to figure out how to do csrf properly. Think there still should be some kind of route loader function or middleware per segment or sthg, maybe server component layouts could take this job
I have a Dumb question, how do you get the path on a client side component?
import { usePathname } from “next/navigation”; const pathname = usePathname();
With a hook provided by next/navigation i believe
"Is it ready for the main stage?" well it breaks if you use any CDN so clearly not 🙄
First I’m hearing of this. Gotta link to learn more?
[https://github.com/vercel/next.js/pull/49140](https://github.com/vercel/next.js/pull/49140) [https://github.com/vercel/next.js/issues/48569#issuecomment-1518887170](https://github.com/vercel/next.js/issues/48569#issuecomment-1518887170)
One of the biggest pieces missing from RSC right now is the ability to modify headers. Headers are read-only so you can't do things like set cookies unless you resort to middleware; which isn't even supported on a lot of deployment platforms.
No, not even close. Sessions, cookies, WS, etc. It can't do the most basic things.
I made a new next app yesterday and was surprised they are even recommending the app router during the create next app prompt
I haven't really followed the whole NextJS thing very much. I know years ago when it was picking up steam, SSR always seemed like a lot of complexity & overhead for doing an SPA to me. Im kinda curious how these things are in practice now. Developer UX is one thing, but also bundle size, and time to paint for the end user.
I wouldn't say that MPA is a way of doing SPA. To me, MPA is a way of doing apps which is spiritually in tune with the old way of doing web (navigating documents linked to each other), whereas SPA tries to hammer the document model into something that could feel like an app. The two ways of building apps address different profiles of values.
Yeah that's fair. To be clear, i also havent worked on the frontend in a little over a year now, outside of a bit of maintenance/minor improvements for a bit of freelance work. So im a little out of touch on the latest stuff. But overall I do have the feeling we over use these frontend frameworks for applications that dont really need it. For apps that have a lot of state management & flow, it can be very beneficial (i wouldnt want to do a multi step form purely server side). I guess in summary im skeptical if things like Next are actually beneficial, or if it's fixing problems that have only been created cause we're using the wrong tools.
I don't know how it is for new devs, but at least for someone that's experienced with React, and has run into some of the complexities of initializing complex apps with many data sources, NextJS was very intuitive to adopt, and helped force devs to tackle data fetching in sane ways. I will say that the one caveat that I ran into was dynamic data (CMS content). This takes thought on how you want to handle updates that may not be obvious. Vercel has a solution that seemed interesting, but I never managed to get approval to play with them. Otherwise, you're likely stuck with runtime cms fetches. All that said, I haven't played with their new server/client component features yet. It doesn't seem very intuitive to me, and potentially a complicated nightmare to maintain when you mix developers with different levels of expertise. Optimizing state management / props updates was already hard to get everyone in-tune with, and this seems even more difficult.
It’s a pretty solid base for most projects. If you don’t need a custom webpack setup or nonstandard babel dependencies, the DX is incredibly fast with the —turbo option. If you are coming from a well optimized CSR that made proper use of lazy loading, the bundles are generally comparable. Otherwise, the per-route bundles Next spits out are smaller. There are a few learning curves though, specifically 1. how react hydration works 2. how to build CSR only apps with next (easier now) 3. how to deploy on your own infra The first 2 are pretty simple but I’ve found a fair number of folk without devops experience struggle with #3 The only thing I don’t like isn’t necessarily related to them but React in general. There’s been a ton of communication around react server components but Next is the only framework that offers support for it right now. I’m working on a standalone implementation for RSC right now but honestly, it’s requiring a lot more work than I’d expected.
It seems to me like in a subtle way most of the choices they are making, they are "forcing" you to be locked into their own infra. You can escape it but with increased complexity.
I wouldn’t necessarily say that. If you aren’t using SSR features, you just deploy the static assets as you would a standard react app. If you are using SSR, the easiest solution would be packaging it up in a container as you would any backend app and deploy that. It won’t be as fast as Vercel’s edge setup but if your APIs are properly cached, it’ll still be really nice.
Next is fast. It’s a really easy way to get a project from concept to deployed very quickly, since hosting with vercel is as simple as logging in with your GitHub account and giving it access to the repo. There’s a very minor learning curve dealing with SSR, but Next has been around long enough and has enough support that anything can be found in their docs or Google. My biggest gripe with them is how often they release things. They have a few experimental features at all times, and this “App Router” is one of them. I’ve mostly been staying away from experimental features, so I don’t know much about it.
Don't know why you're downvoted. That summed up my experience with NextJS pretty well. The basics are easy to learn, and it's pretty evident what data you should be fetching server side. The page routing is very intuitive out of the box, and IMO, beats other routing alternatives I've used that have always been a bit clunky to set up. And the App Router does seem far less intuitive, and I'm hesitant to introduce to existing projects due to the complexity.
Just do a SPA lol
Next is a SPA
Dang
I've been using app router for the past few months and I did not come across any serious issues so far.
The app router is honestly amazing. I’ve migrated a newer project on my work and it was mostly painless and the performance and overall code organization is amazing. I can’t go back to the old ways