What are my thoughts on next.js app router vs pages router

okay so this will be a really quick talking video I just want to talk about the app router I have been playing around with the app router on a side project that uses Super Bass and I want to kind of give my initial thoughts on the app router now that it's like unstable because I have some opinions on it um for the most part prior to the app router we had the pages router right and all of my other projects were built using the pages router like for example if I were to load up my icon generator this is using the T3 sack with Prisma and we have the Pages directory right so if we go here we have pages okay so I'm going to talk about the name conventions of these files first of all okay I personally liked how the the pages router named the files if you go over to the app router approach now let's look at all these different files and we have page.tsx page TSX page TSX htsx page TX TSX I've been kind of complaining on Twitter about this um but when you have like a couple of these Pages opened up and we'll just go ahead and open up some other stuff too oh wait here's another page.tsx okay so when you have a lot of these open up it's kind of a little bit harder to figure out what page you're trying to find when every single thing in your top tab says page.tsx I know you have like the directory here where it says forgot password but in terms of like the approach with the pages router it's much easier just to read Community or feedback I can just read that I know it's it's there a lot of people say well you should just use command P fuzzy searching and now you don't have to worry about it right even that it's easier on the pages router so if I were to type in like privacy policy first result comes up so for the app directory when you you can't just type in page because now you have like 100 of them right so you kind of have to do extra steps for example if I want to open up the update password I say update and then I say page okay and now I have access to that page and then typically in the drop down you just have like a bunch of pages okay if this is a small complaint I mean you can get used to it but overall it's kind of annoying personally I think the file based routing does have limitations and I think a lot of other Frameworks I think even svelt or solidstart might do the same approach where like you have the same named file so I'm not a fan but other than that I kind of like the approach that every page is server side rendered by default if you were to compare the app directory's server-side render by default against the the way that was done with the Pages directory so for the Pages directory every page is kind of flying Side by default unless you export a git server-side props and then it changes it into a server-side rendered function now depending on your thoughts and you should be doing client-side rendering or if you should be doing like server-side rendering server-side rendering does have a lot of benefits for example when I needed to basically set some metadata headers on my endpoints one thing I needed to do like if you ever need to like dynamically change these let's just go to the icons page which I have here all of these metadata tags are Dynamic right they changed based on the ID of the string here so because of that I do need to export a git server-side props and basically take that image ID and pass it in I will say there's a bunch of boilerplate for doing this like I will say that the app router is actually a lot nicer because I can just do async functions directly in my pages so for example if I were to go to let's just go to my layout here notice that this is just a server-side rendered page this is the layout basically and I can just do a weight directly in here I don't have to have some external git server-side props I like this a lot better I think it makes the code easier to write you don't have to jump back and forth between functions you have to worry about passing props from one function so that you can insert them as properties inside your page definitely a win here I do like this approach and overall I mean the server-side rendering you end up finding small things that just make more sense with the server-side rendering for example in this application I have a nav bar and if you don't do server-side rendering for this user session and pass it to the nav bar basically what happens is your page loads and then you'll see a flicker on the top right where it'll say sign in and then that'll kind of go away and you'll see a picture of your icon if you do server side rendering for your nav bars and things depend on session or like your username or something by default you won't have this flicker right because the users defined the nav bar gets rendered on the the back end for its initial run and that data is going to be populated correctly based on conditionals right so the user will be passed in on the server side rendered rendering process and that'll show a drop down by default you won't have that weird flicker I do like that a lot so I do think server-side rendering does have a lot of benefits and of course there's like search engine optimization that we haven't even talked about um I will say that the the way that you do apis for the app directory is a little bit different I'm not sure if I'm a fan of it yet so before I used to have like request in response as like parameters here let's see if I can just find one real quick so for example like here's the endpoint that has request in response this is kind of familiar with Express and how a lot of other node Frameworks do it but it was kind of hacking ugly the fact that we had to do like if Rec method is equal to post here and then you know check if it was a git or a patch or put not a fan of that so I think again the app directory it's a big win for just exporting the function here without having to like bring in a third party library to do that switch statement for you or doing the switch statement for yourself that's a big win in my opinion so some things I don't like about the the route handlers for the app directory is like the request used to have some really useful methods on it like this would be like rec.params or rec.query and then you'd already have access to the query string parameters now you have to basically take the URL pass it to like a URL here and do a bunch of extra boilerplate just to get the search parameters I understand that they're trying to be like more in line with the conventions for the front end I think these data structures are actually things that are found in the browser so it's like kind of consistent which is good I mean that's a good argument to have your backing in your front and be consistent you're using the same type of data structures but I do miss the the ease of just like doing request dot query and then you have access to those you know query strings out of the box um and then also returning from an API a little bit different instead of saying response dot Json you actually have to create like a response object and then like Place Json on it and set headers on it and then that's what you return from the object that's not too bad I don't have an issue with that um I'm trying to figure out what else could we potentially talk about I haven't even dived into like layouts and stuff or like these these head files I'm not sure how I feel about splitting up all these things in the separate files I mean like technically we could have just kept them all in the same file and just like exported functions um now a lot of people ask me like most of the content I've done has been trpc and like the T3 stack stuff and they're kind of curious like is is trpc still necessary like is this a better approach I don't think I'm going to like the only reason I'm doing the the app router right now is because a the E3 stack set up I don't think they've actually gotten trbc fully working with the app directory maybe they have I haven't checked in a while but the main reason um I'm kind of still waiting on using the app directory is because the server actions are still Alpha I'm kind of slow at adopting new things especially if they have the label Alpha on them because I I just don't want to waste time going back and refactoring code um because like their signatures change or the function definitions change I'd rather just use something stable so I don't have to like go back later and maybe change it so as far as like can you still use a T3 stack and trpc with the Pages directory I'll say absolutely I think this is still a good solution um I will say that now navigating the next JS documentation documentation is kind of hard because when you start searching for answers you'll start reading the docs and then you'll realize oh I'm actually on the pages docs I'm not on the app router docs and like that is screwed me over a couple times where like I'm reading blog posts I'm reading docs and it's like oh well this is showing me the new approach or oh this is showing me the old approach which is kind of painful but that's kind of just you know the way it works when new paradigms come out for Frameworks and libraries overall I do plan to switch over to the app directory so right now you're looking at my icon generator code I'm not gonna intentionally go and change this all to be the app router I think keeping it as pages is fine until the next team comes out and says that we're going to deprecate pages I have no uh real reason or argument to like refactor an existing code base to use the app router but if you're starting a new project brand new project I think using the app writer would be nice but again like I really like the autocomplete that trpc gives you the built-in Zod validation that trpc gives you and I don't know if there's a very easy way to hook that in to the app directory approach leave a comment if I'm wrong like feel free to correct me but I will say whenever the server actions get out of Alpha and they're stable I will probably switch over to using the app directory because I think that would be the point where trpc is basically obsolete because you can basically invoke methods directly from your front and code get that type safety out of the box and I do believe um Theo has like a library that hooks in the Zod with your server actions that makes like validation super easy as well Josh tried coding as another YouTuber I think he just made a video of how he's like not using trpc using server actions again I'm just more hesitant of adopting anything that says Alpha so I'm going to hold off but overall I do like the app directory I think it's other than like my small little complaints about like how the page is named everywhere the same it's kind of annoying um overall I think it is an improvement and I think it does give a lot more flexibility if you buy into like every route is basically server rendered by default because as I build larger applications I realize that like I really need those extra features that server-side rendering gives me um and client-side rendering has a lot of like more pain for the users of like you know the flashing like I talked about anyway I think I'm kind of just rambling at this point I'm sure there's stuff that I didn't even mention about the app directory versus Pages directory I didn't really prepare that well for this talk like I always never prepare for any of my talks but if you guys have any um suggestions or comments on do you like the app directory or do you still like the Pages directory leave a comment below maybe we can kind of discuss about it other than that uh yeah if you want to join my Discord the link to my Discord is in the description below where you can kind of hang out with some other developers and ask questions and like always be sure to like comment subscribe press the Bell icon have a good day and happy coding

Channel: Web Dev Cody

Views: 21,173

Keywords: web development, programming, coding, code, learn to code, tutorial, software engineering

Id: MuTsNooES1g

Length: 11min 4sec (664 seconds)

Published: Sun Jun 04 2023