Next.js App Router REVIEW (Six Months In Prod)

yeah hi everyone webtony Dev Tano here internet's laziest typescript Dev let's talk all about the new next.js app router if you're somehow not familiar next.js overhauled their entire routing system to be the first heavy user of server components the result is a whole new framework honestly it still supports everything next used to and you can still use the old page directory but the new experience is very different very jarring very exciting and very polarizing wanted to take the time to do a proper review now that I've been using it for over six months in production I'm going to break this review down into three parts The Good the Bad and the Ugly so make sure you stick to the end if you want to hear all about the worst and scariest warts what's so good about app router that I've bet multiple projects on it over the last half a year well more than anything it's the productivity my team and I feel like we are shipping so much faster and honestly it's because we are in just under two weeks we were able to build all of upload things dashboard and and back end using the new patterns it was surprisingly quick to work with I had another project where I would keep track of my twitch markers that took me weeks to build and was impossible to maintain that we rewrote in approauter in literally two days it is incredibly easy to work with these new patterns and man it simplifies the architecture of what we're building in almost all cases while also having better performance so let's break these parts down the productivity win comes from two core pieces the simplification of getting data to components as well as the composability of those components once they are created previously we had to use a not great pattern get server-side props which on a page level would fetch all of the data that page might need and then pass it down through props maybe you would add your own context layer on top but it was really a crap shoot you never knew if you were getting the data you needed in your components unless you actually fetched it in the components which defeated the whole model unless the components were able to fetch that data on the server and just send the right content down to the client that's what the new model enables and man it's so much easier to work with if we have a component that's the user drop down that component can fetch its own data and we can mount it anywhere in the app and even if you mount it in multiple places or have it under a waterfall it's not too big a deal because if it's using fetch to get the data it will cache it on a per request level or optionally on a global of all two so that you can have your content faster and have a great experience developing it no more context just to dedupe requests you can just fetch all over your app and not worry about it as much as long as you're doing it on server stay tuned to the end if you want to hear the problems of doing this on client anyways when it comes to composability you're already familiar with how mounting react components and breaking them out and reusing them works but with server components it changes a little obviously when you map things on server it still does what you expect when you mount a client component in the server component it still does what you expect one of the unintuitive and really powerful pieces is that you can mount server components as children of client components so you can have a child component that wraps your whole app like a theme provider for example and then everything underneath that is still a server component it won't have access to the context this is not running on the client where that context is defined but you are able to take server components and mount them as children inside of client components client component can't import a server component but it can receive one as a prop and you can do a lot of powerful stuff with that generally my experience is that there's more things to use but they're much shallower where with hooks we had these simple New Primitives that we could build complex things on top of and some of them like use a fact we would dive deep down when fighting with a new model is that the solutions are much simpler you have the basic cash wrapper you have a single weight you have suspense and it kind of does what you expect it to now it feels like these pieces are both easier to use and harder to hurt yourself with and really importantly when you do screw up it fails immediately I feel like it was so easy to make a mistake and use effect that was impossible to catch until it was way too late and with the new model we've had almost nothing like that and we have way less use effects too the way I've been explaining this is that there's a wider surface of things now but they're much shallower there isn't as much depth to fall down when you're trying out the new parts and it might seem like there's a lot more going on and on the surface level there is but as you use it you realize these pieces are almost beautifully simple there was a lot of parts of next that I think needed to be removed specifically underscore document underscore app get server side props yeah get initial props wasn't great either there was a lot of cruft that made it hard to compose your next applications if you had a route with a side nav and then you had sub routes with different components on the inside encoding that was miserable and with the new model it's simple some of the biggest fan of file based routing we'll get to that in a bit but if you're gonna do it this gets pretty close to doing it right and it's been a much better experience overall and man I will take a root level layout over underscore document at any day of the week this is this is a great win one more piece that I really love is how much better loading and streaming is in the new model put it simply you can have a component that fetches data and if it turns out takes a while to fetch that data you just wrap it in a suspense and give it a loading State Now by default there are no loading States everything is just fetched but if you do have some components that are slower you can wrap those components into suspense it's allowed us to make great experiences for our users and within the same web request you make to get the core page data the rest of the HTML Finds Its way over to I really don't want to make this all about performance even though the performance is much better but I I want to emphasize how much better things are now that use client and use server are standard you have to choose which content actually makes it as JavaScript to the user by default they just get HTML one silly example of something that would have sucked before was having a bunch of inlined svgs we wanted to have different backgrounds for all of the cards in upload things so when you have different apps they all look fancy but we didn't want to load every single SVG for every single user in that JavaScript blob so we chose to do instead is put that part in a server component and now you don't have to load all of that data it just renders the markup for the right svgs for the cards in your dashboard and sends that down instead it's not included in the JavaScript bundle at all and those types of wins are just built in you don't have to think about it as much we're not worrying about bundle size at all anymore I do want to talk about use client though because I guess this is the start of the bad I don't like the term use client very much I think it's a bit misleading because a used client component also runs on the server it only runs once but it does actually render on the server I think it makes it a little harder for developers to understand what truly is client versus server and also those words don't mean what they used to anymore and yeah that's the part that's sketchiest to me is client components running on server makes it less intuitive what and where they're actually doing their thing I think use interactive would have been a better name simply because the components are interactive the reason you mark a component use client is because it has some type of interaction or need for the JavaScript in that file to make it to the client you can have interactions that don't use JavaScript through server actions and forms but the component itself in the interactivity in JavaScript is the thing that use client entails and specifies I think use interactive would have made it a little bit clearer what the split was the naming isn't the only complaint I have in the bad though I think there's a lot of weirdness that we're still working around obviously nothing is foot guny's use effect but there are some footguns in use particularly if you use it on the client side in an async component you're in for a rough time I don't know why this isn't just like a warning that lights up really loud when you're mounting an async thing on client it should just complain at you when you do it it's not intended and while it's supported in react it's sketchy to say the least so I hope they get that addressed soon generally asyncline components are a bit weird I would stay away for now there's also a new hook use transition and I'm starting to wrap my head around it after using it a bunch but it's weird I'm still figuring out how to even describe it much less make educational content on it so uh keep an eye out for that it is an important thing for us to understand and it makes the navigation experiences in an app router project much easier but that's all on the react side I do want to focus on app router itself and while you do use use transition to do navigations in app router it's a react thing so let's stick to app writer I think compatibility is worth bringing up it's not that app router isn't compatible with the old way of doing things it's that server components as a model break a lot of the pieces that we used in react before like react query is a weird fit in this new architecture how do you fetch data on server and pass that to a hook on client and keep the context in sync and yeah there's weirdness there that we need to figure out it's gonna be a bit before we do but I do trust the community to get this all not just sorted but working as a really good experience as time goes on so definitely keep an eye out for all of the developers and Library maintainers working hard to make things better but right now server components by default don't integrate great I do want to emphasize if you keep things in client component land it's going to be fine and if you just use app router as a better router for managing which components render where and react just making everything a client component with use client is basically what you're doing before page router it's worth looking into that if you have things that are incompatible with server components there's still a lot of benefit to be had with app router tangents a little bit to talk about file based routing because uh still not my favorite thing having a bunch of files named page.tsx sucks having to scroll to the right place in the directory I still have no idea where I should put my components where I shouldn't put my components what goes where all these weird syntaxes with underscores parentheses brackets and random magic names like metadata.tsx page.tsx layout.tsx it's not great I really like how svelt handled this with the syntax that specifies with the plus that this is a thing that's part of the router and everything else isn't and also moves them all at the top of the directory file based writing still isn't my thing this is one of the best implementations I've ever seen of it but it's still hard for me to recommend what I can recommend is subscribing to the channel seriously less than half of y'all are subscribed and you're this far into a review about app router this is like the perfect Channel just hit the button back to the review one piece I don't see enough people talking about that uh really frustrates me okay we talk about this a lot here but not in the context of that router we need to talk about cold starts a bit I'm putting this in bad I'm not ugly because I know it's being worked on and it's not necessarily unique to app router but man if you have streaming and it lets the next piece of content after that first one come in faster but that first piece still takes three seconds it doesn't matter if you reduce the next paint from 3.4 seconds to 3.2 seconds because the first thing still took three seconds cold starts suck user experience wise and this is a big part of why I didn't like get server side props in the first place by default get server side props blocks the first byte on the first response from your server if you're hosting your next instance on a traditional server like on ec2 or just running a Docker image yourself you won't feel this difference when you're running it in a Lambda and hits a cold start and it takes half a second to three seconds even to spin up and start sending a response it doesn't matter how quickly the second and third parts of that response come in because the whole request is blocked for three seconds this sucks and as great as the new model is it is encouraging us to use the server as the first byte in our react apps way more but if the first byte can take up to three seconds it's a bad experience at this time there's no way to Cache the first response and Stream in additional data so you can't have a static shell and then wait for the cold start on the Lambda to hit so what I've opted to do is just run everything on edge and the result is incredible performance we don't necessarily run at the edge we use the regional Edge functions on versel please don't come at me with the names but the result is incredible performance like just using the upload thing website everything is so Snappy but there are things I need to complain a lot more about which is why we have the ugly section so what's the biggest problem with app router stop if you've heard this one developer performance the greatest the productivity wins are for devs the speed of the server in Dev mode is a little bit rough okay it's a lot rough I'm on a maxed out M2 Pro that I use because I do a lot of video editing but if you're on anything less powerful especially like an Intel machine or God forbid on Windows the performance is unusable you make one change in hailwind and it takes five to ten seconds to see a response there's a couple things that help and the next team is working on documenting them and I know they're taking the performance issues here seriously seems like a lot of the bet is on turbo pack though and I'm not super helpful I mean obviously fingers crossed if they succeed with turbo pack that's going to be a groundbreaking change that will push all of web deaf forward but if they don't we've been putting a lot of uh a lot of weight on a horse that might not get us to the finish that would be unfortunate we really need to see better Dev mode performance as soon as possible because we shouldn't have to gatekeep a good developer experience to high-end like apple silicon Max I do expect this to be fixed I know they're pushing it really hard but at this point in time the developer server performance it's not great I've also had a lot of issues with The Branding not in the way that they've discussed things publicly more the the lack of clarity around boundaries I guess it's the best I can put it when next 13 dropped they announced app router but they didn't really have a name for it yet they just called it the new app directory and with that people started associating next 13 with app router and assumed that to upgrade next versions they had to use this new pattern to this day we get questions when will create T3 app support next 13. support next 13 day one and it will support app router very soon but those are different things on top of that server components are very different on top of that server actions are different within the server components model in react and we have all of these different things going on and all of them are pushing us to this new era of web dev and it's really exciting I feel like what we're going towards is a react 2.0 in a way a new vision for how web dev can work using react at its core but all of these parts are different and many of them didn't have names until it was too late now people are mixing up server components server actions app router next 13 and turbo packets thrown into it's not the easiest thing to communicate and I understand the struggle that they've had because I've had to do it too it's not easy but man it would have been nice to have a clearer brand for each piece and more focus on how these come together and a name for all of that this has also resulted in a lot of drama where people see app router as stable even though it's depending on something like a canary react version because it's using some server action stuff as well as some server component stuff and even if the server component stuff is stable because they're using a canary version people are now scared of using App router and that's because they don't see the relationship between these parts and I get it I understand it's hard to communicate these things I know you probably expected more in the ugly but honestly app router has been a great experience for me and I went in very skeptical I was not an early server component fan I was excited when I saw the switch to async but I really didn't think it was going to click as much for me and I really did not like the file based routing changes that were happening so I don't like file basement man I'm so impressed with what they've done here I cannot recommend app router highly enough if your computer can handle the dev performance use it now and if you can't use it in a couple weeks when it will be better supported this is the first step into the future of web dev and I feel very lucky that I got to be part of it you want to hear a bit about the drama going on with server components I'll pin a video here all about that thank you as always peace notes

Channel: Theo - t3․gg

Views: 57,589

Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg

Id: zsa9Ey9INEg

Length: 16min 9sec (969 seconds)

Published: Wed Jun 28 2023