Mark Dalgeish - AUDIO EDIT
===

Noel: [00:00:00] Hello and welcome to Pod Rocket Web Development Podcast, brought to you by Log Rocket. I'm Noel, and today we have Mark Dole developer on the React Router team here to talk about React router and react server components.

Welcome to the show, mark. How's it gone?

Mark: Good, good. Thanks for having me.

Noel: ~Of course, ~of course. Yeah. I'm,~ uh,~ I'm excited to chat today. ~there's, ~there's a lot going on here in React Router and Remix and all these recent changes and stuff. So ~I feel like, ~I feel like before we jump in, can we like kind of place where React server components ~kind of ~fit into the current React router,~ uh,~ like ecosystem or, ~you know, the, ~the blueprint for lack of a better term.

Mark: Yeah,~ so, uh. ~React Router has been, ~if you, ~if you merge the history of remix into React Router,~ um,~ has largely been solving, in many ways a lot of the same problems that RSC is trying to solve. ~Uh, ~which is things like how do you know what code to load when as you navigate around a website? ~Um, ~how do you know how to load data and,~ uh,~ on the server and pass that down to the client?

How do you deal with things like form submissions and so on? ~Um, ~and ~so. ~What's been tricky for Remix and now React Router is figuring out,~ well,~ how do we [00:01:00] merge these two worlds together? How do we take what the React team has been doing and what we've been doing and merge it into a cohesive whole? ~Um, ~so up to this point,~ uh,~ we've been ~sort of ~experimenting behind the scenes with what.

React server components looks like in the React router world. And we've just recently shipped,~ uh,~ our new preview of RSC data mode, which you can play with right now. So you can start experimenting with what RSC looks like in React router today. And we're also working on,~ uh,~ shipping that to framework mode consumers as well, which is our first class support for the framework level features,~ uh,~ through vet.

Noel: Nice. Yeah. ~Can can we, ~can we contextualize that just a little bit more for people that maybe aren't in the world? ~Like what, ~what are. Just conceptually, like what is data mode versus framework mode with React router.

Mark: Yeah. So in React router,~ uh,~ we have actually have three different,~ uh,~ modes that you can choose from. ~The, ~the simplest one ~is, ~is declarative mode, where it's really just components that decide what to render based on the URL ~um, ~data mode is really bringing that more framework level functionality. To,~ uh,~ react router [00:02:00] where you define your routes statically upfront, and all of your routes can have things like loaders and actions for controlling, ~you know, ~how to load data, how to manage form submissions, things that take it from being just a router that decides what you know, what to put on the screen, to much more of that full framework experience.

~Uh, ~what stops it short from being to me, of being something like a framework mode that we have is that,~ uh,~ it's not. Really integrated into a bundle ~or, ~or anything like that for you. If you want to do things like server rendering,~ um,~ and do data loading on the server and pass the results down to the client, that kind of thing.

It starts to require a bit more complicated interaction with the bundler and,~ um, you know, ~you can do that sort of thing yourself on top of data mode, but it gets quite tricky. So yeah, ~if you, ~if you want to just get the nice,~ uh,~ off the shelf solution,~ uh,~ using v then,~ uh,~ framework mode ~is, is ~is the solution for you there?

Noel: ~Gotcha. So if is, is, ~is framework mode ~basically kind of like, do, ~do you guys view it ~as, as just kind of ~as just kind of a more heavily opinionated data mode? ~Like, ~like wrapping data mode, or is that an inaccurate

Mark: ~Yeah, I mean, the way, the,~ the way I think about it for the average [00:03:00] app,~ um, you know, the, ~the way I think about it is that framework mode is. Just doing, it's doing the things that you can't do as a library ultimately. ~Like ~if you pull in a library from MPM ~and ~and start and use it in your app code in your.

V app that you've spun together,~ uh,~ you're gonna hit these problems straight away where it's like, I need to build for the server and the client and I need to communicate between these environments. And you can do it of course, manually yourself ~if, um,~ but it's not easy. And framework mode just means that, okay, now you've got a v plugin, you can stick in there and it knows how to manage these environments for you and how to communicate between them.

Noel: ~Gotcha. So then. Let's, I guess~ you mentioned that with RSCs, ~ you guys had kind of, you, you're the, ~the, the preview ~is, ~is currently targeting data mode. Could, can you still use them if one is in framework mode, but just like for specific use cases or ~how do, how do, ~how do RSCs kinda play into this?

Mark: So as of right now, you can't use RSCs in framework mode, and that's,~ um,~ something obviously people are asking for. Now that we've shipped some semblance of support for RSCs,~ um,~ I'm, I've been actively working like full-time on getting,~ uh,~ RSC support into framework [00:04:00] mode. And so that's the goal is that,~ um, you know, ~if you still want that off the shelf.

Solution that most people, I think,~ would,~ would go for, given the choice of these different modes,~ uh,~ RSC framework mode, is it,~ um,~ when that comes out, that's gonna be the way to go. ~Um, ~but ~if you, ~if you wanna get on that bleeding edge, then,~ uh,~ RSC data mode is available now. And ~what, ~what's really nice, ~I guess, is, ~is that.

~Uh, ~data mode,~ um,~ without RSCs,~ um,~ is a lot less powerful than what you get with RSC data mode because now with,~ uh,~ re the way react is leaning into,~ uh,~ itself, working with the Bundler, like you have to have an integration for SC for your given bundler, it means that. It's sort of native to react, having some knowledge of how the server and client parts of your application are linked to each other in the bundle and how they communicate.

And so if you look at an RSE data mode app, it actually looks very close to what a, a framework mode app looks like, that they're ~very, ~very similar. So ~that, ~that's what's been really nice for me is that it means that framework mode is becoming less of a custom [00:05:00] thing for us and more about leaning into.

~Um, ~the native RSC support from React and ~the, ~the support that V itself is getting as well.

Noel: ~Yeah, that, that's kind of, that's kind of where I wanted to take my questions next is because~ it feels like at some point if you're in like RSC with data mode, ~you're like,~ you're ~kind of ~using it like a framework. I'm air quoting framework a little bit already anyway. Like ~how, ~how is this going to differ?

When you guys get this migrated and ~like ~set up,~ um,~ for ~frame~ react router framework mode, ~like where, where is that? Um, I dunno how to frame this question exactly. Where, ~where is that delineation going to be in? Like what the framework is handling versus ~what I'm, ~what I'm thinking about as a developer, what I'm using RSCs.

Mark: Yeah. So if you are using,~ um, uh, ~RSC data mode today,~ uh,~ it can work, but you're still missing a lot of the niceties that you get from,~ um,~ something that's a bit more polished and presented as a framework. ~Um, ~for one thing, like configuring routes has a bit more boilerplate and doesn't support,~ um,~ file system routing.

~Um, ~that's something that you'll get in framework mode.

Noel: Sure.

Mark: ~Um, ~HMR ~uh, ~is something that we,~ um,~ make sure works,~ um,~ especially in,~ uh,~ the case where we have our own APIs on top of what's out in ~the, ~the stock standard [00:06:00] RSC beat setup that you might have.

Noel: ~Mm-hmm.~

Mark: ~Um. Uh, a ~a, a good example of an API that we've added on top is the route module API, where you can co-locate everything in the one file, even if it's on server and client, even in an RSC world,~ um, you know, we ~we're still maintaining that API, so for me, like, like.~ like, like.~

Maybe most importantly, the number one thing is that we are giving people,~ uh,~ the ability to migrate existing react router applications over to this world as well, because all of these,~ um,~ route module APIs, the loaders and actions and everything that we've presented before will still work as it did before, but with the additions of what RSC ~uh, ~brings to the table as well.

Noel: ~Yeah. Cool. Yeah, maybe, maybe we should, um, kind of establish. A little bit here. Again, especially for, for listeners that aren't in this world, in, in,~ in data mode in particular, ~like what,~ what are RSCs really enabling now ~that they weren't,~ that they weren't before? ~Like, ~what is the performance benefit here?

~Why, ~why did devs and consumers eventually care about this users?

Mark: Yeah. I think for me ~the ~the big thing that. ~Makes, ~makes me interested in server components is that it really provides a way to do, there's a couple of things that, that I personally find interesting. One is,~ it,~ it's a good way to get code out of the [00:07:00] browser bundles that doesn't need to be there. ~Um, ~that ~the, ~the best examples for developers,~ um,~ of where this pays off is something like a markdown react component where.

~Um, you know, you, ~you've got some code that's gonna pause, markdown and figure out, ~you know, ~I'm gonna render an H one and a PT tag and a link and so on. ~Um, ~and you've got all this heavy code that you need in order to calculate just a few react elements is ultimately the result of it. ~Um, ~in your traditional SSR React app, you have to send all of that markdown, pausing, logic.

You have to run it on the server first, of course, to do server-side rendering, but you also have to hydrate that entire app on the client. And all of that code has to go with it,~ uh,~ with server components. Something like that mean,~ uh,~ something like that can be sold very differently where it's ~like, ~I'm just gonna run my markdown, pasa only ever on the server, and then I'm just gonna send down the react elements that it calculated,~ um,~ as the result down to the browser.

Noel: ~Mm-hmm.~

Mark: ~Um, ~so that, that's really interesting. I think especially as someone who's worked in a lot of developer tools ~and our, ~and our developer tooling websites are often full of things like markdown components and code,~ um,~ snippets, like highlighting and things like

Noel: Parsers and all this [00:08:00] stuff. ~Yeah, yeah,~

Mark: Yeah, and it's ~like, ~let's get that all out of the browser.

We don't have to have these really heavy websites anymore. ~Um, ~and the other one, the other use case that's really interesting to me is when you've got UI that is not so strictly coupled to the URL. ~Um, ~so a really good example of this is something like the newsfeed in Facebook, funnily enough, which probably explains why so much of this is coming outta Facebook or people who used to work on it,~ um,~ where.

~You know, ~your newsfeed or my newsfeed might be really different depending on the sorts of content we are being presented. And, ~you know, ~that means that what the server can do is work out dynamically for each user. What UI do we need to send them? And then we'll only send them down the things we actually rendered.

~Um, ~whereas if you go for your more traditional,~ uh, you know, ~route based splitting like you've had in React router, ~um. You'll, ~you'll,~ um,~ it's very easy to ~sort of ~naive naively just bundle every potential component you might render on a page and have to send that down.

Noel: ~Mm-hmm. ~Which I think is~ is kind of the, ~has been the defacto for so long. It's hard to, it's hard to kinda get outta that mindset, I guess you, you mentioned there just traditional server side rendering and rehydration. ~Can, ~can we ~kind of ~go over that again? ~Like what, ~[00:09:00] what, why historically was that? ~Why, ~why did we have to send our whole like mark down pars?

~You know, to the, ~to the client. And ~why, like,~ why is that ~such a, ~such a bad thing?

Mark: ~Yeah. So the, the, ~the way that React worked when you would ~do ~do service side rendering is,~ um,~ the way I used to think about it when I was new to ~it was, ~it was almost like if you think of rendering in the browser as just like a series of frames in, in ~like ~a, in a, like a game engine or something. It's like you, the very first frame.

Was rendered on the server. All of the code that created that frame now also needs to be sent down to the browser to recreate it again. So it can start from frame one and then onwards. Everything from then on is running in the browser. ~Um, ~but ~there's no, ~there's no way to ~sort of ~say this part of the reactory,~ um,~ only runs on the server, and this only runs on the client.

~Um, ~it was all the same application. And so yeah, what that meant is that. ~If, ~if you wanted to do server rendering ~of, ~of anything, you still had to send that entire,~ um,~ all of the logic for that down to the browser.

Noel: ~Mm-hmm. ~That may be the cleanest explanation ~of, ~of SSR React, SSR that I've,~ uh,~ I've ever heard. So ~I ~I appreciate that. ~Um, how, how, I'm sorry. This, the backup alarm going off. Um, how does, uh, like, how, how do you kind of think about, I guess, how, ~how did your. Approach [00:10:00] to thinking about this, like RSCs, where to put them and how to get developers to ~kind of ~adopt them ~and, ~and get this into just like the developer headspace.

How have you ~kind of ~factored that into your guys' implementation and approach and,~ uh,~ like just, ~you know, ~wiring this up, is there, are there any decisions you guys have had to make there, or has it kind of just been like ~a, ~a process of going through and checking the boxes ~for, uh,~ for support here?

Mark: I think for me the main thing,~ uh,~ upfront is making sure that the overall architecture is still ~kind of ~the same. Like you've still got that same flow of when a request comes in, we match it to routes and we. Get all the data for those routes, and then we go to the rendering stage,~ um,~ even with server components.

~Um, ~and ~we've, ~we've made it so that you can incrementally adopt RSC features if and when you see fit.

Noel: ~Hmm.~

Mark: So even what I find really interesting about that is, is it means that as a consumer,~ uh,~ you can really start to play around with it,~ um,~ if you want to, but you can also be [00:11:00] completely. ~Uh, ~in this theoretical future where potentially ~we, we, ~we go all in on this as the default.

You might not even be aware that you're using RSC,~ uh,~ at all. ~Um, ~because the developer experience the code,~ um,~ that you're writing, that the, even the build output feels very similar to what you had before. ~Uh, ~you were using RS.

Noel: ~Yeah. Is, is there, is there a specific way I, like, I I, I think that a lot of, a lot of users who are kind of. Or developers who are in this headspace, that's, they kind of, they kind of see that vision as well. ~I'm curious about ~like, ~if you guys are thinking much about ~the, ~the devs who are like, maybe they're like more full stack, ~they don't spend a ton of time kinda like thinking about like~ they're not in this headspace much.

~Is there, ~is there a way you ~kind of. ~Recommend that they think about this. Like how proactive are they? ~Like ~would you recommend they be in thinking what they can have,~ uh, um, ~and trying to consider what they can put into a React server component? ~Is there, ~is there like ~a good, a good line like, um, maybe, you know, ~a good recommendation for how to look for ~like, ~candidate parts of your app that would be easy to move up,~ um,~ and get some of this work out of the browser.

Mark: ~Um, the, I mean, the thing is, I think ~for a lot of people, they don't actually see a clear benefit for moving to server components. So it's, ~you know, I, ~I think if you are saying to them, ~you know, ~take your standard framework mode app and then start thinking about what parts you want to move over to the server.

~Um. ~It might not be clear to them [00:12:00] when they Exactly, they should be doing that. ~Um, I, ~I think for someone like that who wants to think less about the architecture, it might make more sense to go,~ um,~ more all in on server components and make client components the exception.

Noel: Yeah.

Mark: In re in our RSC framework mode,~ uh,~ that we're working on at the moment,~ um,~ we have added an additional export to the route module API.

So right now you can export your component as your default component.

Noel: ~Hmm.~

Mark: that's implicitly a client component. ~Um, ~even though it's server rendered, it's in an RSC sense, it's a client component. ~Um, ~but now you can also optionally export a server component export instead. And that's your way of opting in a route to just be a server first route.

All the other APIs basically stay the same. ~Um, ~but it means now if you want to have,~ uh,~ client components, they need to be separate modules with use client directive, you import those. ~Um, ~so I think. I, ~you know, ~I've been so heads down on working on it. I haven't actually thought as much about how would I exactly recommend,~ uh, you know, ~different types of people adopt this.

But I think, I do think it makes sense that ~if, if you are, ~if you are interested in RSC to play around [00:13:00] with just going all in ~as the, ~as the default.

Noel: ~Yeah, so like, is that, if, I guess this is probably a good place to kind of jump into this. Like what, like what, what, ~how does that delineation actually work? So say, say, I guess our, our server like like a routes kind of ~the, ~the highest level entity where ~you can, guys, you guys can kind of, one can flip. ~One can flip this switch.

Is that like the top? ~Um, from, ~from the, ~you know, uh, ~data mode perspective in React router.

Mark: ~Yeah. So what ~what's really nice about this architecture is that you don't have to decide at an app level, am I gonna use RSC or not. It's more that,~ um,~ I, ~you know, ~the RSC, ~um. ~Mechanisms ~within React router, uh, sorry,~ within React are taking over some of the things we historically had to do ourselves as React router.

~Um, uh, ~so there is an architectural shift under the hood in terms of your sort of, might be swapping out one V plugin for another.

Noel: ~Mm-hmm.~

Mark: But in terms of,~ um,~ the way your, ~you know, ~your app is built, it's up to each route to decide is it gonna maintain the traditional client first route structure, which means it's backwards compatible, which is nice.

~Um, ~or you can say for this route I want to have a server component export. ~Um, ~or you can even have a sort of a hybrid approach, which is that your loaders and actions can just [00:14:00] return react elements from them as well as data. Which is effectively what I mean, that's, that was also probably the aha moment for me with server components was realizing ultimately it's just a way to send react elements over the network as data.

It's like the server has done its rendering, it's created ~some, ~some elements and it's ~like, I'm, ~I'm gonna send them over the network and the browser doesn't have to do any work. It's just got these things already.

Noel: Yeah,~ let's,~ let's talk a little bit more about,~ uh, like~ the ~loader, ~loader in action support, because I think ~that that, ~that is an interesting thing and I think, yeah, it's, it is ~kind of ~like a, it's,~ uh,~ revealing as a, like ~a, a, ~a developer using this kind of gets you into this headspace. ~Well, um, how, ~how does this actually manifest?

~Like if I, ~if I'm looking, ~you know, ~like at a React component or ~like, like what, ~like what, how am I instrumenting that to, to have it be sendable like, ~you know, as, ~as data ~over the. ~Over the wire like this versus what I, how I would traditionally have a component that I just import and use.

Mark: ~Um, ~if you render a component on the server you like, you can do it in your loader basically.

Noel: Gotcha.

Mark: ~So your, ~so your loader, ~you know, ~up until this point, your loader might have just [00:15:00] returned like a JavaScript object with some, ~you know, ~basic properties and like basic primitive values on its strings and numbers and arrays and whatever.

~Um, ~and now it's like you can just render a react element as part of that data structure as well.

Noel: ~Yeah. Are there good. Kind of back to my prior question, are there good, are there good components, which are typically, um,~ are there good components which are typically candidates for this? Like,~ when,~ when do you see something you're like, oh, ~I should, ~I should wire this up to be, ~you know, ~loadable,~ um, in, in this, in,~ in this mode versus traditionally.

Mark: I think either, like I was talking about before with ~um, you know, ~components that are really heavy computationally, but ultimately just render plain elements.

Noel: ~Mm-hmm.~

Mark: Markdown syntax highlighting, things like that are really good candidates. ~Um, ~the other one is when you've got parts of your app that are just static and they just sit there, excuse me,~ uh,~

Noel: Okay.

Mark: like maybe you've got ~a, ~a footer on a website with a lot of links in it and so on, and it's ~like, ~do I really need to send down all this JavaScript code for how to render that when I just, I could just send the markup down basically as react elements.

Noel: ~Yeah. Nice. Is there, um, is there, are there, uh, like particular concerns here? You, you grab some water or anything? We can, we~

Mark: ~Yeah, I might need to grab a~

Noel: ~Yeah. Go, go do your thing. No sweat. No sweat. Yeah. Yeah, yeah. I'm, I, I was, I was curious how, um, or if there are any like potential, um. I dunno, I feel like the, the word foot guns and the term foot guns is overused, but ~are there any potential,~ uh,~ pitfalls here that, that devs ~can kind of, ~can ~kind of ~fall into in tr trying to get into this mode?

~Um, ~do you think that'll be better or worse? ~Uh, you know, ~like ~with, ~with data mode versus framework mode, [00:16:00] how are you thinking about that?

Mark: I think the biggest pitfall with server components is that because you can now do your data fetching in the component itself,~ um,~ it's very easy to. Start doing like way too many,~ uh,~ database queries or API calls ~sort of ~separately. ~Like ~if you render a hundred different components, all of which need to hit an API,

Noel: ~Mm-hmm.~

Mark: ~you know, ~it's, it might not be obvious to you as you're building your application how bad that problem is getting.

Noel: ' Hmm. 

Mark: looking at it as, I'm just running a bunch of components and I'm gonna make my code clean, I'm gonna split it up and I'm gonna, ~you know, ~isolate everything to these components.

Noel: Right.

Mark: ~Um, ~whereas with the loader pattern, one thing I really like about it architecturally is it does force you to think about ~like, ~I need to hoist all of the data requirements for this route up to the top.

And there's a single place where I can ~kind of ~see everything that's being done. ~Um, ~and if I have to and if I can, if I'm gonna batch something, it's like that's my place to do it. ~Um, ~but yeah, so server components can make it really hard to be aware of how much you are. ~You know, ~hitting these,~ uh,~ APIs or database, or making database calls too much.

~Um, ~and that's why in [00:17:00] our RSC data mode demo that we,~ uh,~ shipped, we did show a really great example there of how you can batch,~ uh,~ API calls or database queries. Even across,~ like,~ as ~you know, ~if you're rendering lots and lots of different components, there's still,~ um, a, ~a mechanism there that you can use.

~Uh, it's all, ~it's all in user land though, which is really nice. Like it's using our new,~ uh,~ middleware, API, to ~sort of, um, ~to provide these batch load of load functions to all of the different,~ uh,~ components. ~Um, ~but. Ultimately it's just using,~ uh,~ standard node APIs for managing, like scoping of those things to each request.

Noel: ~Nice. Okay. You kind of, you kind of threw, threw a lot at me there. So I wanna, I wanna talk about the middle. Like, ~let's talk about the middleware a little bit more. Ab abstractly first. ~Like, ~like ~what, what is, ~what is that middleware API, what can it do? ~Like what's it, ~what's it in charge of? What's the abstraction?

Do.

Mark: Yeah, middleware is something that people were asking for for a long time and like a really good example of where you,~ uh,~ really feel the need for middleware is something like authentication

~where. You know, ~you don't wanna have to authenticate at every single loader. You would ~kind of ~want to,~ um,~ have an architecture where it's more like upfront, ~you know, ~we check you [00:18:00] at the door,~ um,~ we figure out everything we need at that point, and then the loaders run and they all,~ uh,~ are able to have access to any data that, that middleware,~ um,~ set up as well. And that's what we are using,~ uh,~ for the batching mechanism in our demo, where basically what we're doing is we're saying. ~Um, ~because the middleware ~has, ~has access to that scope of the request. It's like we know we, it, we call the middleware before we've run any of the loaders and done any rendering. And then,~ um,~ that you can also hook into the end of that and know, okay, we've finished rendering and we are done.

So we've, you're picking it up on the way out as well. And because you have. That touchpoint in the code for, ~you know, ~before we've done anything and after we've done everything in terms of loading and rendering,~ um,~ that allows us to use,~ uh, to, to, ~to scope,~ um,~ any batching,~ uh,~ functions that you have,~ uh,~ any batch like load functions to the entirety of that request.

Noel: Gotcha. So ~is is, ~is the middleware pipeline E executed once per request? ~Is that, ~is that essentially how it goes? Gotcha. Cool. ~Is so, is that, is that like, I guess I'm kinda, ~I wanna delineate between what ~the, ~the data, ~this kind of data, um, data batch. ~Batching [00:19:00] used case is versus what middleware can do, like more abstractly.

~So you talked about like that authentication piece there is, is that, is that, is that like ~authentication in that world is still ~like, ~in my head, ~kind of like ~a, ~you know, ~like a data fetching like problem, like there's like a ~who, ~who is this person? ~How do I, ~how do I determine who they are? ~Are tho are, ~are those the kinds of problems that middleware has really been leveraged to solve?

~Is that what you~

Mark: ~Yeah, it's, it's just trying to, it's,~ it's really trying to solve anything that people would naturally be duplicating in all of their loaders. ~Um, and, ~and instead want to just handle it up top for the entirety of ~the, ~the request.

Noel: Yeah. ~And, and, ~and you mentioned that~ it, it is, um. The,~ this like data batching thing is more in user land. ~Do you not, ~do you not view middleware ~kind of ~as user land? ~Is that, ~is that something that you guys don't want ~to have ~to have devs worrying about that much and you think should be handled by kinda like the framework or the tool chain somewhere else?

For the most part,

Mark: It's definitely our ~ uh,~ that we want to try and keep the API as small as possible,~ um,~ and don't add too many things that.

Noel: ~yeah.~

Mark: If they can be done relatively easily in Newland. ~Um, ~and I do think this example of,~ uh,~ setting up, ~you know, ~special data loading functions that are batched ~for the, ~for the request,

Noel: Yeah.

Mark: it's, that's a really good example of where we could [00:20:00] go that extra mile and start to bake that into the framework.

But that just balloons up the surface area of our API. Just to save you a tiny bit of boilerplate, whereas it,~ I,~ I actually do like it this other way where it's quite clear, ~you know, ~how much of this is framework knowledge that you have to have versus ~like, ~you can really hook up any sort of library you want at this point when you're not bound to whatever we decide is the best pattern.

Noel: Yeah. I guess ~kind of ~from a. Like ~at a, at a, ~at a higher level then how has this kind of react, react 19 overall shifted your thinking about what React routers responsibilities are ~like, ~like how has that kind of, the landscape changed wherein like ~your, ~your, ~this is, ~this is definitely react routers job versus, ~you know, ~reacts or the framework's job.

Mark: Yeah, I mean my, most of my work on React Router has been around the bundling side of things, ~and so that's, ~that's definitely the perspective I'm looking at it from. ~Um, you know, ~that's not all that React 19 is doing, obviously, but,~ uh,~ I think what it does for us is it allows us to think more about targeting,~ uh,~ server components and [00:21:00] like those APIs rather than having to invent a whole bunch of custom things.

Noel: Yeah.

Mark: ~Uh, ~why that's important to me is it means that it's much more feasible for us to support other bundlers. 

Noel: ~Hmm. ~

Mark: ~know, ~our framework mode is only on vi

Noel: Right.

Mark: and theoretically we could support other bundlers, but it's just a ton of work,~ uh,~ especially when you think about all of the edge cases and things we have to handle.

~Um, it's, ~it's,~ um,~ it's hard enough just supporting one bundler basically.

Noel: ~Mm-hmm.~

Mark: But I think RSE actually changes that relationship a bit for me. ~Uh, ~because like our RSE data mode,~ uh,~ demo ~that we, uh,~ that we showed people,~ um,~ was actually built on top of parcel,~ uh,~ parcel was the first time for me that I'd seen,~ um, uh, ~like an R-S-E-A-P-I at the bundler level that really clicked and made it clear like you could build a library on top of these APIs.

So it's ~like, ~it feels closer to what React Router felt like previously as a library where it's ~like, ~I've set up my bundler and now I'm pulling in React Router and I'm just calling React router functions in my app.

Noel: Yeah.

Mark: is that my app has an RSC environment as [00:22:00] well as an SSR ~and, ~and client environment.

Noel: Yep.

Mark: but the, ~you know, ~the bundle is managing that for me.

Noel: ~Yeah. Has, has that been, has that been,~ I keep kinda ~asking, ~asking these questions that are more like in developer's relationship with these tools, but ~I, I feel like, I think this is curious or~ I'm curious about this because I feel like ~this is all, ~this is all kind of changing, like the optics are weird.

~Have, have you found that, that, that kind of like. ~The understanding of this is just being a, like a pluggable piece. ~Are, are,~ is that clicking with developers? ~Like ~are people perceptive to that or ~is it, ~is it something that like people are just so used to not even thinking about anymore that you guys are really having to be like,~ like,~ this is the goal here, like ~this is, ~this is our vision.

Mark: Yeah, that's a good question. ~I, ~I think. for the better. The average developer isn't as aware of this stuff and doesn't need to be. ~Um, you know, that's, that's, ~that's why things like,~ uh, you know, ~more the framework style,~ uh,~ solutions ~I, I ~I've become more and more popular is because you don't have to think about these things.

~Um, you know, ~I just grab this thing off the shelf and it's already solved the hardest problems for me. I can just build my app. ~Um, ~so yeah, I think this is probably more,~ uh,~ for ~people who are. Like people,~ the kind of person who would listen to this, right? Like enthusiasts,~ uh,~ who are interested in what's going on under the hood of maybe a bit more as well.

~Um, ~I think if you are making decisions about, ~you know, ~how to build your application today ~and, ~[00:23:00] and ~you know, ~what the future might be for ~the, ~the tech choices that you'll making, the way I think about this is it means that it's making,~ uh,~ react router more of a safe bet. I think because it's. Now you're not as coupled to a particular bundler.

And as we've seen with ~like ~the shift, the big shift that happened from webpac to V as ~kind of ~being the default choice in the react space,~ um, if, ~if you're choosing your own bundler,~ uh,~ this put puts us in a much better spot to be able to move to something else if the community was to ever shift again.

~Um, or it makes it,~ it also means that you feel more confident that if. The framework mode solutions,~ um,~ aren't working for you. ~Uh, ~for whatever reason, you can drop down a layer to the RSC data mode, and that is not coupled to any particular bundler. ~So, you know, ~if you're using something else,~ uh,~ you can just go straight to the RSC data mode and wire that up yourself.

Noel: ~Yeah. It like, I feel like as we, as we talk about this, it's kind of, ~I feel like we're painting this picture wherein ~like there's the dev, like ~a dev in an environment where they are choosing their own bundler feels like almost more a, an important delineation than ~is like, ~are you a dev who's all in on a particular framework?

~Because like, like that, that really feels like the optics of what. Like the, the two, ~the two theoretical users that we keep standing up, ~like are those, ~are those two people? So ~with, ~with ~React router kind of being used as more, or being like ~React router, having the [00:24:00] capacity to be used as ~kind of a, ~a library, again, it's bundler agnostic.

~Um, ~does it ~kind of ~change your long-term? Vision for ~like the, ~the project ~are, ~are you thinking about that differently at all? Like how you fit in, how you interact with the, ~you know, ~the other devs working on ~different, ~different layers ~of, ~of this, ~you know, the web, ~web app ecosystem.

Mark: I think it, it definitely changes where features might need to be implemented. ~Um, ~because, ~you know, ~previously it was like, if anything,~ uh, if, ~if any feature relied on the BUNDLER in any way, it had to be in framework mode and that was it. Whereas now it's ~like, ~okay, is this more of just ~like, um, ~something that could work at runtime with RSC.

~Uh, ~and it doesn't need any special bundler integrations Beyond that, then that can live in ISC data mode. And so that means that we are much more incentivized to say, okay, let's not try to add too many of our own custom framework isms on top of, we can avoid it and if we can implement it at the lower level,~ um,~ where it feels more like a library, let's do that.

And so that,~ that's,~ that's I think making the library a lot better in the future. ~The, ~the more we can do that.

Noel: Do you think a lot of [00:25:00] this has ~kind of ~been just enabled? By there being a performance necessity, like there being a functional reason to have another,~ um,~ like runtime that exists ~kind of in, in, ~in, on the server essentially. So it's like before it was always like, we have these things we build. Then we spit that out.

But like again, we were building a lot of that functionality into the Bundler. ~Like as you was like, okay, we'll do this in the bundler step,~ but now it's ~like, well, ~we've determined that there are performance gains. If we actually have ~like ~another place where code can execute and ~there's like, you know, ~like the devs are thinking about it.

So then it seems like a lot of the functionality we've determined that, okay, we can ~kind of ~do this in this like. ~You know, ~react server, component layer. There, there is another place where we are doing logic that we are ~kind of ~cognizant of. The end user developer is thinking about it. ~Like, ~do you think ~that ~that was ~kind of ~the key that unlocked that?

~Or, ~or is there, was there another, ~you know, kind of ~mindset shift that you think really ~drove, ~drove the capacity to have React router just, ~you know, ~able to be leveraged ~in this, ~in this way?

Mark: ~Um, ~I think for me, like the, what I've found when using the new RSC stuff that we're working on. It's actually not too different conceptually from where [00:26:00] we've been before. Like you're talking about the,~ like,~ there's an extra environment, but I think in practice it's almost like I'm thinking about server and client when it comes to things like,~ um,~ data fetching and rendering server components.

~Um. ~So there is still that separation of server and client, but it's, I feel like ~that ~that SSR environment in the middle is much less important now. Like I'm not really thinking about that one as much because it's almost more ~like ~that's just a pre rendering layer in the middle. ~It's just, ~it's just an optimization almost to say, let's take ~the, ~the fully resolve, like reactory, including client components and let's just spit out HTML for that.

Noel: ~Mm-hmm.~

Mark: And that's ~kind of, ~its only job. ~Um, ~in terms of thinking about server versus client, I feel like I'm still roughly only doing about the,~ like,~ I'm still thinking about it roughly the same way. ~Um, ~and to that point, I think like in terms of my own journey towards becoming more interested in server components,~ um,~ one thing that really helped me get on board was seeing that.

Like the Bundler could spit it out as a single,~ uh, like ~build artifact single,~ uh,~ server. Because I think when I first looked at RSEI mistakenly thought, because you talk about the [00:27:00] SSR server and the RSE server, I thought it meant I have my actual ~like, um, you know, ~infrastructure has to be different at runtime.

~Um, ~but that's not the case. ~Um, ~you know what, I really loved playing around with our first experiences playing around with,~ uh,~ parcel. Was it ultimately still just spits out a single node server, and so ~that ~that was like, oh, I can literally just ship the way I was shipping the day before if I was using more standard,~ uh,~ SSR setup, except now I get all the benefits of RSC.

And it's ~like, ~if that's the, if that's the way it's shaking out where I don't even have to really change how I'm deploying my app or anything like that, it's like, why not start leveraging these features if it's really that simple?

Noel: ~Yeah. Yeah. I, I agree. It's, it's an interesting thing 'cause yeah, like. I dunno, just the, the kind of, um,~ the ecosystem journey is maybe like the term I would use, like ~how we, ~how we've wound up ~in this, ~in this world where ~it's like, okay, we can do, we have,~ we can have like explicit data fetching and stuff as this kind of ~like, you know, ~first class citizen.

~Um, ~but then everyone realizing ~like, ~maybe we don't actually need to think about it that much. As long as we're like cognizant of it happening, we ~kind of ~put some boundaries on things and then ~like ~everything will just click. ~Um. So like, it's, it's, uh, I dunno, it's,~ it's been an interesting journey over the past few years, kinda ~kind of ~seeing this ~all, ~all come [00:28:00] together.

~Do, ~do you think that this is really ~gonna, ~gonna catch on you? You mentioned before that you're hopeful that ~like ~this'll be ~the, you know, kind of ~the default mode in the future, ~or it'll be, become so. Just that ~that membrane will become so thin that it's not really a thing that has to be thought about much.

Are you optimistic? Are you seeing that happen already or~ do you think it's like, ~are you ~kind of ~just predicting it will happen in the future?

Mark: ~I, ~I think we're on a natural journey towards,~ uh, you know, ~RSE, just being the natural way, that framework level. ~Uh, you know, ~react Tooling works. ~Um, ~and ~you know, ~I can see a future state where with React router, there is no, ~you know, ~do I choose RSC or don't I? It's more because like I said, if the build output is still the same as it was before,~ like, and, ~and also I should be, I didn't even touch on the fact that RSCs don't, that the naming's a little confusing in the sense that you don't have to have a server with React server components.

~Um, ~because ~you can, ~you can generate these RSC payloads at build

Noel: you can do it.

Mark: 'em on disc. Yeah. And then you can just have a static site that's just serving up RSC payloads,~ um,~ which is mind bending. ~Like ~that's, again, it's another thing that's made me like, once you start to realize ~these, ~these things,~ um,~ about RSC, that it's ~like, ~okay, my build output doesn't need to change.

I [00:29:00] don't even have to run a server if I don't want to. ~Um, ~I think the arguments against using it start to get smaller and smaller. ~Uh, ~for me ~the, ~the big concern early on was just whether there's gonna be good enough support for it. Because it felt ~like, you know, ~obviously you're getting first class support ~in, ~in next js ~uh, ~the framework, but then it's ~like ~if you are doing your own thing in a different bundler, it felt like people were still ~sort of.~

Just experimenting with it rather than shipping real Polish solutions. But ~it's, ~it's been a, it's been a while now since I, ~you know, ~I had those concerns and I think that the tide's definitely starting to turn and,~ um, you know, ~we are building on top of the official RSCV plugin that's being worked on right now.

~Um, so, you know, it's, ~it's not just some experiment at that level. It's like we're building on top of what is supposed to be the RSE solution for V. So ~it's, ~it's a very different place that we're in now there as well.

Noel: ~Yeah. Yeah. I feel like we could, ~we could go down ~a whole, ~a whole nother rabbit hole on ~like, you know, if you're,~ if one ~is, is, ~is writing ~a, ~a static site with,~ uh,~ RSC, like the concept of what the bundler is doing,~ like,~ and like that build time delineation versus runtime donation, it starts to get~ very, uh,~ very mind bendy very quickly.

~It's like, well, ~maybe. ~Like, ~we could just use RSC for everything at the top level [00:30:00] and then ~like, ~do I even need to think about a bundler in the traditional sense anymore? But anyway, that's probably ~a, ~a, an episode for another ~day. Um, I think we're, ~we've covered quite a bit here. ~Uh, ~I wanna transition us into our little lightning round, one or two sentence responses.

I've got a handful for you, mark. Can we jump in?

Mark: Sure.

Noel: Cool. ~Um, ~what's one thing that RSC enabled that surprises you?

Mark: That surprises me. I think,~ uh,~ the fact that you can do it at build time was probably the most surprising thing to me. ~Um, you know, ~it's not new to me now, but at the time I was like, ~you know, ~oh wow, that really changes how I think about what server components are.

Noel: ~yeah, yeah. As we, as we just said, um, we may have covered this already, but~ what do you think the biggest pitfall is,~ um,~ when you've seen developers try RSC with the React router?

Mark: ~Yeah, um,~ putting too many individual like database queries or API calls into your components, and then just rendering them like crazy and having no idea how much ~your, uh, your, ~your app is no longer very optimized in that regard.

Noel: ~Hmm. Is there any one thing about the um, um, RSC ecosystem or maybe the spec itself that you could change that like you wish we'd had a little, or there'd been a little bit more foresight on I.~

Mark: ~Oh, that's a good question. Um, yeah, I'm not sure I have a good answer to that one.~

Noel: ~It's a hard one. Yeah. You one doesn't wanna be over opinionated and~

Mark: ~Yeah.~

Noel: ~yeah. Put your foot in your mouth. I understand. Um, let's see.~ What's a,~ uh,~ subtle but important technical decision,~ um,~ in this kind of the RSC integration that you guys have done, that you've been especially proud of?

Mark: ~Uh, ~a really subtle thing I think is that your route [00:31:00] configuration is now done at runtime. It's kind, ~kind of ~hard to explain, but,~ um,~ like in our framework mode, you have a routes ts file, which configures your routes in code.

Noel: ~Hmm.~

Mark: And people have been a big fan of that. And,~ um,~ you basically have the same pattern in RSC where ~you have a route, uh, your, ~your routes are just a data structure at runtime.

And so what's really nice about that as well is it means that,~ um,~ about ~that, ~that architecture is that our framework mode, ~uh. Uh, ~when it comes to generating the route config, it's really just basically mapping the code you wrote into this,~ um,~ runtime format that works in RSC. Uh, kind of hard to explain, but it's,~ uh, it's, ~it's ~really, ~really elegant,~ um, for, ~for us in terms of maintaining a framework.

Noel: Yeah, a lot of those, a lot of the really,~ uh,~ elegant or performing, the things we're always proud of as devs are like, I can't explain this in less than 15 minutes, but ~like, believe me, ~believe me,~ it's,~ it's great. Yeah. ~Um, ~cool. How does this,~ um,~ return to a kind library, like library first approach, influence, react router design?

Mark: ~Uh, ~it means that React router can still stay from a developer experience perspective, can still stay at this high level. Of being a framework, but by [00:32:00] targeting RSC and RSC enabled bundlers, it means we can bring more of those features,~ uh,~ to a broader audience of not just v or not just whatever bundler we've picked.

~Um, ~but it means we can think of ourselves more again as a library whilst still supporting these more full stack features that you expect from a framework.

Noel: ~Nice. Cool. Cool. I feel like that's as good of as good a note to end on, uh, as any,~ is there anything else you wanted to ~touch on, ~touch on quick mark that ~we didn't, ~we didn't have time to delve into at all?

Mark: ~Uh, well, ~I think the big thing I wanna stress is ~if, you know, ~if you're listening to this, you've come this far and you're interested,~ um,~ definitely do jump in and start playing around with these,~ uh, you know, ~releases that we're shipping. ~Uh, ~because I think the difference between this being. The fun new thing versus ~like ~what we've talked about where it becomes the new default.

~Uh, ~it's really just gonna take usage to get there. ~Um, ~so the more eyes we have on it, the better. And I'd love to hear,~ uh,~ what you think about it. And also ~of, ~of course, big shout out to, ~you know, ~the team,~ the,~ the rest of the team for working on this as well. 'cause obviously not just me,~ um, you know, ~Jacob in particular on our team, he's the one who really pioneered this work.

~Um, ~he's the one who really blew my mind in terms of how you could get React router,~ uh,~ as it exists today as a framework [00:33:00] to run on top of RSC. ~Like, ~it's just completely broke my brain. ~Um, ~and since then I've been really enjoying,~ like,~ taking his work and trying to figure out ~like, ~okay, how do we get this thing,~ uh,~ to a point where we can get it in everybody's hands?

So yeah, big shout out to the team.

Noel: ~Nice. Cool. Well, thank you.~ Thank you so much for taking some time and letting me,~ uh,~ letting me pick your brain, mark. It's been a pleasure.

Mark: Yeah, thanks so much for having me.

Noel: ~course. ~