137: Tim Neutkens - Continuing to Innovate with Next.js 9.3

This episode of Fullstack Radio, I talked to Tim Noykins about what's new in Next. Js 9.3 and how it's changing, how they are building applications at Zite. This is Fullstack Radio episode one thirty seven. So the reason I wanna have you on the show is, Next. Js 9.3 came out recently, which, just looking at the version number sounds like it might just be a small incremental change, but in practice, actually introduces some really kind of paradigm changing, features about the way people use Next, at least in the way that I understand it. So, maybe I think the best place to start would be talking a little bit about, the major sort of new additions that came in, in 9.3 and and what they do. And then we can just kinda have some discussions around that because there's a lot of questions that I have about that stuff. So how do you sort of explain to people what kind of the major, improvements are in Next 09/2003? Right. So, basically, this whole shift started with the release of Next nine, where we released like, basically, like, for those who don't know it, Next is a, framework for React, that makes it really easy to build, web applications. So So it goes from websites to web apps, etcetera. But from, like, the very first release, like, the main thing that we focused on was making it really easy to use React, but also to use server side rendering. Right? So, like, on demand rendering, like, every request that comes in, a new render of the React app happens server side. So that allows you to, like, optimize for, search engine optimization, to, like, get a faster paint to by, basically, like, sending the full HTML, on demand. But, starting from x nine, we basically started focusing on also providing you this, like, not rendering on demand, but rendering at build time, so static generation, basically. Like, the first feature that we released to, like, achieve that is that pages that didn't have blocking data requirements that used get initial props at the time, would be exported statically automatically at build time. The reason for that is if you didn't have, blocking data requirements, the page was already static. It was rerendering the same thing every time on demand. That would obviously, like, take up server resources, be slower, etcetera. So, basically, that was an optimization. So we call it the automatic static optimization. And that means that if you don't have blocking data requirements, it's static. Yeah. So maybe to, like, get into that a little bit so people are clear on it. At least the way I understand it is, like, prior to that feature, basically, you are paying, like, a penalty on any really simple pages, because everything was trying to be rendered the same way. So everything was sort of working with this, like, lowest common denominator assuming, like, oh, when we're gonna need …