React Server Components with Sanket Sahu === [00:00:00] hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session reply, error tracking, and product analytics. Try it free at logrocket. com. I'm Sean. And today we have Sanket Sahu, founder of GeekyAnts, creator of NativeBase, BuilderX, and GlueStack. And here today to talk about React server components. Welcome to the podcast, Sanket. Hey sean how is it going on? Yeah, it's going well. Thanks for joining us. We're really excited to have you. And before we dive straight into serving components do you mind just telling our listeners a little bit about your background and experience with web development? There's a lot of names to mention uh, things you founded. Yes first of all, thank you so much for having me on the show, sean so a little bit about me. I'm sanket. i'm based out of bangalore I started my coding journey very early. Qbasic was my first coding language And I used to do cli back then we didn't have any nice, graphical user interface either And slowly, yeah, I got into C, C all the way jumped to web development.[00:01:00] And with all these I entered the world of React and then React Native with React Native, we had the first contribution of open source that is native base. It's a UI component library for React Native and also works on web. All these was happening with a company that I founded it's called Geeky Ants. We are. An I. T. Services company with a lot of activities around open source and react native and also communities. I get to speak at conferences in the same ecosystem. And yeah, these days, I'm building glue stack, which is a full stack and universal framework uses. React Native and Node. js in the backend. So yeah, that is what I'm up to these days. Sean, yeah. Awesome. And do you use React server components at GlueStack or is that something that you've gotten interested in on the side? So we are building the next version of GlueStack. The v1 was internal. And for v2, we have considered using it. We... [00:02:00] started off with Next. js and it comes with Next. js 13 plus, I think 13. 4. And yeah. So right now it's available as a part of the entire ecosystem inside Next. js, which is a part of glue stack altogether. But at some point when we probably switch Next. js to something else, we'll have to probably redo that and start building the same thing inside glue stack too. So yeah, we are experimenting with it right now. Not officially a part of it, but. Since we have a lot of dependencies on the cross platform UI library and the support of that is somewhat here and there That's why we are still experimenting with it. Yes. Got it. Makes sense. And I guess now would be a good time to back up because I think most people know what React server components are by now, but do you mind just giving a brief explanation of what they are and why devs might want to use them? Yes for sure. So react Is a ui component library and then we saw react going to the server in the form of server [00:03:00] side rendering at some point When we had meta frameworks like next. js and others came in but the paradigm was We could do render react in the server per on one route basis which was good if you want to like completely navigate from page one to page two but if you would like to do a partial rendering then you would essentially Like to use something like Server components. And that's not the only thing that it comes with. It also renders everything on the server and does not essentially ship the JS bundle on the front end. So essentially we get like zero bundle size. And when you are rendering react on the server and not doing the hydration part and not, in fact, bringing in the bundle on the front end, you're free to do a lot of server related things. You can do API keys, you can do DB interaction and use it much like an MVC sort of framework in [00:04:00] some sense. Got it. Okay. We've had the server side rendering in the past with earlier versions of Next. And I guess from my understanding is the difference that those will ship, the HTML to the browser, but they still have to then ship the React to the browser as well. And there's this hydration step. So how do React server components avoid doing that? React server components is like just shipping HTML and nothing else. So you lose on the interactivity part and. Essentially, if you're not shipping any JavaScript and the hydration is not happening, it's plain string. And the string is just dropped into inside your DOM and attached to it. So you lose some you get all the benefits of doing everything on the server. But you can also mix and match, like you can use a client component where you need interaction. Yeah, say consider you have a landing page or a blog page. You might need interaction ads Just maybe the comment box and not everywhere else so [00:05:00] you would Use a client component at your comment box and the submit button And then that would fire an api call and save it do the things on the server and bring it back but the rest of the page essentially does not Ship any JavaScript at all, which makes it really fast. And say if your blog is using Markdown, for example, before React server components, we had the Markdown renderer, which was happening on the server and the entire, say a hundred. KB of the render was also shipping to the front end, which was essentially not good. So you get best of both worlds, and you can mix and match, that's the best part about RSEs. Okay. Yeah, that does sound quite convenient. And you've mapped out the timeline of RCs from conception to today. Could you tell us a little bit about. The conception of Rack server components and what were they originally intended to accomplish? Yeah, I think many companies are doing something like server driven UI. The first one that I came [00:06:00] across was LinkedIn, when they had to build UI on their mobile apps, and they had their own JSON format, which would be read by the mobile client and would render things on the screen. So with mobile apps, it, at some point it becomes essential to drive a part of your app from your server without updating your entire bundle. And even at Facebook I heard somebody talk about at React Summit just last month. That the origin of RSEs was into one of the React Native apps or maybe the native apps where they were rendering things on the mobile through a JSON that was shipped from the server. And it also makes sense to use the same thing on the web as well. So it starts from there, the concept of doing dynamic things without updating the user's code base or the bundle that is shipped. And then, yeah, you can do a lot of things from there. Nice. Yeah, that, that makes [00:07:00] sense that the server code is easier to update versus, having someone update their app, especially if not everyone has automatic app updates turned on to update the UI. And yeah, I can see how the other conveniences fall out of that of being able to talk to the server and the database and just write in the component. Yeah. And mobile apps are more of like offline first and they don't just so you would essentially do OTAs and then implement that, but yeah, before OTAs was a thing, I think different companies were doing it with a JSON server driven API sort of thing. Gotcha. Do you mind explaining what an ODA is? OTA is updating the user's Apps without them actually updating it. So if you have to push an update to your apps on mobile apps app store and play store. It goes via the screening process of apple and google if you want to skip all that and maybe just say [00:08:00] Update some basic things like some typo and say some color changes here and there which essentially doesn't change the entire app but fixes things which even apple and google are okay with so you would essentially put a script that updates a part of your app and that happens all by itself whenever your mobile app gets an internet connection. It checks for updates and then dynamically updates that for you. Got it. Interesting. It's cool that like these sort of solutions, including Rack server components, start out to solve problems that large companies face. And now a few years later, everyone's getting them and it's improving developer productivity and development experience in lots of different ways. And now Next. js has announced the stable release of their app router, which is using Rack server components. So I guess, what do you, what does that mean that, what does it mean for next to implement RSCs into their own framework? Does that basically mean that they've really taken on or is it in a spot where we can all start using them confidently?[00:09:00] In some ways, yes, though it's not a complete yes, I would say because It was an obvious step for for any meta framework like Next. js. Because before RSCs, React was only on the front end. And if you want to do RSC and make a part of your app render on the server and a part of it render on the client and mix and match down the tree you can't do it with a front end only library. You have to use something on the back end. And that's where Next and Vercel come in. They make sure that it happens smoothly without spoiling the DX and that, that has been there. USB you just build stuff and then it takes care of what runs there, which is nice. And essentially that also makes Next. js more full stack because React itself is front end and Next. js with its API routes and the edge functions and all those things they were moving towards full stack at some point. And with RC, it becomes like even natural, the process, the [00:10:00] transition becomes very natural. Yeah it makes total sense for them to make that step, like you said, because they're already, their focus was already on all of the edge. Compute stuff which would just benefit even more from having server components. And I think it's interesting to see how the Next and React teams have now started to work so closely together. Do you see that continuing in the future? Actually the React? Documentation now just recommends going straight to next. js instead of using create react app, which I found was really interesting Yeah, what do you think about that relationship? Uh, I think it's there are mixed reaction in the community because you can see the responses coming in on Twitter in different forms. Though most of them are like really positive and there's a reason to it because next is driven by Vercel, which. Essentially has hosting and next plus three, I gives you the front end and everything. So for innovation. [00:11:00] That partnership is essential because when, as Dan said, when Sebastian made the move from React core team to Vercel, he saw the future of React. It was moving in that direction. And that partnership becomes very essential there. And even a no brainer and the next step for React to go full stack. That's that, that's really good. But on the other side there were some comments on Twitter talking about now React is being driven by Vercel and. At RemixConf, Dan had to, in fact, take this question and answer it to the panel saying that it's not the case. Most of the ideas are, and the decisions are driven by the React core team and Next are helping to implement that. So yeah, so that partnership is like the path to innovation, I would say excluding The things that people are talking about, I think those will fade away because, and as more frameworks and more companies other than Vercel altogether [00:12:00] implements RSCs into their frameworks and technologies, and even like the hosting solutions, it would become even more evident because right now it's just one company and as many companies start doing it it becomes very obvious that, okay, this is the next step. Got it Do you feel like in order to take advantage of react server components? You have to use one of these meta frameworks Is it possible? Or I guess feasible to just implement them into your app yourself or is that kind of is the barrier to entry too high to do that? I asked this question, I asked the same question to Dan do we have a documentation of how we can use or build our own React server components outside of Next. js? And he wrote a very nice GitHub post, wherein he detailed down how we can go from the source code and then write plugins that identifies, different parts, like the directives of use server and use client and how those can be like moved to a bundle of the server and it's not shipped [00:13:00] to the client and you can somehow build RSCs. It's not easy. It's very difficult. And but I see that happening because people. Big companies, even other companies, they want that freedom not to be logged into a particular vendor and I was speaking to Tejas about the same thing. He was a co speaker at React Nexus that happened last week In fact, he implemented the entire blog post that Dan had proposed and he could run a basic version of RSC in the experiment and his talk was all about that So it's possible. He's just one individual who could do it Obviously, it was just a POC when you go full blown with a framework, there are edge cases that needs a team not just one, maybe a team of 10 or 15 people but it's not as easy as it was with building a, say, a route based or file system based Next. js framework. Now it's like even harder and it's going to be more difficult in the future with next server actions, for [00:14:00] example. And things like that. Only future is going to tell us like where it heads. It's going to be difficult for sure. But if that's an open source project, and we have an equivalent, something like builder output API of next that helps us with deployment, essentially we would get to a point that it becomes more open source in terms of hosting as well. Got it. Yeah, I'm excited to see what people do with it going forward if we have more projects similar to Next. And I guess in the meantime we do still have Next. js in the app router, which is pretty convenient to use. You mentioned the server actions, but I wasn't familiar with those yet. Do you, is that related to React server components or is that kind of related to Vercel's edge compute strategy? It's both so with react server server actions you can call a server action. As if it was a local function, local async function. So what it does is say if there's a function that runs only on the server and that talks to the database, but you have a client component that needs the data. [00:15:00] So client component can make a call to that function on the server and get the data and you can render things on the screen inside the client component. Before this, you would have to create an API route and then use fetch to get the data out of it. But now with next server actions, you would essentially call them as if it was your local function in the same file. It essentially puts them into two different environments altogether. And it feels like you're calling a local function, but it gets called on the server through the entire API route. Got it. Okay. Yeah. How do you feel about I guess that, that fact and just in general that now components are server components by default and data fetching. Will happen on the server securely by default is that is that a better paradigm you do find it's easier to think in that way when developing apps I think that's that's the. Mindset that I have because I come from a PHP background. [00:16:00] So I have all like I have a lot of experience in building server driven pages So the default nature is obviously the server driven like something very similar to making RSC default the default from the server side so and we can't even make it client component at the root level because you cannot use a server component inside a client component. So Having that as default is a good strategy that also keeps enforces the developers to make sure they're not shipping anything extra that is not needed. And then opt in for interactivity, opt in for the like front end features of react only when they need it. So that, that Linting on or enforcement is really good. And there's also, this was made famous with Astro. Astro at its core is like server driven and wherever you want to add interactivity, you would, they call it islands. So it's that mind map like Astro pages and Astro [00:17:00] islands is same as like React server components on the route and React client components. So that paradigm is a pretty straightforward mental model, I would say. got it. Yeah. Another way that I've seen to think about it is try to push the client components out to the leaves of the like component tree. So I guess in your example, like that you gave earlier, the comment box. So maybe like the page and like the parent components are like server. And then like way down in the leaf node of the component tree, you have what you have a client component comment box, which I guess maybe you could in that other way of thinking would be like an island of interactivity. I don't know which I like better. Yeah. Yeah. That's what Astro guys call it. So yeah. Makes sense. So I think there's also been, I think you, you mentioned there was some tweeting, but there's been some legitimate criticism I think of RSCs in terms of breaking libraries like Apollo and I believe causing some issues [00:18:00] for Redux. What are some other issues that you see in, and do you think? These are just very temporary as the community builds around React server components. Yeah, how do you feel about the, how fast it was, it's been introduced and whether those kinds of issues are a problem. Yeah. I think the criticism, I wouldn't a hundred percent disagree that the criticism is not right. In some sense, especially for the library authors there has been a bit of breaking change and things not working out, out of the box. And in fact, I saw somebody talking on Twitter as well that reacts version that is being used inside the latest next that is marked as a stable, but the react version that it depends on is itself a nightly or canary build and a lot of things around the paradigm of like RSC and also app router We tried to port our scripts, port our library [00:19:00] and also our app to next 13. 4 RSC and all those things, but we did face problems like we, as we built a lot of libraries, like glue stack style, for example, which is a CSS and JS library that works on react native and react as well. So. It had its own issues because it's a CSS and JS library and they say that CSS and JS wouldn't work because it's all getting computed at the server side and there's no way, no API available to inject that CSS at the style tag of the, maybe inside the head. So we have problems like this. Then glue stack UI, the component library that we built, we have used compound components which uses the dot notation to combine the related components. For example, if you have button and button dot text wouldn't straight away work in several components because it just understands the things at the root level. And. Anything that comes after dot it doesn't really treat as a component. So it's not shipped when you do an rsc, so rsc [00:20:00] uses its own json format to send things from the server and then we have a client renderer of rsc that Understands the json and then does this the reverse of the things that happen on the server So it renders things on the screen inside the ui so essentially it does not take care of the compound components right now, which is Breaking our app. I think the way it was announced and released into the, like for everyone, probably it should have been done in two steps. Something like how you see iOS, MacOS and Windows coming in developers preview first, and then it is available for consumers. Probably there should be a phase that it's available for say library authors first, and then stay there for three months or six months. And. Then release it for actual developers. Otherwise, like we have, I saw a tweet yesterday that MUI is now working with RSC. Like it, they took so much of time to make it work. [00:21:00] Even Chakra doesn't straight away work. The author of Chakra had to build a new CSS and JS library, which was compliant to the RSC paradigm. So it gives you a different CSS file altogether. So yeah, there's a lot of back and forth that's happening right now, for sure. Yeah. It sounds like there, there are some hurdles and maybe that's another reason why for the time being, at least we're stuck to use other people's and Next. js's implementations of React server components. And their framework. Yeah. But, yeah, I would like to add something here. It's not that negative because that's how innovations happen when you bring in something like a big change, things like these would fall out, like apples at some point they'll remove CDs, right? And they keep doing that. And, but they do push and speed up the entire innovation. It may annoy the existing ecosystem a bit. But I think that shake is also important from time to time. Yeah, no, that's [00:22:00] a really good point. And you're not going to, release an out of the box experience that will make 100% of people happy straight away. So yeah, no, I think it's important to keep that in mind as well. So do you think that it was the right time for Next. js to ship the app router with React server components? And you mentioned that the app router is now stable, but the server components are still in a nightly or canary build. Is that a contradiction or have they worked around the issues? there's a bit of contradiction. The only thing that it should have been released, but with a tag that, okay, this is for library authors and not for everyone. Because as you As soon as you mark anything as stable, the entire dev community, they just start jumping in and start saying that, okay, this is not the latest. And the code that was great, that is still great is marked as like legacy, which is not right. And that happens in the JS world very often. So we need a transition period and also need to balance out with the new things coming in without having that FOMO.[00:23:00] Got it. Yeah. And I guess to end on a more positive note, like we began, what do you think the future for RSCs is? Where do you see these going? I know you alluded to other potentially other frameworks adopting them, but yeah, what else? Yeah. I think it's very bright. If you're still questioning how good RSEs are, go ahead and watch the talk by Dan from the RemixConf. I think he made seven or eight points and examples for each one of them. And those are like, mind blowing ideas. And if that paradigm comes to every app and every web app that I build. I think that's the future that, that opens up so many new possibilities of bringing in things. And yeah, with server actions and the whole DX becomes like really easy. You don't really care about writing APIs you straight away , do the DB calls in your React components, which is nice. So yeah it's for the good. The future [00:24:00] is definitely bright as all these libraries and ecosystems stabilizes. This is going to have an impact outside React for sure because that's how we have been seeing like from the past 10 years, whatever React comes with we can see like Jetpack Compose or maybe SwiftUI adopting that, or maybe other frameworks too adopting that. So this is the genesis of ideas, I would say, and it'll have a compounding effect overall. Awesome. Yeah, it's really exciting to see the React team drive innovation that way. Thank you so much for coming on. I guess before we wrap, , is there any place online that our listeners can find you anything you want to promote? Yeah. I'm available on Twitter with the name Sanket Sahu. Go ahead and yeah, where we can get connected and yeah, go ahead and try out glue stack UI and glue stack style, which we recently announced. Would love to get feedback and start helping everyone. Awesome. Thanks so much for coming on. Thank you so much, Sean. Yeah. Thank you.