Next.js 15 Is Here (Vercel Ship Breakdown)

for sell ship just happened from next 15 to firewalls to AI to GMA wearing a white shirt finally to shouting out Dax of all things and you all out there with no users yet this is a very interesting event not too much massive news but enough small things I think it's important to go through that here I am on my day off filming a quick video so I can go over this with you guys before I go any further though I want to be very very clear this video is not sponsored I'm not being paid to make this I work with forell and other content pretty regularly but this is my genuine thought and beliefs about what happened here no money has been exchanged theyve not seen this video ahead of time they have no opportunity to approve or change anything I've said here this is just how I feel about this release with all that said let's dive in before we get to the juicy neck stuff which is let's be real the reason you should be here let's go over the quick two additional announcements first first is the forell firewall this is I'll be frank a little overdue most of the web just relies on cloud flare as their way of dealing with random dos style traffic and that's fine Cloud flare is totally fine for that but put Cloud flare as your CDN in front of something like vercell has historically caused all sorts of weird caching issues that aren't Pleasant to solve and vercel should be the ones doing this nice to see that vercel is actually taking this problem seriously and giving us the ability to quickly set up rules to keep people from destroying your websites and making your bills go massive nice to have this finally in haven't tried it yet but it looks really good check out the blog post if you're curious the other fun thing they rethought feature Flags they actually shouted out Jane Wong when they brought this up which I thought was really cool because if you're familiar with Jane she loves leaking features and products by going through their feature flags and finding things that probably shouldn't have been there so I worked at twitch I was always curious how they did feature Flags turns out once you don't work at twitch and you look at it it's actually kind of hilarious okay I knew this when I was there but seeing it outside is even funnier you load any page you see this huge settings thing load I just threw this in vs code so we take a better look at it there's a key in this called experiments experiments is every single feature flag on Twitch you'd think that these uyu IDs would off you skate it pretty well but they also put the name of it these are the names that they use internally for all of these things so if you want to see any of these features like chat pause on Hover by default 100% of people are in the control group 0% are in the treatment group if you just manually swap these values around suddenly you're going to see this feature all of the features twitch is working on that are already shipped are probably in this file somewhere which is kind of hilarious because that's how almost every website that does feature Flags Works they're super insecure and hackers like Jane can go into these files go into these mobile apps and just flip these values around and now they can see everything you're working on which kind of sucks this is why versell is building feature Flags more deeply into versell because that should be happening on the server not on the client as soon as you let the client do all of the feature flag work you have now allowed the client to see every single feature that might exist in your app if the server is not the thing generating the UI then the issue you're running into now is that every possible State the UI can be in has to be encoded in the binary the user has be it a mobile app or website Co didn't think this problem seriously haven't really used this too much I know my CTO has he says it's really good so far excited to see them taking this stuff more seriously enough about versel though what we're here for is nextjs 15 to be clear it's an RC but to be clearer it's not an RC because it's not ready to ship it's an RC because they're blocked on something they're blocked on react 19 it's still an RC because they're waiting for react 19 to be the official release and not also an RC the moment react 19 ships I am positive next 15 will be the official release within a few hours if not minutes so let's take a look at the actual things that here cuz there's a lot of fun stuff obviously if you want to play with us today you can just npm install next RC you can also use the new create next app RC to get all the fun new things they change and create next app still not as good as create T3 app by the way but good to look at regardless so react 19 the next CH app router is built on the react Canary channels for Frameworks you might not know that you might think oh but I put react 18 or 17 in my package Json fun thing about next is that at this point in time app router ignores what you put here and just loads what ever version of react it actually needs with 19 shipping this will finally be over and you can just have the right react version in your package Jon and no more weird side loading different versions to get things actually working very exciting to have this change finally next a5's RC now supports the react 19 RC which includes new features for both client and servers like actions awesome cool you've already learned a bch about react 19 by now hopefully if not you should check out my other videos all about it one of the cool things in react 19 is the compiler technically you can make it work in 18 but it's not recommended you really should be using 19 if if you can not doing the weird polyfills for the additional things that the memoization needs and now it just works I was skeptical of this because I had a hell of a time trying to set up react compiler on our upload thing code base before they added this feature but then when I updated to the most recent RC of next I literally just changed two things in our config and it was good to go no code changes just config changes and it worked and was faster I haven't done benchmarks yet I haven't had time to sit down and really analyze things but this looks really promising and I am so hyped that we can just adopt the react compiler by installing it and then adding the experimental flag for it make sure you also install the eslint rules though because the es lint rules will make it much easier to follow the rules of react so that you actually have code that can be optimized you also can opt Into The annotation mode where you can tell react on a given component do optimize this don't optimize that using the Ed memo directive still don't love having directives for all these things but at least we have an option now speaking of things that weren't great but are finally in a usable State hydration errors we finally have actual errors what hydration failures occur they start working this at 14.1 but it still wasn't great now we have actual useful errors here previously you'd see the specific elements that were different but now you'll see an actual diff P class name was paragraph on the client but server text was the content on the server having actual diffs for what the client and server disagreed with is going to make life much easier when you're debugging complex hydration errors I find most of mine are simply some weird stuff with date but it's cool that at least in this case we'll get a real error finally also they even call it in the notes here that date. now or type of window like these are the things things that cause it the most and that's absolutely been the case from what I've seen speaking of things that are confusing and hard to debug cashing has been overhauled not quite how I would like but in a way that is very very much better and at the absolute least is listening to what the community wants because they killed all the weird cashing by default stuff that everybody was so upset about fetch is no longer cashed pages are no longer cashed by default everything makes a lot more sense here my Hut take is that the missing piece for caching was never the behaviors it was almost always the developer tools because we don't know what is isn't being cached it's just very hard to get that information when you're working on something in next or any other tool that does a lot of heavy caching stuff on the nextjs side if we just had good tools for analyzing this like you know we have in the browser for browser tools and we could just do something similar on the server to actually see what was happening I don't think the cash itself would have been as big of a deal but the lack of that has made it very painful and as such the default behaviors have to be very obvious like stupidly so sadly some of those behaviors were unobvious in even stupider ways like get route handlers being cashed by default I still don't get this one I still think this was insane if you have a route. TS file in nextjs at least the old version I'll be clear export function get I return new response here let's say this is like a date time instead so I'll do like new date. to local string perfect so I have this end point and when you get from it we return new date2 local string up until this release this would have generated by default a static Json file that would have been what gets served whenever you call this endpoint are you kidding this date would have been set during build and then never changed again that's a terrible Behavior if you're exposing a get you want it to be dynamic almost always if you want it to be static you can make it static in a billion other ways just made no sense nice that they're finally fixing that one I still have hot takes about the fetch stuff you check out my video about that if you're curious overall nice that these things are getting way easier for us to understand how the next patterns and caching works but this is less a massive update to caching Improvement in how we can adopt these tools and the DX around it more a walk back of the things that were way too aggressive that weren't communicated or understood well enough to be sane defaults this is still just one step in the long process of figuring out caching over time I've heard that they're working on more things I have not seen them I don't know if they exist yet I actually have quite a few reasons to believe they don't but cashing is still a very very early story and that's why unstable cash is still called unstable cash the other a ways to go oh actually they say here we're continuing to improve cashing in nextjs in the coming months and we will share more details in the next js15 general availability announcement cool so keep an eye out for that because they might actually fix cashing yeah as we said fetch is no longer cash by default finally no more of these cash like overrides they're just done oh apparently this is the web fetch API cash option so this already exists in web fetch nice that's cool so it still has the caching thing but it's opt in and web standard Now isn't that nice you still opt into cashing fetch request by doing any of the following setting the cash option to force cash in single fetch setting the dynamic route config option to force static for a single route or setting the fetch cash route config option to default cach to override all fetch requests in a layout or page to use the force cach unless they explicitly specify their own cash option nice you have to be explicit about cashing now probably always would have been the case the get thing I already said silly they didn't do that before but also client router Cache no longer caches Pages components by default the amount of random things I ran into with this one is insane this is like if you were using the new next stuff and you went to a page and then you went back expecting it to be different and it wasn't even though you forced a new navigation that's cuz it was cashing the page component when it probably shouldn't have been and this Behavior was not communicated at all this one sucked so having the default stale time now be zero for Pages means that navigations will always get you the latest information as they probably should navigating these apps is going to be fast anyways this is fine the thing that will be cashed by default though is the loading file so remain cashed for 5 minutes or until the value of the stale times. static configuration is hit I'll make sense to me backwards and forwards navigation will still restore from the cache but if you click to go to a page you were on before again like you never forward to a page again then it will be cash busted as it always should have been very nice here's one that's important to me I have been a partial pre-rendering Fanboy since before it was even a thought because I was pitching partial pre-rendering to versel to Dan abramov to basically anybody who would listen to me since I discovered the pain that was serving your first bite from a Lambda the harsh reality is that if you're waiting for a node.js instance to spin up before you can send any data to your user that experience sucks being blocked on a page that is a blank white page for sometimes 300 100 milliseconds to up to a second is insane and while yes once you're navigating and you're waiting for new data to come in or you're sending a post or something like that a 300 millisecond penalty is not a big deal navigating with that penalty sucks it genuinely does and the goal of partial pre-rendering is to make it so things that can be fast will be fast because they'll just be cashed and if I can cash a static page or a static shell of my page so that you get it immediately and the rest comes in later cool sadly adopting partial pre-rendering was a bit of a because there were so many pieces that might just break or be set up correctly even when they announced it it was still not working they had it working on forell in for but they didn't have it working in next yet which is a funny Quirk but now it works obiously to sh on any of my major projects because we're still on edge on upload thing that's a long story I could do a huge video about but one of the big things that is going to make this easier to adopt has just been shipped you can now adopt partial pre-rendering incrementally so previously when you opted into PPR every route would try and generate a static shell of some for a lot of routes can't generate static shells or have a lot of reasons why they probably shouldn't like authenticated or behind a wall of some form but now with incremental I can adopt on specific routes this caching behavior and this generation Behavior so for like my homepage my terms of service my blog all those things within upload thing can be cached on a CDN even though everything else gets streamed in and on every other page it's fully Dynamic this is awesome this is how it always should have worked I'm genuinely really hyped about this I know that longterm their goal is to let you just turn it on for every route and they'll figure it out but they're still figuring out how to do that so we got a little bit before we get there one more very exciting thing I did a video that touched on part of this before which was wait on tell on versel you're not familiar with these behaviors when you use a traditional serous environment like Lambda and you send a response as soon as that Lambda sent a response the instance dies so if you want to do some things after you respond like send some logs to post hog or send some data to Sentry or keep track of some analytic stuff all those types of things that you want to do after the request is completed would die before they could be done because the server dies when the lamb is done responding which is not a great Behavior you can kind of work around this with streaming but it's not trivial wait until was an awesome addition because it lets you say hey don't kill this until this other work is done what if you don't want to start that work until after the response because it takes some CPU it takes some Cycles it takes some time you want to get the response as fast as possible you want to cue this work up for as soon as that work is done that's what next after is for and it's very exciting I kept an eye on the pr for this one for a while unstable after it's one of Lu's first big contributions she she might have contributed more she's a wizard she's one of like the earliest people like Allin on uh server components in nextjs so her working at for sell and contributing to these things is awesome huge shout out to Janka very excited to see what she contributes going be more stuff like this I'm going to be very hyped with her contributions because now you can just call after unstable after is after because again it's very early so they're still calling it unstable after but now if I want to do some logging after we send a response I can just call this in a component it's fine I can just log this whenever I feel like and now I know that it will eventually make it to my server or run at some point and it won't block my user from getting a response as fast as possible for things like analytics this is a GameChanger I am so excited to be able to just drop analytics anywhere in my app that I feel like and not have to worry about blocking the entire service in the actual request that the user is trying to get a response for that's awesome I'm surprised that this hasn't existed before but I'm hyped it does now speaking of things I'm surprised didn't happen before create next app has finally been overhauled and looks a hell of a lot less bad I create a lot of create next apps so I spend a lot of time in this template I'll show you the current one so you can see the difference here so in the current create next app like this looks nice and pretty but the blue gradient a bit much the different types of text everywhere is also a little much giant layout and then the code for it is also a bit much like I love Tailwind but this is a ton of text to have inside of a getting started template it's just so much and I delete it every time just a little Annoying with the new template things are significantly better if I just run this as create next app at RC uh RC next 15 one more fun new thing here we'll get to this in a little bit so you can now turn on turbo pack for Dev as part of the setup process cool and now we have a much nicer much more minimal simple looking page they got rid of the big built by versell thing just nice simple clean we look at the code also quite a bit cleaner I know it's a small thing but just having a giant pile of text as the starting point was never fun and it's way fewer lines okay it's not as many fewer lines as I expected but it is quite a bit more minimal this is the original it's a giant pile of 115 lines of huge chunks of Tailwind there's nothing this chaotic in the new template still a little bit heavy for a template but really not too bad all things considered it's kind of just this one like div for the versell SVG with their fancy like round button otherwise nice change overdue cool to see a template that doesn't make me cringe every time I have to run it I did talk about one little thing in there though which is Turbo and I think we should talk about that turbo bit because previously you'd enable turbo manually by going into your scripts in your package Json and adding the dash dash turbo there was no vious way for anyone to just go add this like if you read the docs cool you know how to do this you can go do it nice but for the average next Dev was not clear what turbo even was much l how you could adopt it and if you're building with next app router and you can possibly be using turbo pack you probably should because it makes the dev experience significantly less painful turbo pack is the path that they've been building on to for a while now for how app router was intended to be built with and while it took significantly longer than they expected getting a lot closer I will say the roll of Turbo has been a little bit funny for me because we had the announcement that we had a ton of work being done then we had the alpha that was opt in through this and now the next release is that they'll prompt you and ask if you're ready to use it so we're still probably pretty far from this being the default and much further from it being ready for production there's a website are we turbo yet that they made and while finally all of the dev tests are passing for Turbo so as far as they know turbo should work great for almost all if not all developer use cases as an in Dev mode when you're not building the production bundles but if you switch this over to the production tests they still got a bit of a ways to go 82.6% of the next build tests are currently passing and as you know when you're trying to close things out like this the last 10% is where it gets really painful so I wouldn't count on turbo for production builds anytime soon I would probably expect turbo pack to be the default by next1 16 but the fact that the progress report here is they now ask you and create next app that's kind of funny hopefully we'll see this rust ReRe go well someday but as per usual I think writing things in Rust is more a hopeful act than it is a productive one and we're still a far ways away from having turbo pack be the Blessed path to replace webpack hopefully I'll be wrong about this and we'll just suddenly have a better web pack written in Rust but uh it's taking a while and my faith in this project has slowly dwindled it's nice when it works but we're still so far from it working for everybody that I'm I'm skeptical at the moment we'll see where we end up one more nice small thing that this is not for everybody but this is very much for me optimizing bundling of external packages bundling external packages can improve the colar performance of your apps in the app router external packages are bundled by default and you can opt out specific packages using the new server external package config option in Pages router external packages are not bundled by default but you can provide a list of packages to bundle using the existing transpile packages option this is nice because it means you get one bundle going to the server so it's much more performant because it doesn't have to orchestrate and find all these different things and load them all synchronously and block randomly on the network level just sends one thing when you combine this with another small announcement that they made about their infrastructure where they are now caching the bite code that V8 generates when you give it the JavaScript code so they can spin the bite code up immediately on the Lambda and Instead This is always going to help a lot with cold starts and overall response times when using nextjs in servos environments especially if that environment happens to be for sell sorry Dax does turn out for cell was making things faster than Lambda by doing things Lambda isn't yet someday Lambda will probably copy them I don't expect it to go otherwise and I'm sure there's still some overhead the way versell does things but it's really nice to see them challenging the current ways we do server lless both on a framework level and on infrastructure level and I'm excited to see how this comes out for everyone one more thing since the word Pages router is here which I don't actually think is on this page a whole lot yeah the only place Pages router occurs is this optimization thing but there is one other place that this occurred believe it or not they actually improved the page router performance I did not expect this but there's a performance Improvement only one according to the docs here at least of all the things shipped in the 15 RC in Pages router the old way of doing things pre- server components got a performance Improvement on server rendering I think that's cool I like that as they've been exploring performance side and server side rendering stuff but they're finding optimizations that affect users that are on the old Tech hopefully this helps ease the concerns that some pages router developers have that they're being left behind and app router is the only way I have had done good word from forell the pages router it's not going anywhere will continue to receive support like this so if you're shipping things on it which I even am to still to this day you don't have to worry so much this is a cool proof that that is the case that's all I got on this one let me know if you're excited about the infer stuff as well so I can possibly cover that in the future for now this is next1 15 and all the other small things that were announced at for sship maybe I should grab a white shirt next time because it seems like these black and gray ones are out of style but until next time peace nerds

Channel: Theo - t3․gg

Views: 93,405

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

Id: Txf2pbR2Cyk

Length: 19min 33sec (1173 seconds)

Published: Fri May 24 2024