What are my thoughts on next.js app router vs pages router
ฝัง
- เผยแพร่เมื่อ 25 ส.ค. 2024
- 📘 T3 Stack Tutorial: 1017897100294....
🤖 SaaS I'm Building: www.icongenera...
💬 Discord: / discord
🔔 Newsletter: newsletter.web...
📁 GitHub: github.com/web...
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
![[TH] VALORANT Champions Seoul - Lower Bracket Final - LEV vs TH](http://i.ytimg.com/vi/fyYkI80GG4o/mqdefault.jpg)
With the mess that RSC looks like it will be, I tried out svelte and solid over the weekend and I must say they're looking pretty good. Both solutions feel so much less convoluted and less error prone.
Having seven "page.tsx" open at the same time and trying to navigate back and forth is going to give me a brain aneurysm
@@karlnassar8646 Well, yea, except that using barrel export with a ton of index.tsx files is just a convention your company chose. Thing is, imo, that using multiple index files is at least 'an option' rather than a mandatory most of the time
@@divided_one8188 index.tsx usually used just to re-export modules and that's it
I think tRPC still should be used in App Router cause the structure that it gives you like creating public or protected procedures or validation with zod or the middleware is quite hard to implement by yourself and it gives you them with clean syntax.
Great video but honesty, once we start using it more! You will see and understand the benefits from it. Am using it for like 6 months ish?? And it’s so powerful! What I do see though is that u basically use use client in all your pages which does make it user rendered instead of server side. I also see that you have set revalidate = 0 in your main layout which is going to force your whole project to fetch on request time instead of build time or revalidate in increments! Keep up the content though, love it ❤
The multiple `page.tsx` is what will stop me using this new thing
Yup same
It's a pretty common format though, even for components themselves, /component-name/ and then index.tsx and storybook.stories.tsx for instance or e2e files
would be nice if next allowed to do home.page.tsx, about.page.tsx, blog.page.tsx etc. Any name, but ending with .page.tsx would become a page, any name ending with .layout.tsx would become a layout (while still allowing using just 'page.tsx' or 'layout.tsx' names)
@@makl-the-oracle `index.tsx` makes sense since it defines the root of a path.
This `page.tsx` and then the file exports `Page` as well is ridiculous imo. If we're going to be exporting Page, we can return the naming convention that was there but with this new pattern
Same²
regarding trpc, i remember someone mentioning from another video (can't remember which, might have been theo's) about a library called ts-rest.
I haven't tried it yet (even now), but i did check i out and at first glance it looks like it makes much more sense that trpc and might even work with the app directory for type safety.
---
btw, i'm still kinda new so i'm not sure if i'm asking the right question but,
what do you think about the tradeoffs that come with SSR by default?
If i'm understanding this correctly, the potential for reducing client-side JS is a lot but in return you have to make a lot of server-side calls.
Well, server-side calls aren't bad per se but, most hosting providers charge based on number of api calls or bandwidth (usually both).
so i imagine, in general, less JS but more api calls, so i'm not sure if this would be more or less expensive.
I think the trade off is a user actually sees something in their browser faster using client side rendering, but it takes longer to see the real data on the page because it has to make yet another api call. SSR returns a complete package do the moment the page renders, everything the user might want to view is there without needing extra api calls. So, probably SSR is faster overall?
@@WebDevCody I would say the rule of thumb should be server side render what you need for SEO or maybe even do session management server side(like shown in the latest Cody video:D) but do client side for anything else. With client side and loaders/skeletons you will get a better "perceived performance" for the user, the app will feel faster and responsive, even if the blank screen then everything rendered from the server might in reality be a bit faster to get to the final state. Why I would still go to client rendering first if there isn't a direct reason like SEO to use SSR is offsetting the "cost" of rendering from your servers to users browsers like you mentioned in your original question. Overall beyond the rules of thumb I think we should strive to understand the pros and cons of both approaches really well and the cool thing about the new paradigm is that we get to mix and match them as however we want to.
@6:20 you can now grab model params with the second param i.e. GET(req, context). const { id } = context.params - i am sure you now know that.
Haha I saw your tweet about page.tsx 😆 I agree with your points
I haven’t done a deep dive into app directory yet, but I know its caused you issues
Remember that app pages are twice as slow as regular pages in benchmarks. I'll stick to pages for that reason. I don't wanna increase my server costs just for some async components.
That's actually the biggest deal breaker.
I played a bit with app directory as well and here are some subjects that to me are a bit messy :
- I was hyped with the "loading/page/error" setup but in a real production case scenario, this is a mess. when you have multiples Api call on the same page. You wouldn't want to wait for all of them before showing the page. Since i've been using Astro, i've tried to emulate the "island architecture" and organize my code in component rather than "pages".
- When using a component lib ( Chakra for the most part) you almost have to tag everything as client, loosing the SSR capibilities of Next.
Maybe i'm using Next wrong, but i wouldn't really use this solution for heavy project. But I love to use it for POC or rather small project.
I guess it comes down to making the right decision depending on the project, you cant really have only on stack above everything else :)
Even if you have use client, I’m pretty sure next still runs through your client react component once to initialize the html. Try it out, add a console log to your use client component and you’ll see it print on the backend when you request you page.
Recently after migrating to app router i found a big draw back. Since we don't have access to the response handler we cant set dynamic response headers especially if these response headers depend on the request.
Thanks for sharing!
I prefer the app router and layouts
The layouts are better for sure
Same. However, you can incrementally adopt new features in Nextjs and get the best of both worlds
Just started learning Next with app router without never touching pages router. No problem with file namings and such, but data fetching seems to be quite a piece to learn. Coming from basic Vite/React app and separate apis, so now I’m quite confused, for what should I use the api folder 😅
If you want to build your own API routes.
@@oscarljimenez5717 yep, of course. But I actually meant, that server components won’t need, and shouldn’t use, api routes. Not to mention the new server actions… And then if I need an api route for some external app, I need to implement the same functionality both in server component and api route? 🤷♂️
So it’s basically the thing, that you can build fullstack app without having a single api route, that’s confusing me 😁
@@janikaikkonen6384 i understand your point, but they're others cases like webhooks that fetch in server components don't resolve. Also if you wanna share your data fetch to reuse them in a mobile app you could use API routes for that. About the question, you could make a function and call it in both places.
hey cody just want to tell you, you can stil search all of the files even though all of them have page.tsx, you can type command shift 5, and it will search the folder name, and the file will come.
I’m a huge fan of yours sir.❤ please reply 🙏
Can I get your number baby?
Off topic, but what's your vscode icon pack?
what the theme?
@@jasondhakhwa1179 🤷♂️😭
He just hearted the comment and didn’t reply
Anyone noticed the hot reloading in next 13 is a mess and way too slow?
I’ve noticed the app router doesn’t even refresh at times 😂
Yes. It's really slow in dev env. But the same project in Pages router is working or reloading fine.
Personally i loved the page.tsx name, made me see that this is the main file route for whatever folder, but yeah everyone can have different opinions, its dope how we have the option between pages and app router though.
What are your thoughts on UI component libraries with server components? I've heard most don't work because of client state that's usually backed into many of the components.
I been realize that workig with pages directory is much easier for me. That's why now i learn nuxtjs 😀
where we need to use window variable but the page is strictly in SSR. how can we handle this?
if you need window, you need to access it in a useEffect. You can't access browser related variables inside the SSR logic
your theme looks cool theme name?
My hold off for the app directory is that I’d like to have an electron app but nextron does not support nextJS 13 yet.
Have you tried Tauri? It supports Next frontend with a Rust desktop layer
@@danielcruz9583 I’ve heard of tauri but didn’t even consider using it. I’m still using the t3 stack, not sure how well it integrates with that.
it takes a while to learn, but i'm all for it!
Hey , please im having issues with docker seeing the way i import components in next with @/ till i use relative paths it works. Do you have a solution for this ? Thanks ! 🙏🏾
What is the current tech stack u would recommend right now? like including your choice of framework, UI library, database, middleware, state manager etc..
T3 stack, any type of sql database (Postgres or mysql), I mix and match ui related components (but I like flowbite, headlessui, roll my own), react form hooks, state manager maybe jotai
Do you think we still need state managers? In my mind state managers are a way to keep FE in sync with BE but with the full stack/tRPC approach, I didn't feel that need yet.
@@elfelipe1996it’s all circumstantial, if you need to share state between components, bring in a light weight state management library, if you need to cache server data as you navigate tabs on a page, bring in tanstack query
I struggle a bit with server components and i18n, maybe I switch back to pages until all the libs catch up.
Can you make a vid on your thoughts about mongodb vs supabase?
What’s the extension that shows the colored bar for the opening and closing tags?
Indent rainbow
From where do you clone these projects? Or are they always project that you creat from scratch?
depends on the project, usually I just run npm create next-app
I have difficulty learning use-client. How does it work if I use "use-client" then initially it is rendered as SSR then after its been rendered will it turn into client or what ?
You are right. For client components ("use client'") for the initial run the server will render the output and then send BOTH the html output and the javascript code (streaming) to the client. The browser will first show the already generated html output but then immediately it will get the javascript client code and run it making the on page elements interactive (hydration).
I suggest you to look at Remix framework 👍
What is vscode theme name?
Why don't you just change the page.tsx file name inside all of your folders? I think that's the point of this new approach to the folder structure
Yeah, I'm watching from a distance but I'll wait until the ecosystem has matured before jumping in too hard.
Honestly this new version of Next feels like a hacked version of Angular
So they're just two ways of doing the same thing, with slight differences between them
still waiting for some more vue content.....
Lol yeah idk at this point. I’ll probably just stick with react
Don’t use app route😂
I am using app route and keep founding error. There are many conflicts with ui/js libraries and SSR. Eg. Chakra ui Color mode, dompurify, etc.
I don't like the nextjs's built in api. It is simple and that's also what it is made for - for simple cases. But if you have a huge projekt it won't scale architecture-wise.
It scales fine if you deploy next to anything that uses serverlesss behind the scenes
The name convention is a bit weird indeed but really when you will realistically have 5 open pages at the same time. Usually when you develop you focus on a page at a time plus the related components of that page with a loading and error tsx. So I don’t see that as a huge problem.
Ranting at its very best.
You're not a fan because you're not working on a single page at a time. Why do you ever need to open more than 2 pages??
Documentation till now is absolutely trash, imo, sadly
It’s even worst now that there are two router approaches. They need 2 completely separate documentation’s imo
Just let us use "my-custom-name-ignored-by-next-js.page.tsx" naming inside app directory