Tim Neutkens
===

[00:00:00] Hi there. And welcome to pod rocket, a web development podcast brought to you by log rocket log rocket help software teams improve user experience with session replay, error tracking and product analytics. Head over to log rocket. com to try it for free. My name is Paul, and joined with us is Tim Neutkens.

He's the co author and engineering manager over at Next. js. We're here to talk about what's new with Next, because, man, there is a lot of new stuff. I'm sure if you listen to this podcast, you yourself have heard a lot of what's going on in the community, so we're excited to dig in, excited to have you here, Tim.

Thanks for having me.

You are the engineering... Manager over at Next. js. How did you grow into this role? How did you get that? That's a one heck of a title. I mean if you're talking to other devs and they're like, I want to know what's going on. Go talk to Tim, right? So yeah, how did you get into that journey?

It's quite a long story. I could do a whole podcast on it. I recently wrote it down in like internal blog posts at Vercel as well. [00:01:00] And basically like I, I just crossed my six year mark at Vercel. So I joined pretty early on in the company. And mostly joined to, because I was like contributing to Next.

js before that already, like I had been contributing to Next. js since Uh, Nexus was released at the end of 2016 it's like Sharma reached out to me cause I had been like active in the for sale community for quite a while. And he was like, Hey, we're building this new thing. You should have a look especially as you're working with PHP at the time.

So it was like building Magento web shops WordPress type stuff and like some custom PHP things. But I, like I was learning Node at the time and. I just found it interesting to contribute to some of the other projects that Versailles was building at the time. and that turned into like me going out and working on Next.

js, the very early version. For quite a bit in my free time next to my job and ended up being like a maintainer of the framework for quite a bit. And then like eventually got hired to work on some internal stuff at Vercel and then that turned into like working [00:02:00] on Nexus full time and fast forward, like the six years just the fast.

We now have a larger team multiple people working at full time. I'm working at full time , and that basically meant that we had like a need for like engineering management, like tech leads type stuff as well. So I've been like juggling both at the same time trying to help out with the tech side as well as doing EM related work for Vercel.

Yeah, now since recently, like trying to skill more to tech lead again with someone else jumping in on the M side. So like touching a bunch of code again which has been nice. 

Yeah, you've been there since the beginning really. 

yeah, pretty much. , I started working on Nexus like. Months after it was released or so. And eventually like I ended up doing so many contributions that Sharon reached out and being like, Hey we want to add you to like the original, like authors list of the framework, because like you've been doing so many contributions that like, it made sense to them, which was, at the time was pretty hyped.

that's, That must have felt like you were on top of the world that day. I [00:03:00] think it's interesting that you said that you were like really versed in the PHP world before then. And it's funny because when we talk to people on this podcast, they're like, okay, so you got like the PHP guys, and then you got the next JS guys.

And here we have Tim who's like both of the guys at once. Did you find that you had to change a lot of your ethos about how you go about web development coming from the PHP land where you have different markup, you have a specifically server environment. And then you come into next, like maybe like a few years ago, it was different than what we're looking at now, but total mental paradigm shift.

Was that challenging for you?

So the main thing that was very interesting to me at the time when I like an extra social release, like this was The time where everyone was building their own, like webpack on face. It was building their own like guilt files, like all this, like configuration that we're doing in no chess land in the PHP side of things, like things are figured out at the time.

And it's gotten much better. Like the language itself, like PHP as a language has evolved quite a bit. Same as [00:04:00] JavaScript, really like JavaScript has evolved so much over the last six years or like seven years since like natural sources released, like You know, I have like ES modules that is fully baked.

You have all these like language features that are fully built in and things are, like where previously people would say Oh yeah, the language is like not complete or I don't like these things about it, or I can't do this particular thing in the syntax that another language has, like JavaScript is pretty good at this point and.

PHP at the same time as well. Like you have like strict typing and PHP and dependency injection, things like that. So for me, it wasn't about the language per se, it was more about the model in which you're programming as well as , in like PHP land, you had a bunch of frameworks that were like established and had like decent tooling, like really decent tooling.

And then you had some other framers that were less like established per se in terms of what they were doing in the. Not yet side of things, especially in react community at the time, like it was like you built your own framework from scratch at that point. So to me, it was like when I saw Nexus for the first time, I was like, Oh, it just makes sense.

It's like a [00:05:00] lot like what you're doing in PHP. It's more structured. You have all the benefits of react like the component model and like how you write components. You still have service at rendering, which I was interesting at the time as well. Like I said, I was mostly building e commerce websites and 

at the time, at least like Google, wasn't really good at like doing this indexing of like client side render JavaScript apps. That was at the time, it would still take two to four weeks before like your particular page is indexed. Now it's like less than 10 minutes or so from what I've heard. So the capabilities of like crawlers have increased as well, or at least Google's crawler.

But at the time it was like really Oh, it's like service that rendering for react can actually write all my components and. Use those as bricks , to build like websites. And that was like something that was really in my mind, like missing from the way that you write like applications in PHP, for example.

It's more, so I focused on like a model view, if your controller and the few would be like an entire page, and you would be copying a lot of the logic between between these views basically

whereas like in react, [00:06:00] you can do components, 

I find it interesting though, that you do mark them as there's a lot of similarities between them. And even though we're in next JS, the most popular thing that people are using these days, here you are tried and true PHP background and you're like, yeah, there's a lot of parallels even though there are differences and it's just cool.

It's just interesting to pull that harmonious like interaction from you who's been there since the get go of next JS. And you've been talking about tooling, Tim, I think in this episode we're going to get into tooling because that's been the name of the game with next 14 people online they're going what another version.

Next 14. Oh my God. But it's okay, chill out. We got tooling to talk about. We got interesting things. So right off the bat, Rust based compiler reaching stability. Why is the Rust based compiler such a big deal? People hear Rust, they think of speed. I'm sure there's that, but there's some other things that go into this decision.

So I'd love to hear about that.

Yeah, it's definitely been interesting. So so let's start off with nexus 13 and then like to switch to 14. So with nexus 13, we basically did a completely [00:07:00] new approach to building like nexus apps, right? like it's a completely new way of structuring your code and a completely new way of Interacting with reacts in a way because you now have server components, which is a new concept that you had to learn.

And basically what we did there is we took all the gripes that people had with building with face writer and the pages directory that you had in, in like previous Nexus versions, and we basically said okay, what if we take a new approach here that is more focused on like fixing all these problems that people had before.

So like I can now do layouts, I can do data fetching in my components. And no longer have to write like an API route for my form. I no longer have to write like API route for fetching data on the client side per se. What if we take a bunch of these learnings , and like work with the React team instead of as our own framework on top of react where we add like a bunch of new APIs that are like part of next jazz instead of react, we actually tried to build them into react as much as possible. And I say, we like gave [00:08:00] a bunch of feedback here. We have some people at for sale working on react itself.

anD we try to basically upstream a bunch of these learnings over the last seven years of building next jazz. And a big thing of that was like. Making sure that server components, which is something that the react team has been working on for a while, actually gets into existence by building all the compiler tools around it.

And a big thing of that was making sure that this compilation is still fast. If you reason about like server, a client server, a client like waterfalls of not waterfalls of like data fetching, for example, which is what people usually talk about is like waterfalls of compilation, right?

In the current, like today's world of compilation, there's a few only a few bundlers that can do going from the client to the server, to the client, to the server compilation. So it's like bundling of code that is like going into this module graph of like server code and client code, but are actually like a client component can import server side code in a way.

It's not exactly server side code, but it's like a reference to the server side code, [00:09:00] but we still need to bundle that server side code. And this is why we started building a turbo pack. , so, In essence, it's like a bundler that has this single motor graph. In that way, it's like similar , to parcel, for example, which has a single bunch of graph as well.

And what it's allowed us to do is to have this like client component can import a server action and a server action can import a client component type of like compilation waterfall without actually adding additional overhead. We also use that to take all the learnings from seven years of building like Webpack in Next.

js, and build like a better bundler that is caching by default, having this fast incremental compilation fast initial boot up like all these benefits that you need in order to make Next. js apps faster. Like those are all built in and then like we released it as part of Nexus 13 as very early preview.

Then in Nexus 14 we went further with that. Like we, we've only spent like a year building this like extensive builder tooling and like the Nexus side of that as well, which is large as well , [00:10:00] because Nexus does a bunch of specific features for bundling as well. And we're now at a point where over 90 percent of the tests are passing. And so next, this is like a test suite is 11, 000 tests.

Oh my gosh, that's

and they're all integration tests. so basically built this like turbo pack to go through these like modular layers. And then like in excess, , 13 to 14, we basically went and we spent this like year building out the entire like building set up and this building set up is now like passing 90 percent of tests in excess.

Or over 90%. Actually, it's like at 92.6%, right? Right now, we've launched this website called Are We Turbo yet? Dot com to keep track of that so you can see it yourself as we progress through that. But Nexus itself is like a test suite, is like , 11,000 end to end test. And these 11,000 end-to-end test, they run on every single pr, right?

So every single PR you open is going to be tested against all these real world. nexus apps that are basically running. So like they, like the test [00:11:00] themselves, like we added files, we check if that actually updates the page, that kind of thing. And I make sure that things are very stable in terms of like pages writer, app writer, that kind of thing. So for TurboPack, we ran the exact same test suite currently only for development, which is like around 6, 000 tests, ,and these 6, 000 tests out of that's 92 percent are now pausing basically. We still have some work \ to be done. It's like for a hundred ish tests that still need to be passing.

And we're making steady progress on that. And at the same time, we're now asking people to try it out more so that we can get their early feedback on. is This thing working for me or is it not is it compiling correctly, that kind of thing. anD like seeing some like of the early results, like in our own app, what we saw is.

Pretty decent, like HMR improvement and and all that. 

And this is all TurboPack, right?

Yeah. So it's like turbo pack. And then on top of that, there's a layer of like next specific features that, that are needed to do bundling and extras because extras itself is like particular outputs and things like that.

Also off of Turbo, you folks. [00:12:00] now have Turbo Repo, right?

Yeah, so turbo brand is like turbo repo turbo pack turbo repo is for building your like monorepos. whAt turbo repo does is it basically allows you to define like a config of these are my projects and then it only recompiles the projects that are, that have changed between if you make a change to like, so you have three nexus apps next to each other in like a monorepo and you're only changing the marketing pages, for example, that kind of thing.

And your like dashboard is a completely separate Nexus app it wouldn't recompile the dashboard if you're changing the marketing pages, that kind of thing. And , it's not just for Nexus apps. It's for any type of task that you would throw at it.

So it can like dedupe anything that true caching, like it will basically not rerun anything that hasn't changed.

And if you're listening and you want to find out more about Turbo Repo, how it's used in the wild, we in particular here in Potterocket, we had Alex Ternikian, who he helps teams over at Hulu and Disney plus successfully use Turbo Repo to basically [00:13:00] create giant ecosystems that have good DevEx.

So, Check out that episode if you want to dive more into Turbo Repo specifically. Tim, we have a lot more to cover. We're going to hop into specifically server actions, app router, partial rendering. Right before we do that, though, I just want to remind our listeners that this podcast you're listening to is brought to you by LogRocket.

And if you're building a web app, big or small, you want to spend less time debugging, less time going through that Error console and more time writing good code. You can use LogRocket to find and surface issues faster that you might not have noticed. You can get heatmaps, session replay, full capturing of DOM events.

It's pretty impressive. So go over to logrocket. com today and use it to start supercharging your building of your next great app. So turning back to Next. js, server actions, they've been floating around the web for a little bit and half the things you hear are people yelling at you about how they're not stable and how you shouldn't use them.

The other half are people talking about how fast they can write apps now. So the long short of [00:14:00] it, Tim, for people who are new to the show, what is a server action 

if you're familiar with RPC so remote procedure calls basically it's a built in way in react to do RPC. And the quick explanation of RPC is like, you can basically pause a function from the server. To the browser and then like the browser can call that function and like pause values, \ and you write it as this is a normal function.

And I reasoned about it as a function, as a developer, but under the hood, it changes it to be a transfer protocol. So it's a way that like, basically you can call back to the server but you writing the code, you actually are not reasoning about it. It's just this is the server, this is the browser per se.

You reasoned about it in a different way, so you reasoned about it as like I can like I can access a database or I can access my like data layer that has like secrets and I can read from this database or I can do mutations on this database or that kind of thing.

It doesn't have to be a database. It could also be like an external API, that kind of thing. But it's you get what I mean? Like it's a data layer, right? 

It felt very [00:15:00] similar to the first time you data load an app router and you're just like, Whoa, I'm just like thrown in a weight. A function right here, in my component. It had that similar ergonomics to it. As a developer, when you use it 

yeah, for sure. It's like server components in react allows you to basically write a react component. It's like an async function, whereas like usually and people that have used react before they, they know that you can't have an async function that is a react component because you couldn't await something.

You would always have to do like a use effects or anything like that, or use the library. Usually we use the library, not use effects. So libraries would be like as the VR or react query or Redux to basically handle this state of the ceremony you had to do to get like the data into your app and show loading states, that kind of thing.

that's a good word for it. I, I just wanna say, I love that you used the word ceremony. That's 

Yeah.

the best word.

so it's like this like slight boilerplate you have to add every time to, to do a data fetch to the server, to access your database \ and you can't even access your database, right? In the normal React [00:16:00] component, like you would have to build like a data layer. There's like a public API that you can call.

So it's like , in actions that would be like pages API and you like put something there, or you would have an external service that, that does this as well. Now in the server components, and there's like ways to do this with a service approps, where you do have access to the server. But the ergonomics of that is like.

You can only do that in a top level page, right? Because like next just needs to know about like where this is. And we can't reason about the complete component tree because we're not uh, running, like we're running reacts, but we're not react itself. We're not like aware of the component tree. We're just aware of the top level where the entry to the react component tree is.

So that's in pages riders and uprider, we have server components and server components as this new primitive, which is async function as a react component. So you can now do a wait and just call like a database or a data layer or anything like that, and make sure that it's always on the server so you can always reason about it as I'm running my data layer function there's like database access.

aNd then I [00:17:00] render something, right? So it could be like, I'm going to get a list of all the users and then I rendered the list of the users. Or I pause the data from that down to a component that renders the users. thAt doesn't mean you can't use state \ or anything like that. It means that you now have a new type of component that can do data fetching.

If you've been around longer in like React ecosystem, there's been like this. Presentational components versus like container components in the past. It's like that in a way. It's not exactly the same, but it's a good way to reason about it. It's these things are doing data fetching.

And then I have like presentational components that actually create the UI for all the data that I've fetched before. So it's just like one way to think about it. The way I like to think about it, it's like. I can render pages to pages are made up of more components and those components could be either more server components or a client components that have interactivity and all the server components can also render more client components that have interactivity and you can pause props to the [00:18:00] client component, which is also more like rendered UI.

So it could be like you pause more divs or anything that you want to pause. To a client component as well. So it's not just like , you can do like server client, but it's more like you have one side on the server that renders the entire tree. And then there's another render for rendering all the client components on the server for SSR.

Then on like client side navigation, you only render that tree on the server. And then like you pass it to the browser and render all the rest of the client components, for example. 

I have a quick question. When you said, so on a client side, navigation, it's gonna send a message back to the server and then re-render it on the server.

yeah. The way to reason about it is, it's it's similar to a normal navigation, like using the browser, but instead we were actually only asking React for just don't give me the HTML. Just give me the React RFC payload is what we call it. It's React server commands payload. If you get that, React can then render that in the browser.

So you don't have to get the entire HTML. So it's not like turbo links, for [00:19:00] example. But in a way it's like similar to that, where like we get some intermediate like representation called RSC payload that we can render in React in the client side.

Just a really quick, like deep question here. Does the RSC payload need to have a defined path into every node within the tree?

Like you can pass server components into a client component as like a child. And I would guess that you have a server component. Rendering the client component, which is then passed another server component. And there's a direct link between the original server component and that child that gets rendered.

There's no like island, of server component or is that okay? Can you have that?

So it's less of a it's not really an island. It's still one

Yeah, that's not really the right word.

Yeah. So, Usually like when you talk about island architecture, it's like, oh, these can all render by themselves. ReAct server components, do that and you can write a framework that does that. But what we do instead is we we built a single React tree.

That's [00:20:00] like top to bottom, a server component, basically. So it starts in the server component and there's a server component you don't see, which is like the one that Next. js adds. And then like your own component could be a server or client component. But a rendered as part of a tree.

And that's why like layouts and pages can have like use client as well, but they don't affect each other. If you put use client in a layout, it's not going to mean your page is a client component as well. So that means it's a single tree that's rendered. And that is passed to the browser on client side navigation, and then react on the client side uses all these references to client components.

So then render that with the props that you've provided in the sort of component. Uh, If you don't provide any props, obviously there's no props, but if you've looked at the compiled outputs in the bevel rebel, for example, or anything like that, you would see react, create elements for all the, like JavaScript, that's like JSX is turning into JavaScript and you'd see react, create element.

And then it would be like dev like coma and then some like props, the RC payload is like that, but like a more. liKe it's [00:21:00] transferable version of that. It's not JavaScript. It's more an intermediate representation that React can use on a client to create a new React tree as well.

That's neat to hear that it's not intrinsically like they have to be neighbors to each other and that there's the capability of separating them out in terms of, I don't want to call it an island because you're right, it's, that's a totally different paradigm, but you can have a isolated like server component that is a few removed from its next parent.

That's neat. And just to be clear, we were talking about server actions at one point. I wanted to wrap that up with getting your confirmation to him that with next 14, these are stable. 

Yeah.

So go ahead, go crazy with them, use them. Have you gotten any constructive feedback so far from the community on what is the next sort of integration pain point or area you want to sand over in the next quarter or two?

It's definitely been interesting on the server action side of things. The most interesting thing here is that there was like this one slide that everyone saw on Twitter because they had it turned into a [00:22:00] meme and everyone was sharing like different versions of it. I think that the most funny thing I've seen is like use binary, which you would be able to pass binary code to your function or something like that.

anD someone like edit, like use PHP as well. Like you could write PHP in like your server action. It's a way to actually work, which is funny as well. But the idea is not so much like don't get hung up on the way that you alter it per se and that you can do database queries. And there was this one slide, which is basically I'm doing an inline query to insert a new user into my database.

The main thing there was like, it was just showing okay, I can do database access. And it's like a community talk which is like in the whole context of that whole talk. It was a really like really good talk. We recommend watching it. The idea here is that you have to write like an API layer or some kind of like in between for handling like forms, for example, and I can actually write.

These functions that have to be called when the form is submitted, for example, and be progressively enhanced inside of your component. And from what I've heard so far, so there's a few like [00:23:00] early adopters and like larger apps they're a ton more productive and they don't have to do this like I said before, like ceremony to get like an API route.

And then can be used to take in. A particular form submission, the big difference here as well is that this is part of react, right? Serve action is not an access feature. It's a react feature. And because of that, it means like it's integrated into their reacts form element, for example.

In the react form element, you can now like observe this posting of the request as well. So you have use from status as a hook inside of your form that you can now use to check on like, is this currently submitting or not uh, you can do like use reducer for, like a server action which is like use form state which then it's like a reducer.

That's every time you post to the like the question that we got a lot was like, how do I do errors, for example, in my forums? And this actually allows you to like post to the server and get a new result back that then applies that, that particular, like new state automatically for you. So you don't have to reason about that.

And it's built into react. So it's very deep integration into [00:24:00] that whole model. And so directions was really like the missing piece, right? Like that not being stable, like you really needed to work around it mainly quite a bit. Now that everything is integrated and you have this single like server components or actions model where you can do the rendering plus the mutations, what we're seeing now is that like people are starting to build.

Like more complex apps with this type of approach. anD we're obviously doing that internally for sales as well. And we're partnering with some, like of our larger, like enterprise customers also guide them through this option of server actions or components 

you were mentioning about these great like hooks That we have for forms and in react now, do you feel like this is going to make libraries such as formic react hook form obsolete?

Because just to be clear, you can still use those with your server actions like you can write make a server action that calls your hooks and your validates and all that. But do you feel like those eventually are going to get phased out? Why or why not

that's a really good question. And that's been most [00:25:00] interesting to me that no one else has asked it before. But the idea here is not so much that we're replacing some of the form libraries. Maybe if the form library, the only thing is doing, is it currently submitting and give you like some errors, but in most cases, these are not doing that.

Like the, those libraries are doing way more. They're doing like giving your like thought schema to Dan, turn it into a forum that can be like submitted and actually has like validation. Like next she has and server actions don't come with form validation built in, right?

Like there, there is like the primitive to do form data and you can take in the form data, but now you have to validate that using some libraries. So that could be a schema library like Zod, or it could be, like a TRPC like library that can do this for you automatically. And then like the interesting thing here is that what I think will happen and we haven't seen this yet is like this from libraries can actually build a complete experience now, whereas previously they couldn't.

So you can now build a. Server component or like a server [00:26:00] component form that it takes in like a soft schema and it can do both the server side and the client side, if you're able to sterilize the schema values as well, or like the foundation. We're not there yet. And I haven't seen it yet in this community, but.

It's it's definitely where I think things will go over time once people have tried that more.

and one of my last questions about server actions because you brought up to your PC in particular there's the famous t3 stack we've had Theo himself on this pod a few times and that's a well known combination got to your PC You got next JS some folks have been saying that you know taking to your PC putting it on a dynamic route when you're using app router when you have the ability to do server actions is It's actually an anti pattern.

you agree or disagree with that?

So the main thing that you see with tRPC is that it does multiple things, right? So it's not just the RPC layer, it's also the validation layer. It's also the structured responses, that kind of thing, [00:27:00] right? Like it's doing schema validation for you, that kind of thing. What I think will happen is that there will be , some kind of like TRPC adapter or like some kind of library.

Like, TU actually was building a soft schema validation library for server actions pretty early on when we sent in the first demo of it. So what I think will happen is that there will be Parts of TRPC that are currently working really well. And like I said, like we don't have this validation that is deeply integrated into the way that TRPC works.

What we have is the RPC layer and the way that you define it. So it becomes actually like easier for TRPC like library. It doesn't have to be TRPC itself. Don't want to force their maintainers to do, to do anything to support this per se. And the current like API route approach still works, right?

Like it, it works in the same way as it was before. The main difference is that now you have this built in, RPC layer that works with react and that has like some other benefits. One of them is you can now pause like this RC payload as well, or like RC through this same [00:28:00] layer. So what this means is that what you can do is a separate API route case.

It's you can't pause. Like my component that does some like rendering of UI, whereas like in the server action sketch, you can actually pass through a say you do the error validation and you want to render a particular component that it's like, you need to add this many more characters or something like that, that it's like specifically styled.

We don't want to put it as part of the bundle. You can actually pass the error as like a component that's rendered instead of like a message that you have to put in and render that as part of the client component so the interesting thing with server component is that it has the same serialization layer that like the server component, the client component layer has.

So you can do a lot of this, like passing off specific components as well through this layer. , so my take on to answer your question fully, it's my take on this is I think TRPC will evolve to have some kind of like server components wrapping feature, for example, where it does the validation.

It does the other [00:29:00] things that TRPC does, and it it just doesn't handle the, like calling the server part, which is only a small part in practice.

And I know for a fact, the T3 team is working on this right now. As we speak, their discord is buzzing with activity. Just had to pull your opinion on the anti pattern thing because it's been a hot button topic of conversation of if it's an anti pattern or not. People have a lot of different thoughts about that.

Tim, we are running up on time. We only have 10 minutes max left, but I have to ask you about Partial rendering because it seems like it's a really big deal, especially since that time for first load and seeing content is so important. It's such a big deal that if we bring up Theo again he posted a video saying we fixed app router, quite a bold statement, right?

So why is partial rendering such a big deal and why was it something that came into mind when we switched over to app router as the new paradigm?

Yeah, it's a pretty wide topic, but the [00:30:00] quick explanation of partial pre rendering itself is that previously what you had was you can do static or dynamic rendering. So what this meant in the pages writer case was like, you had to get static props or get service of props, get static props didn't mean like static, as in it's not never changing after the build it was like, it's a render during build time.

But then you can provide a revalidation period. So it would be like 10 seconds, for example. And I'm like, after every 10 seconds, we do like a new render of the page in the background. And I like replace the cache entry basically. Then for dynamic was like every single request is going to render the entire page again.

And do the data fetching again. And if you have a header, that's the same you're out of luck. Like we have to render that again and we have to fetch the data for that again. Cause like there, there's no way to make this distinction between like things are static and things are dynamic.

So what you would then have to do is you have to introduce like some extra caching here. And that was like quite [00:31:00] hard. So you had to set up like Redis or like some other external caching layer that could then catch all your like database calls or all your like fetches basically.

So what we introduced in X13 was , like with the App Writer, we introduced the Next. js data cache. So this data cache is built into all these like fetches, for example, you can provide like a recall date time or you can use like a function that allows you to specify it as well for any arbitrary calls.

So that gives you like pretty decent like dynamic rendering page performance, right? So you'd like. Get you to the point where you're not refetching your header all the time, but you're still rerendering the header all the time. So just like the data is very fast then on top of that , there now it's like suspense, like react suspense that allows you to provide like loading States.

And basically the thing that we found very early on when building the operator is maybe we can combine all of these into a single model where you don't have some reason about revalidation, static rendering, that kind of thing, but instead you render a reason about a single [00:32:00] model.

That's like static and dynamic at the same time. So how can it be static and dynamic at the same time is cause initially when you hear that, it's like, Oh, it is like suspicious. Like you can't,

uh, like you can't do that. Like you can't have a static page and a dynamic page. So that is what partial pre rendering is.

Like it gives you static rendering where we basically at build time tried to render a shell of the page. The shell of the page is for example, that header it doesn't have to be your header, obviously, but the easy example is like the header is now part of the initially rendered page and that page can leverage the incremental static re rendering.

Like ISR behavior, like revalidate can be specified. So it can still re render that page, like every 10 seconds, for example. But we can now skip all the work that's done there and we only have to render the dynamic parts. So how do you mark like the deepest part of like where things are dynamic?

That's where you use suspense. So it integrates this [00:33:00] react API called postpone, where basically if you call cookies, headers, or no store, what will happen is it will trigger a suspense at the closest suspense boundary that is available. If that is like the entire page, obviously you've got the entire patients with loading state.

But if you move it as far down as possible. So for example, like in one of our demos, it's an e commerce page where the cart is dynamic. So you had a suspense boundary around the cart and you add a suspense boundary around like delivery times, for example, because that's localized to you personally.

And maybe like recommendations or products that you've been to before that kind of thing. Those are all like localized to you. They're very specific to you, especially your cart. And those have suspense boundaries around it so that you see a loading state initially, but then we can serve that entire like static HTML page.

As part of the the etch network on Vercel, for example, or if you're self hosting, it can serve that static HTML, like as soon as possible, basically what happens then is then we use the [00:34:00] streaming that we use to render like react server components anyway, and we stream in the rest of the dynamic data.

So your initial HTML, it's like the , entire, HTML page, for what was statically rendered. And then after that we stream in all the dynamic parts.

So would you say the overall paradigm here is , any static content that doesn't change could even be like a product placement, right? Because you could update that static content every 10 minutes as an example, but something that needs to load dynamically, like user data, be done independently of the page, in its own bubble now.

Yeah, exactly. And you don't like a reason about Oh, this whole page is static or Oh, this whole page is dynamic. It's more I can have the static rendering pause at build time for all pages. And it will just find the shell that is as closest as possible there. Like in, in terms of if you have a suspense boundary, if you don't have a suspense boundary

it will still be fully dynamically rendered if you trigger like headers or cookies or that kind of thing. anD [00:35:00] if you don't use headers or cookies or anything like that, you get a fully static page, right? Like it's not forcing you into it's fully static or it's fully dynamic. It's like a hybrid between the two.

And if you don't use either you can get fully static or fully dynamic still.

And one important thing to note is if you're developing with Next. js and something feels dynamic locally, and that Is more static, like when you deploy it, this is this could be one of the areas to look into and I know there's ways you could like force revalidation on that data cache. There's some differences when you run in production.

Last question about the data cache, Tim, that has Vercel needed to take any additional like product pricing and, deployment scope considerations into mind when you guys are thinking like, okay, like our hosted environment is going to have a lot more sitting in it now.

Like we're going to have data, which we didn't really have before unless people really pin and prodded.

Yeah, it's very similar to like the parser pre rendering implementation, looks very similar to how ISR already works. So like the incremental [00:36:00] static re rendering. So , in practice it did need like some changes there and especially for data cache, like we had to build a, like globally \ , scaled like a caching layer for any customer that we have.

So that has been a pretty big like investment for the Vercel side of things. But at the same time this is not a Vercel feature, right? Like it's a Next. js feature and like Vercel has an implementation of a similar like caching layer that is like globally distributed. Cause like we host our apps globally distributed.

NeXt. js by default has a built in cache as well, which is like fully integrated. And you can provide your own handler for that as well. So you can actually like. Come in and have a, file that you can export a class from that is get and set. And as this get and set could be powered by like your own Redis instance or anything like that.

And they can choose to use that basically. That is the same thing that's also used for ISR if you provide that. So it, it combines like data cache and ISR in the same like caching layer.

tHis has been a great conversation about next 13 and [00:37:00] 14 app router. This is just a whole new paradigm that we're working with. There's so much more to talk about, but we are running up on time. So I just want to point our listeners, Tim, to anywhere that you post. You mentioned an internal blog post you made, but what about the external ones?

Where can people find those?

So I don't write publicly often besides like in, in our GitHub repository. But the thing I do want to point people to is that as part of Nexus 14, we also released a new Nexus learn course. So this new learn course allows you to go from starting with the app router to building an entire application with it which is different from what we had before, which was like, you build a small blog.

Now you actually built like a real application. And it walks you through. Like the end to end for starting that to building the entire page. And along the way, it gives you like all these quizzes and like ways to try out like AppWriter and like all the different features that we've introduced.

And one more time, what was the name of that new tutorial?

Uh, You can find it on nexus. [00:38:00] org on the learn button. So it's like nexus. org slash learn, or you can click on the learn button on the website.

Awesome. Tim, it's been a pleasure kind of digging into some of the details about AppRouter and Next 14 and look forward to having you on once again in the future when more great stuff comes out from the next team.

Thanks for having me.