Next.js === Tim: [00:00:00] Tejas: Hello and welcome to Pod Rocket, the podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, air tracking, and product analytics. Try it for free@logrocket.com. Today is an exciting day cuz we get the co-author of Next Js and the next Js lead maintainer at Brazil. And also my friend, Tim Kins. Tim. it's a privilege, it's an honor to have you on the show. I'm excited to talk to you about all things Next Js, specifically 13.4 that was just launched, at Marcel ship. But before we get into it, why don't we start with, an intro to yourself, Tim: so like a quick introduction about myself, founded for Self for five years now. working mostly on Nhas, before there was a, a core contributor for about a year. so that was like right around the time that, it was first launched. I feel like in the, for self community for quite some time. and then eventually, I ended up working on basically my hobby project, which is next years. so I've been working on e-commerce websites, for an agency before that[00:01:00] and now I've been mostly working on exercises for the, for about five years. Yeah. Tejas: and before you joined Rael, so when it was just a hobby project, you also used it.do you count yourself as a co-author of Next Js or did you join after? It was like initially written. Tim: I, I joined maintaining the project, slightly after it was launched. but at some point, Khar basically reached out and said Hey, We're going to add you to the list of archers of the project cuz you did so many contributions, in the few months right after it was launched. so I, I got that title, didn't end up asking for it. I would've not minded if that wasn't the case, but it's it was a nice, recognition for the manga was putting in, Outside of, cuz I wasn't using it for my day job, I was just like contributing to the project cuz I found it very interesting to work on. Tejas: I also find it very interesting, to work with. it's my go-to for React. And in fact, I feel like that's the prevalent advice, right? if you're starting a React app, it's probably best to start with next JS or some framework. [00:02:00] but for the sake of. Brevity, we'll say Next. Js. next JS recently had a big release, and it was a really nice blog post to read. I'm talking about 13.4 where app router is stable. I wanna talk to you about this, and I'm specifically interested in this, like in how next JS has been able to stay true to its core values or core design principles. So I was reading, the original blog post that introduced njs to the world, not 13.4, but like 1.0 many years ago. and there were those principles, right? There was, zero set up, use the file system as an api. There was only JavaScript, everything is a function, et cetera. I'm curious if you could speak to those principles and then how, NJS adheres to them, and the process behind that today. Tim: Yeah, definitely. So it, it all started with a readme. So there, there was like a Readme that Sharma wrote. and that one, was basically like the blueprint for like, this is what the things like that he wanted to, to solve with this framework. So the framework that originally wasn't even called Nexus was called N four.[00:03:00] it was like a handlebars ish, like special templating language, with the. like the file system writing and all that. And they were using that to build the Versace website. so this was really like, not meant to be open sourced, from the start or whatever. it really started out as we're building this thing in order to ship Foster for Versace own properties. so then at some point they basically made this big shift being like, Hey, we're going to use React instead. which wasn't a. Like a super clear bat at the time. it was like end of 2016 ish. Reactors got popular, but it wasn't like as popular as it is today. and basically they needed like a component model to go with that. So it's really like the core principles was like we're doing file system based routing. so it just means like you create a file in your pages directory, any file really, like you, you call it like pages about yes. And. That's a route. you can now start coding,[00:04:00] in a way that's really similar to phb. you'll often hear people joke around, oh, like NHA is becoming php or Rails or, whatever. But like that, there's a reason for that. and that's like also because a lot of the folks that worked on Nhas, have been active in a PhD community at some time. Have worked on work brass or, other frameworks. And, a lot of the ideas that started, in other languages or frameworks or all that, made its way into like mainstream usage but changed over time or wasn't as easy or things like that. So you started with file system routing, as the. ways you just create a file and start, working on your specific route. and this file system router in the end turned out to be, a really big bet on, other optimizations we could do, right? So one of the things that Nexus can do is it can now split your JavaScript bundles by the, individual, files that you're creating in your pages directory. And it was a big step at the time. cuz [00:05:00] what we were doing back then is web back, let's just bundle everything into a single, JavaScript file. and have the, have code splitting, but code splitting couldn't really do anything cuz in the end, you were initializing all the code. Cause they get our side effects in JavaScript and all that. and what we did instead is Every page becomes own JavaScript bundle. and then from there we take it to more granularity introducing dynamic imports and stuff like that. Tejas: Right. and I do want to stay true to also the spirit of giving listeners, actionable things they can do, based on the next JS story and with next Js part of that. You mentioned a couple things. You mentioned, it started with a read me. And I love that because a lot of us just start hacking immediately, especially in the age of create react app or even create next step. You get to read me and then you start building something. so I love this idea of no, no, no. You start by writing it down and then you implement. and I do feel, I don't know if you'd agree that this is something that, this is a principle that will influence a lot of people's engineering for the better.[00:06:00] I'm curious, you mentioned this routing and how it led to the innovation of. Route based code splitting around 2016 when N four was a thing when N four existed. I'm curious where, react Router was it not introduced yet? Was it new? And I'm not trying to draw any, controversial lines or anything. I'm just curious about the state of the ecosystem at the time. Tim: I'm not sure to be honest. it did exist. I, I was using it for, a project, At work at the time. so I do know that we used it there. I'm not sure which version it was. It could be there was an earlier version or something like that. but this shift of you're not the defining your route in a component for example, was some of the, the main shifts that nhas, introduced to the ecosystem. Tejas: That's incredible. I'm curious, was N four like a acronym for something or like. Tim: I'm not sure. I would've to check. it was probably something like [00:07:00] that. but in the end, like it, it just turned into next. Tejas: And I love seeing, as I said earlier, I love seeing how, using the file system as an API is still true. Even with this big shift right from pages to app. you still, instead of the file itself being the route, it's now page dot TSX or jsx, but. But the directory is still the identifier of their art as it worked the sub path. I love how you've stuck to that. The second design principle is only JavaScript and everything is a function. and indeed we also see that everything is still a function, except maybe metadata, which is an object and also some config stuff. but in spirit everything's a component. I love how all of this is. The same, but has gotten better. next JS 13.4 introduces some new features. I think the most popular feature, the most discussed, the most controversial and sometimes the most misunderstood feature is the use of React server components. I've heard a lot of people honestly divided on these, some. Love it because, oh, that's fantastic. That means everything's [00:08:00] getting smaller. We're shipping less code because a lot of the computation is done on the server and we only ship minimal rendered components over the network. also it improves the data phishing story. You can have async components that execute only on the server. but I've also heard a ton of criticism where people say, oh my God, this really conflates my mental model, because now I have to think about which component is which. And also, context, a lot of people complain about, server context, client context, et cetera. I'm curious if you could speak to that. and also if we could give people like a sentence or two that kind of summarizes the best way to make use of these primitive. Tim: Yeah, that makes sense. for a moment, when you started talking, I was like, maybe he's going to mention that layouts is the biggest thing, but like there, there's like many other, like benefits to Appra that is solving some of the so the thing is like in the nexia, community, Server components wasn't really a thing that people asked for, like a lot per se. It was mostly, layout streaming, like suspense boundaries, not waiting on, get service props to, to [00:09:00] get results and things like that. So it's really there's these, it's like very large, amount of, issues and, feature requests that are now solved by. changing the underlying architecture of Nhas. And that's that's been our main goal with this. It's like solving the actual problems that people have a lot in Nhas apps today. so one of these is, this layouts thing, if you create, we could have added layouts in, into pages, but it would've been less ideal than what you get today. the server component part is, Basically taking this gears of Nexus having server side, integration. and a good example here is you had gut server props, etic props, etic parts, and all these nexus specific APIs and these kind of influenced the React team in a way where they were like, yeah, this server side thing. we proved that works. But in the end, [00:10:00] it's not the best DX or not the best way to compose your components. Or even it's not a way to compose your components, right? you're doing it separately from your componentry. So what if we move all of this data fetching logic and rendering logic that is not needed on in the browser, per se. So structural things in her page, for example. and move all that rendering to the server. and solve, many other problems in, in the, in the current ecosystem around React. So one of them is, we're shipping a lot of JavaScript to the browser. everyone will say React is quite big, but if you start looking into real apps, it's like React is quite big, but then it's still only like 10% of your whole app or something like that. And with server components, we're basically shifting this back to, react is quite big still, unfortunately. we have some plans to get to a point where that's better. but that takes a lot of effort and time [00:11:00] to, to develop, like a smaller, like alside basically. But now we don't have this client side code bit that you are introducing yourself. if I write an access app, I'm going to pull in all these libraries, stuff to format my, currency or do internationalization or do, data fetching or like all these libraries that you're using because, A few years ago, MPM published at like 90% or so of your code is actually not your code, but someone else's code. You pull into mpm, and in practice that's like what you're seeing. You're like pulling in all these libraries to then do all these, functionality for you, but you're also shipping into the browsers and like with server combined, ensure shifting that away to the server, which, has the bundle obviously, but then. It does other benefits as well, it's closer to your database or it's has lower latency to your database or your APIs. And this allows you to do data fetching in your components cuz [00:12:00] then, if your database queries are less than a few milliseconds, then you can like, uh, just keep rendering components due to, to the due, the data fetching there. And get the result out, send the result to the browser, which is what sort of combines does, and then hydrate that without the actual need for all the, the static bits in that. When I say static, it's like the Ds, the header, stuff like that. You can still have dynamic pieces where you get client components, If you used to react, before server components, that's basically like any component. and yeah, it's really exciting to see like where people will take this cuz it allows you for way more, granularity and what you're sending to the browser, but also it now allows you to. The site between I want to render this component or this other component. and it could be separate bundles, for example. You get way more granular code splitting, by default as well. Tejas: Yeah, that, that does sound really [00:13:00] powerful, especially this idea that because of server components being a new primitive, it unlocks and unblocks a whole class of issues. For example, layouts, streaming data fashioning, et cetera. That said, the primitive of silver components itself is something that I think people are still very interested in. And I do have some more questions, but we need to pause a bit for a little word from our sponsor. this podcast is brought to you by Log Rocket. Log. Rocket offers session, replay, issue tracking. Product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve conversion and adoption, spend more time building a better product. So I would encourage everyone, check out Log Rocket if you're enjoying this conversation. But to come back to server components, I'm curious because React has before Next JS and other frameworks, react has been. Predominantly focused on client side apps, right? we've seen so many s spas, single page applications built with React. I've got many production, and server components is a massive shift to that. I'm curious if. [00:14:00] This came about, if the React, the people who work on React, the React core team, have been a part of some type of conversation that led to, did, what I'm trying to say is Njs in my mind, popularized this idea that React works better with a server for multiple reasons, route-based code splitting as one. I'm curious how the React team, decided, let's look at server components and I'm curious if the next JS team had some type of say into that. Tim: so like contrary to, to some people's belief, we didn't tell the React team, Hey, here's, like we're going to do everything we can to get this CER components thing that we have invented, in there, or something like that. That's really not. How it went. It was more like, Sebastian, on the React team, was, was working on these problems, for the new facebook.com. Tejas: what problems specifically? Tim: the context here is new facebook.com is a React app. it's previously [00:15:00] what you had is when, react was first created, they were using it, for facebook.com, but it was all these tiny bits of the page. So we'd have one instance of react, but it was rendering components all over your page. The rest of it was rendered by, by hack, by PHB type thing that, that meta built. and then at some point, I don't have a full backstory here, so think this is just my recollection of what, what I've been told. Basically, over time, at some point they were like, we're going to rebuild all of, facebook.com, but using, react as the core principle We're basically going to build a framework, cuz they don't use NHA or any other framework in the, from the open source ecosystem. Notice just started from scratch and they built a framework that can handle the scale that Facebook has. all this, like rendering pipeline. Take all the learnings from what they did for, for this other framework and how that worked before, and integrate it with Relay as a day later. relay was super, important for this whole story, right? Like data [00:16:00] fetching. So all of this comes down to data fetching in the end, writing data fetching. These are the two things that you always see come back in, this reactive world or any app. So the thing is that, really, it's actually really good. they optimize it for. For this massive use case of larger pages, all that. and they got to a point where you get a lot of benefits from using relay, you get code splitting based on data, for example. might sound familiar cuz that's what I brought up with server combined can code split based on, data. So earlier, you can render a different component based on your data, really allowed you to do that as well, right? you could write a query and then get a component back from that. I think that's called entry points, if I'm not mistaken. and those were really interesting ideas that they proved out and shipped to facebook.com. And then, like, has been working on this for five plus years with a larger vision of this is what the, React apps, [00:17:00] in modern React apps will look like. and a lot of this is People would joke about the suspense for getting the, getting this suspense feature. but there was a lot of other underlying things that were unlocked by having suspense, by having transitions, by having, what they call concurrent features. and a lot of the burden of concurrent features is actually on the framework that you give developers. So in order to get to a point where, You can fully take advantage of all these innovations that reacted, through proving out, it for facebook.com. you need a framework in order to achieve that level of, integration. and built in writing features basically. So you need a router that is aware of your backend in a way, aware of your, server components, for example, or your relay or something like that. And you need the data fetching, to be aware of how the writing structure works as well in order to make it, performant and only do the most [00:18:00] minimal amount of work when you're navigating, for example. So all of this turn into this R F C for server components. can we bring, And don't quote me in this cuz it's not exactly, the way that I feel about, this thing is like, can we bring the benefits that really gives you to the broader React ecosystem without having to, tell everyone, go use GraphQL. this is the thing now you're, first us to use this data layer, like this database for example. Or, This particular API or this particular way of doing things. and that's where CER components came from. you get, basically our data, you can render different components that are also interactive. and you get this more granular code splitting. The thing's missing from CER components is this thing that frameworks have to integrate. And that's where Nexus comes in basically. So we talked a lot with,the, the broader React, team and, and Sam in particular, he had this [00:19:00] vision of this is where we want to go. they built that at the mead at some point, right? they built a router that is like aware of, of data and all that. but that's not going into the ecosystem overall. Cause this is like a very particular tailored case for their particular needs. And we were like, yeah, we're kinda stuck in NextGen's pages land, right? we can do innovations, we can make this better still. We can add layouts, we can do all these things. But the bottom line of that is you're going to ship more and more JavaScript. You're going to get stuck at this single level, data fetching. So only in the page you can do data fetching. And overall what you see is that the overall ecosystem is becoming more and more, dynamic and, components become smarter and smarter basically, right? you get components that can do, more and more functionality use S O B R or use query for example, from UX query. but those are only for client site, right? you can only do them in the browser. Whereas what we were [00:20:00] seeing is that there is a performance benefit, overall if you get, this low latency connection to your database, for example, and even, you can't do database queries in your browser, right? So you still can't do this thing where, I don't know, the next WordPress won't be built on, on NHA pages directory, right? you, you would have to do all your data fetching for the whole page. in, in that single place. so that's where we were coming from our side. It was like, it is going great. NEX is growing. It wasn't like a thing of oh, we need to do this new thing in order to keep, growing the framework or growing usage. It's more like we ran into all these limitations to the model that we had. And, we saw the, server components as this way to basically get to the next level of, granularity for data fetching, solving these, this JavaScript loading problem, and giving you a better rider, which is also a big part of this. So [00:21:00] not just layouts, it's also you get a completely brand new rider that is, Aware of, transitions aware of Free React spend. it, it integrates with transitions in that way. So a lot of this is actually we were able to delete probably 50 ish percent of all the code that we had in the Nexus Rider and just offload that to your React server components. and the integration with React. These are things like injecting script tags into your like head in order to wait for that script tag to load to then render the components. This is not all part of the cerv components protocol. and there's other things that React can now do, that we've helped build out in order to make the case that, for you like building a React app on next jazz, better so Something that, Josh and our team has been working on, to get Rich React team, is basically a thing that they call float. you might have heard things like float forget flight, these [00:22:00] are the names that, the React team gives to projects and float is particularly about injecting tags into the head. So you can think about it as I render a link tag in a component, but I don't want my link tag to be in the body per se. So React is aware of that link tag and it will just edit into the head and remove it at the right time as well. This is really important cuz there's a problem that you get into when you get into framework's land, which is what if. we have this convention to do, global css, right? import some CSS file. Now you get a CSS file out. But how do you make sure that, that CSS file is loaded before React starts rendering, so that you don't get this flesh of insult content, for example. And these are like lower level bits that we've. Contributed back into React as well in order to make, overall integration with server finance better as well. Tejas: Wow. Yeah, it sounds [00:23:00] there's so much. Thank you for that, by the way, that was a very nice, deep dive into where server components came from and how Njs joined the conversation. there's a. I think a mutual friend of ours, Suze Teller, who leads a workshop, about thinking like a senior engineer, and I think this is some real, I would say, senior plus engineer thinking, right? Because the problems that you're, you were trying to solve with next js problems of nested routes and layouts, problems of data fetching, even suspense and streaming and seo, all of these problems could be solved without server components, but, They would still be subpar solutions or incomplete solutions, right? Because you would increase the amount of JavaScript you're shipping and it's diminishing returns. Like you get some features, but you also have bigger costs and it's not ideal. So somewhere along the line, it sounds like, the next GS team was like, what? Server components would solve all of these problems and more. Um, and that thinking and decision making is I think, exemplary. Tim: we've kept a, like I've been keeping a list while we were building this, of every time I got pinged [00:24:00] on the issue saying this thing is broken in, in the page directory, right? this thing is broken for me in this particular edge case. I'm like, great. this is solved in, the new app rider. Built in, things. This doesn't mean Nexus books are not solved in pages, for example. It's more this is a fundamental thing that's unsolvable in pages without a massive, rework of how everything works. And that, that change would also mean breaks your app still, right? you would have to upgrade and deal with breaking changes. so that's one of the things that we haven't really talked about is It's totally fine if you're currently using pages and you don't even want to use the App rider per se, or want to wait with, adopting it or things like that. cuz pages are still there. We didn't deprecate it. and it's still there. we just feel that the, app Rider is the, it's the future of what Nexus will do. And the main thing, there is also that. It's not super hard to migrate. depending [00:25:00] on what your app is doing, you can start with moving a single page to App Rider. Just add, use client. and at that point it becomes like a component that was similar to what you got in, in the beach directory. Tejas: I'm curious if y'all have thought about, I'm sure actually, I'm not curious. I'm sure you've thought about. when pages will lose support, or if there's some type of plan long term, maybe many years away or something to like sunset pages in favor of app directory. Tim: It's, like we, we haven't, announced this particular date of we're going to cut it off at this point. we're still going to discuss that further at a later point. for right now, there's not a massive maintenance burden on keeping pages. the only thing here is that for newer features, we will make sure that it works in app router, and probably pages will not get it depending on how it, it depends on what we're doing, [00:26:00] right? if we're building a feature that is particularly, needs to work in, transitions or use suspense or do data fetching or things like that. there is no way to port that back to, to support it in the app rider. there's other cases where we do, we introduced, in 13 four, new thing called draft mode. It's a, a new take on what preview mode was before. And draft mode works in pages and an app, but even the new rider. So if you use next navigation, like use Rider from Next Navigation, you can actually use that in pages so that it helps you migrate. because the, essentially the app, use rider is, a smaller subset of what you would previously have as, options and all that in the pages rider. Tejas: I'm curious, you mentioned transitions, I'm assuming you mean route transitions. So like when you go from one page to another, and how, the support for layouts, only changes a subset of the page based on [00:27:00] route transitions. And this is of course, something that isn't supported with pages. Tim: Yeah, the important thing here is that, when I say transitions, I mean react transitions. And that doesn't mean navigations per se. Navigations just is one thing that uses transitions under the hood. so if you've seen use transition in, react, it's basically a hook that allows you to observe when a transition is happening, so you to start transition. and it allows you to see the spending of that. So transition is basically the moment, like it basically allows you to render in the background in a way so it, it will render till the point where the first suspense boundaries hit, or if there's no suspense boundary hit, it will just render all the way to till the end, and then at that point commit the update. So what this allows you to do is basically, render a complete react componentry in the background while you're still seeing all the other things on the page, and you can still interact with them as well. and this is [00:28:00] why, why it's called concurrent, cuz you can concurrently have multiple, the way that we've been, calling it as different realities in a way. you have one render of the app, but in the background it could be that there's three other renders of the app. Happening at the same time. And those three other renders are also, kept track of in which order they happened. So usually you have this race condition, right? you click on their link, you click on under link, and then the first one comes back, you see that page for a second, you, or for 10 milliseconds, and then you see it flash the other and then flash the other, or you see it cancel in between. which is also not ideal, in some cases. And this is a thing that transition, solves where it can do this discarding of previous transitions or a previous state. but it's not really about navigations per se. It's also about other interactions that you're doing, set state or things that could be wrapped in the transition. And you can observe, these changes while data is loading or [00:29:00] while code is loading or things like that. Tejas: so start transition. So use transition returns, is pending and start transition. And when you call start transition, you effectively. Start rendering in an alternate reality. Tim: yeah. Basically that. Yeah. Tejas: that is, that cancelable a, an a running transition. Tim: so you can't cancel them. That's the thing here, you would just have it render in the background and that's fine. it will just, You three or another transition, and then that final transition is the one that you'll, see on screen, in the end. Tejas: I have a question about the new, app route because with get server side props, or get static props in pages, when you fetch your data and then return them as props to your component, next we'll embed them in the markup, right? So you have these tags at the bottom with js o n responses, with app directory. is that still a thing? Tim: so it, it depends, like the, there still is some data in the, at the end of the H shm L basically. the way that I've been explaining it, and it's not exactly like this, but you basically end up [00:30:00] rendering server components. That's one pause. So it's rendering a React component tree. The main thing there is that every single client component is a reference to the client component, not actually the component. So it ends up not rendering those that will keep those references. And now you do another pass, which is like render to html and render to HTML would be, basically we're rendering the output of the Rex server components three. So it's an intermediate, state in a way, it's basically a, an output that kinda resembles jsx, but not exactly. And it will use that to create, the actual HTML node. So this means that in the second render, that's where, client components are rendered, and that's where cer components are not rendered. Again, they, they would just take the output from the server component that was already rendered. Now the finger is, Then in order to hydrate in the browser, which is what the, unco and score next data, included all the props, [00:31:00] what we now do is we include the RSC rendered payload, like the RSC payload is what we call it. so that GSX resembled, thing that has the references to client components and then we use that, to hydrate in the browser as well. And that means that the server components are. those are still, that rendered output. The client components will become interactive at that point cuz they, will be hydrated based on these references. So we'll load the code for it as well. And that's why I was saying nexus no longer needs to do code loading cuz React has a code loading primitive here. Tejas: And then the server components, those also hydrate though, or do they just stay static throughout the life cycle of the application? Tim: it's almost like Jason in a way. So it's like a Jason of the whole reactory. but it's not Jason. It's a special format. cuz Jason can't, express Tejas: no, but what I mean is during hydration, event listeners are attached to the actual, like elements on the screen. but server components have no event listeners because they're server components. So in, in that definition of [00:32:00] hydration, then do server components ever hydrate? Tim: the reacting, the browser's not aware of server components, even existing, it's only aware of the output, of the server component. And that's a, static thing that doesn't have, that's why you can't have event listeners or state or whatever. Cause then we have to ship the, JavaScript to the browser, which would be a client component. Tejas: that makes a lot of sense because React then works with so react elements and these special server component output type elements and does its, Tim: Those are converted back into react elements basically. So you basically get a, it is like a serialization protocol of react, elements from, the server to the browser. And then this is why, different from, from just like rear rendering everything on the server and then fasting it back to the browsers. when you're navigating, for example, what we do instead, we fetch the RSC payloads and they use that to render, into browsers. Tejas: Right. Tim: is why we don't have to do H M L rendering or anything like that [00:33:00] on the server for a client set navigations. it's also why you can preserve state between, these server components three renders as well, because what you get back is you get, this static payload. and if all the keys just match up, it will still be basically react to consider them exactly the same as what it was before. So it's almost like a, State update where nothing, changes, Tejas: This is also probably why. I've been talking about several components a lot, with. A bunch of people, including the React team, and I keep hearing that it's a bundler that would tie server components and entire and client components together. It's almost like you have two separate dependency graphs. These are my server components and these are my client components. And what you just said That, alludes to that, right? Because the browser has no idea what a server component even is. It just gets this special format and then uses it in reconciliation. Awesome. we have just a few minutes left. I wanted to address some questions that people asked on Twitter. I did tweet about this and thank you for retweeting it. and there's a lot of people with questions I want to particularly highlight. Roy Dirks, my good friend at Get Hack team on Twitter, he says he's [00:34:00] curious about, how. Collaborations with other libraries and tech works. So there's no secret that the next GS team does heavy collaboration with the React team, but also does work with Chrome web vitals, for example. and Roy asks quite broadly, how does that collaboration work? What does that look like? What input do you have and vice versa. Tim: yeah, good question. So one of the things to, to mention here is React is, basically since last year when, Sebastian joined, Roel. and, someone else joined our team as well. Josh who had mentioned before, we was basically, we hired him to work on React as well as a contributor. Basically, since then, reactor become a multi-company collaboration. actually that's giving us too much credit, to be honest. there are other people on the React team that, that left Meta and kept contributing, which is pretty awesome to see as well. so that's like Brian, who works at Replay now. and Sophie, I'm not sure where she's working now, but Basically like they, they kept [00:35:00] contributing, and kept providing input on all the features, RFCs and all that. and then Sebastian joined for sale. one of the things here is that Sebastian had this vision of this is where we want to take, react and server components. and I believed in that vision, and so did, I love other folks at ce. and that's why we. Started collaborating there, and working on it. in the end, I looked back, right after release and it turned out that we spent exactly a year on working on this, just on Nexus features and all that. obviously scope increased over time, like in the end, we created next year, as we want it to be for the next five to 10 years. Instead of, building out like individual features for pages that, didn't fit together. It doesn't answer your question completely. the collaboration, we talk to them regularly obviously, we now have react contributors on the sell side as well. which makes like overall, it is been good, like really good to see the collaboration here cuz In the end, what we end up [00:36:00] doing. And like from our side, it's not like we're implementing this thing that NHA will use and we need to add this special snowflake thing that, that only Nexuses can use or anything like that. It's more like we have these general problems that all frameworks are run into with CER components and with, integrating, with React itself. Like React flow, for example. Where, like we, we need to solve these in order to make the broader ecosystem work, right? Like where Link Techs work and and all that. So we collaborate, with them quite heavily. but that's also because we wanted to make the server components, the goal of making Cerv combines reality, what was there from the start. Then for the Chrome team, it's a bit different, so they have a, Team called, Aurora team, which is a team within, the Chrome organization. historically, Chrome has been, what they said themselves is we haven't been collaborating with the overall ecosystem enough. So they basically had this problem [00:37:00] where they would ship features, try them over the, it's this classic, we, we built this thing. And now everyone has to adopt it. But how do we get this adoption when, you might not know about this, new feature, right? I dunno, an example being high priority, images for example, or, images with the loading attribute and things like that. that have a, like the features by themselves have a massive impact on the overall health of the web, but, In order to get them to be this impactful, you need to have this collaboration with frameworks and not just nexuses to get to a point where, you get large adoption. So what they saw is Nexus apps are used by, quite a lot of the, some of the largest sites in terms of traffic. and because of that, if they make a change to next year, for example, improve the bending. It can have a, larger impact on the overall, web as a whole. and similarly they're working with the Ang team obviously, cuz like [00:38:00] it's not just cuz they're, part of Google or anything like that. anger itself has a large, user base as well. the n team, who have been doing, awesome as well. And, this collaboration is We meet regularly. they're not like, we implemented this feature, can you please use it? it's more we're planning to do this thing. what do you think about it? we'd like your feedback on, on for example, like something that they just announced as baseline, and I don't know if you've heard of that, but it's basically a way, to say, This is the, set of browsers that if you support them, you should be fine. and this is like big problem overall on the web, right? my, my boss tells me to use i e nine. I saw an issue earlier this week of someone saying, Can you please add support for IE nine to App Rider? and React doesn't support that obviously and all that, because I need to ship this. Don't ask me why. and Tejas: Wow. Tim: the thing with Baseline is it's basically like a, collaboration between all the brass [00:39:00] vendors to say this is the, critical mass of. The browsers where, if it's, if the feature is part of baseline, it's now introduced in, the, MDN docs as well, it will say, okay, you can now use this cuz it's, implemented in enough browsers, or like enough versions of browsers to, to get to a point where I don't know, for example, async Await can be used, that's a bad example cuz that's been around for a while. But like some of the newer features, right? You're always struggling to be like, oh, what, when do I need to load the poly fill? Tejas: Yeah. Tim: this is where, this baseline initiative is, really interesting. Tejas: Yeah. Tim: and like, how does this interplay with, Nexus for example, Nexus would have to implement this baseline support to basically have a default browsers list, for example, that has baseline as the browsers for example. and that's the, that's part of the collaboration. Another thing is they spend a lot of time on script loading images, things that sound [00:40:00] simple and they're like, in practices are really not like they, they end up, messing up with like your core vitals and all that. and that's where they, they collaborate the most. Yeah. Tejas: Wow. Okay. Yeah. So something like this differ attribute on images or something like this or what was it like Loading equals lazy. There was, Tim: Yeah, it's like loading lazy is a, is an example, but there's another problem here, which is loading lazy on everything is bad. like your L C P will be wrong, will be, slower as well. so this is where it is, where frameworks can make a difference basically. Tejas: we are in the final few minutes, Tim. It's been an absolute pleasure. I'm sure not just I, think of that, but all the listeners, one final question, for you, and that is a very broad question, but I'm curious cuz you probably knee deep in this stuff, what are you, interested in, excited about these days in the ecosystem or even with next Js? Tim: obviously I'm gonna say up rider, but, the thing here is that, like I said, we've been working this for over a year now, and. One of the main things here is that it unlocks a lot of things in the [00:41:00] ecosystem. So what I'm excited about is what it is, not what we are going to do with it. It's what you are going to do with it. maybe the company you work for or some other, someone else in the ecosystem. I'm going to build a, like a layer, a data layer that is compatible with server components and like that allows you to. to fetch data in any component that's already possible, but has the, Cashing, heuristics, has the, the duping built in, has support for server actions, which we didn't even talk about. but the things I'm excited about is like seeing what people will do with this now that you have better primitives. I saw a tweet from someone that was like, I created a server component that's basically like MySQL admin, but with Prisma where you can create, it's a component that you give to Prisma instant, a server component you give from Prisma instant and it will visualize your whole database tables. I can't remember who it was exactly, and probably wouldn't be able to find it. But this is the thing that I'm excited about. It's People taking these, new component [00:42:00] primitives and building better components or better hooks or better, data fetching integrations. Tejas: That's, I'm also very excited about that and it's a real shame we didn't get to address server actions to truth be told, I could honestly hang out with you for 90 minutes, two or two hours talking about, but we are on a schedule, thank you Tim. I think we'll leave it here. Appreciate your time. Thanks for coming on the Pod Rocket podcast. Tim: Thank you.