Ep 171 - Tim Neutkens on the Next.js App Router

newtkins that's how you pronounce it right uh Notekins but it's very hard to pronounce yeah like the O is um the EU is a and a is um very particular like sound that that doesn't exist in English yeah same as like oh so double like o o um but now it's easier to pronounce uh and we also have e uh which is like I uh e and then

what does sound sort of similar but like a is very uh it's like we're like most of the time English people will pronounce it as new skins nutkins newkins cool which is like n-e-w-t uh and then k-i-n-s or something uh which which also sounds very similar and like I literally don't care so yeah whichever works go all right well uh yeah let's get started man um today I'm excited to talk with Tim uh newtkins he is

um been on the next JS core team I guess lead maintainer and versel for about six years so probably next.js before that how long you've been working on next um almost seven years I think uh it's a it's definitely been a long time yeah nice um cool man so we've had a few episodes on react server components and um you know you and I had a chance to work together last year and you were telling

me recently like you've been um hearing some of those episodes and thought it'd be fun to come on and chat about it because obviously your life has been like reacts over components lately and so um I thought for this conversation be fun to basically just talk recap the last few episodes make sure kind of what we're saying is is how you think about how things work um specifically the rendering stuff the

server side rendering versus the server component rendering and um because I know it's it's helped us just understand kind of the mental model and then maybe we can talk about some of the caching stuff as it relates again to the mental model because I think uh from some of your discussion on Twitter it seems like I always I always find it find it helpful to hear how the Creator and maintainers of a project think about the mental model for a tool because it

could be easy especially for programmers to just dig into specific apis but when you understand how it's intended to use which parts you're supposed to be thinking about you know as an app developer and which parts should kind of be abstracted away I feel like that that helps a lot so that's what I was kind of hoping to get out of this conversation yeah definitely sounds good cool so yeah let's just do a quick recap and make sure kind of some of the stuff we were saying in the last few episodes was correct I think the big takeaway was

um for us and for some other folks was just understanding rendering server component tree versus rendering as it relates to actually getting something into the browser and my kind of tldr here is uh when we talk about rendering server components we're talking about this kind of higher level abstract concept of turning a tree uh getting a tree as a result of rendering some code basically and there's this two two-step pass of

rendering that happens on the server you render a server tree into a client tree and then on the initial request that client treat can come up as HTML and so the browser can request it let's just set aside streaming versus like render to string from now I think at a high level right the browser just gets the HTML representation of the client tree that came from the server tree and