I think this is a natural progression that we go through in tech. New things are introduced to solve a problem or make something better, everyone is excited about it, lots of videos are made about it as it is a hot topic, then people realize it’s not a silver bullet that works for every situation. I’m sure like a lot of people I’m using the app router for side projects and even side hustles. However, the production apps I work on at work aren’t getting rewritten for the app directory any time soon.
I tried the app router with server components and i loved it, you can replace trpc pretty much with server components. It`s only confusing that there are no established patterns and best practices so you have to find something that works for you and hope its scales. But still super exicting to have so much new stuff to learn and explore!
As of right now, the /app router is completely useless. It is nearly impossible to disable the cache and get new content when using . Even with revalidate = 0; or fetchCache = "force-no-store"; or prefetch={false} the data remains stale. You may get lucky if you refresh the page but that defeats the purpose of SPA. I'd love to see a minimal working example of Next 13 using and fetching new fresh data every time the link is clicked.
Hi Josh I think you are the most clear to understand teacher I have ever listened too, I feel I am absorbing the most important information from you than any other teacher out there, Because you are so up to date on the tech stack it’s crazy, please keep making these videos man you are one of the best out there :) P.S can’t wait to this new Open-Ai Functions get out there I would love to see how this new open-AI functions work and what the possibilities are as far as calling outside functions to interact with open-AI :)
Thank you Josh. Summary - 1. Routing pages directory uses client side routing while app uses server side rendering. Route map is not required to download in client for app directoy. Granular caching approach with app router. Dx and Ux is better. But pages is battle tested and used in production. 2. SUpport - Not ready yet. All page directory functionalities may not work. You will get more community support for page directory. 3. Performance Slower req per sconds parameter compared to pages directory. Switch incrementally to app routing from page routing for solving issues.
I love how app router works and all the idea behind to move all client stuff to the server. That been said, I still think the support from libraries is a BIG trade off that I'm not sure I want to pay. The beauty about all this, is that both con live together, so you could be using app router and page router as you mention in your video, without any problem :)
Exactly. People have speculated the pages router might be completely removed in Next.js 14 in the future, but judging by how slow corporate adoption for new tech is I am convinced incremental adoption like this will be available for a looong time
Hey Josh, please make a complete tutorial on frontend authentication on react (or next). To understand the complete flow with all possible user interferences.
@@joshtriedcoding In addition I would love to see how you would solve the problem for local dev with next auth, like how you can switch between users without having to use lets say a google auth. This would be helpful if you want to develop when being offline
Thank you for theses videos , i used app router in local env and my project was working fine wine but when I deployed it even before . When building it I had much errors from fetch to urls to revalidating errors that broke the building so I stopped and switched to pages and the project is fine and deployed now
Great video, and having used the app router in a production app I support your final conclusion. It is really nice to work with, and the UX is far superior. We def do need better tooling around the cache though.
The client side has better options for caching unless you want to pay more for server (Vercel). It's puzzling why every Nextjs feature relies on the server.
The app router is good, but the one thing that seems lacking to me with RSC is that you can't do client level caching for the pages that show user specific data, which is needed for a better offline experience in a PWA. Sticking with client components until that somehow magically becomes possible.
One really nice thing about the T3 bootstrap with tRPC is that it give you a centralized endpoint that you can use to pipe additional context/middleware through. This is really nice for things like logging or authorization. I haven't found a nice way to do something similar with the app router. I might not have found it yet or it might simply be that nextjs is moving away from that paradigm (I guess the app router is more 'serverless' in that sense) . This plus type safety on requests are two things I think that are still missing from the app router. I hope Vercel look at how Nuxt handles their type safe requests. They do it in such an awesome way.
To me app router is more declarative than page router. it has certain rules/convention to follow and has lesser control to do conditional stuff. rather page router is more imperative and devs has much more control over whole app.
Seems like App Router's deployment was rushed. Some of the new routing changes could've been implemented incrementally so that there wasn't such a big shock to the ecosystem. Now it seem s like the react ecosystem is trying to adjust to this major change. I enjoy some of the new changes though and they've done a good job but for simpler applications the old method seems like the way to go
Curious if you tried Remix, and if so how you think it compares to Next 13. It seems like some new Next features, like nested routing and server actions, were inspired by Remix.
i've had a very weird issue with app router that forced me to go back to pages. there's loading.tsx fallback file which displays while page.tsx is being loaded and sent back to the client. i was writing client side filters which are synchronised with url query parameters so i used useRouter and .push method to change those parameters. but app's useRouter.push doesn't have {shallow: true} so every time a query parameter is changed, it requests page.tsx to load data again. and it's actually fine, no need to fetch data from client side with react-query or useSWR. but the problem is that it does not trigger loading.tsx so every time i selected new filters, the page was stuck for like 2 seconds while the new data is being rendered. i ended up rewriting that logic with pages router, react-query and getServerSide props for initial load of the content
Great video as always Josh. one thing I don't understand is. All web apps which I build have 90% api calls that have auth headers (user specific calls) in them and they are not cached by default. So does that mean I have to use the React cache function ? In docs they specifically mention that fetch data where you need it and due to deduping we should not be worried how many same calls we making. But when auth headers are present there is no deduping and have to rely on prop drilling which gets nasty. So is the React cache function the right way to do it?
When you say you can switch back to pages, are you saying that you can have a pages and app router alongside each other? Did not know this was possible!
can you make a video on astro vs qwik and show perfformance comparison and which one do you prefer, since both of them are more performant than nextjs pages and app
I have tried using the app router hosting on aws. I'm having problems accessing the cookies in the server component. Its extremely frustrating, as it works fine on vercel and my local, but not on the aws deployment. It's very weird, the site works on first load, but on subsequent refreshes I get 500s on pages where i try to access the cookies (have tested using both headers() and cookies() - same thing). The only console error is 'A client side exception occured'. I wish I could figure out another way to look into the logging. It seems like the first load is properly server rendered, but the refresh is trying to render my server component on the client, causing an error. Either way, the problem doesn't exist with getServerSideProps, so I'll be using that. I really hope AWS fixes this, I would love to delete the pages directory. It's a new project, I don't want to start using pages on the side, knowing that the app is available.
Switched to svelte lol. Trying to play with cookies in an app that can be both server side and client side rendered is a recipe for a bad time.@@zmorphy
I have also faced a problem with uploading files using the app router. I spent two days debugging, but unfortunately, I couldn't find a solution. Currently, I am using both pages and the app router to address the issue. 😒
I got into this message when try to use app dir & pages dir together. "Warning: Detected multiple renderers concurrently rendering the same context provider. This is currently unsupported." what does it really mean?
the App direcoty router is awesome with it's reserved compnent and I really like it, But one thing i have issue with it is the Page Transition when I implement the Page Transition with framer motion library it doesn't work for me mybe the machenism of page transiton in framer motion developt according to the page rounter only. I don't know
i have very big problem in the one of my project in app router and this is that i cant catch the complete URL or after hash(#) in URL *in server component* or *server side* and that why i want drop app router. as you know we can use (Param) for get just first section of dynamic URL or route and use (searchParam) for catch query parameter after that but i cant catch *hash* after dynamic router. could you plz pin my problem its very serious.
I've recently experienced issues with the App router and API routes. I can't seem to get DELETE requests working. I get TypeError: Response body object should not be disturbed or locked.
