Server Components vs Client Components with Atila Fassina 
===

[00:00:00] 

Hi, and welcome to Po Rocket, a web development 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 free@logrocket.com. I am Taja Kumar, a Derell consultant, and today I'm joined by my good friend, neighbor former coworker.

So many different things. Atila pronounced Ula Faina, a senior developer experience engineer at Zeta who recently spoke at a conference called React Norway. With me. So also fellow conference speaker and he spoke about server components versus client components, the showdown. Today we're gonna dive into that topic exactly and understand server components, client components, how they compare to each other, how they interleave, and so much more With that at until I'd love to welcome you to the podcast, welcome.

Hi. Thanks. Thanks for having me, and nice to chat with you Tejas. This time we're being recorded.

Yeah, , before we get into your talk do you mind just telling our listeners a little bit about your background and experience in web development and where you, I know [00:01:00] you used to have a gym, you used to be a physical trainer, and then your like, I want to do code and Yeah.

If you could give people some insights into that.

Yeah. Yeah, I have a non-traditional background, like my bachelor is back in Brazil in physical education, which meant that I'm a licensed coach. I taught people how to swim. I taught people how to work out. I had a gym back in the day. And then at some point I just realized , that life was not for me.

Start looking around, tried a bunch of different stuff and ended up falling in love with front end development. Since then, has been almost 11 years now and I've done. All kinds of stuff. I work with design systems and startups of different sizes. I worked a lot with React nowadays. I've been doing a lot of next Js and playing around with it doing workshops.

I do have a YouTube channel where I try to record some stuff about stuff I'm learning.[00:02:00] Satil io at YouTube and yes. After that after a while doing the core engineering thing, I realized I was very much a content creator and decided to try . My luck with Dere, which is basically where Tej and I end up working together at Zeta.

I've been working at Dere officially for over a year, and part of my work is actually creating samples and integrations. Zeta is a serverless database platform, so I play around with a lot of different frameworks and. Basically try to understand the best practices on connecting to databases and building apps.

Naturally when React server components came around, I had to be all over it because as I, hopefully most of you know, the best place to connect directly to your database is through the backend. So having a component that renders straight up in the backend kind of makes my life a lot easier. And that's how [00:03:00] I started looking into it.

And I ended up digging a little bit further in order to understand and to better guide people and learn how they work. I think that's the best way to, to build something cool is to understand how your tools work.

That's awesome. Yeah, I fully agree. It's also cool that in your current job you get to play with so many different things and I imagine you're probably also playing with things like up stash or replicas or a bunch of different. Tools to understand the ecosystem. That's awesome. Okay, so you've been diving into server components probably more than most people I'd assume, cuz it's literally you do it like it's your job cuz it is.

So I'm curious, a lot of people have confusion around server components, and I'm sure you've seen the discourse on Twitter go a certain way lately. That hasn't frankly been very good. I'm curious how, given that you play with it so much as part of your job the talk title is server components versus client components, the Showdown.

I'm curious. How that works. Like how do they fit together in, in one's mental model? I [00:04:00] was wondering if you could speak to that for the listeners of the podcast.

Yeah, absolutely. So the name of the talk kinda led on people to think about as them being opposed. And that was a little bit as my silence criticism to the discourse that I've been hearing because. Yes, the defaults have changed. So like the main recommendation is that we are going to start up by using the server components and that kinda led to people in order to try to understand the server components.

They tried to, what I understand what I saw people doing at least, or. What I imagine they were doing is trying to fit their mental model from client components to server components, which don't actually fit, like they're different for a reason. But in honesty, I actually opened my talk apologizing for doing that click bait title and pointing out that the idea is that we are going to mix and match them.

We're going to use them combined and. Again, there is a new thing called server [00:05:00] components, but that doesn't mean you need to use them everywhere. It means you have one more thing to choose in order to build , the best user experience you can. If the best user experience , you can build is using client components, go for it.

If you don't have a place for server components, if you cannot. Leave up to the requirements that a server component imposes in you and there are a few, we're gonna talk about it later. Then, yeah, stick with the client components. It's not something that from now on you need to refactor all your apps.

So that's what I was talking about and I used that into leading on to basically going a little bit. Backwards and looking at how client components got to the point where they are, , why we built the, this component architecture, virtual dom and stuff like that. And then from then on we can see what are the points that client components were actually not giving us the best developer [00:06:00] experience or the best outcomes.

And then pointing out the places where server components do. So I think that's the point. 

So they are not necessarily opposed to each other, but they're more intended to complete each other. And I love that you say, it may not be for everyone. For example, if somebody's building like an internal dashboard for 30 people in a company with local intranet.

Intranet, you're probably not gonna need all of this server rendering magic, but if you have an e-commerce store and performance is critical and so on and you also, security is critical, you'd probably need that. I like that you highlight that. You also said something really interesting. You said the default is moving, the default being client and then moving to server.

I'm curious why that is, and I'm curious how you respond to that.

I think the reason why this is happening is in order to like, Come around and make peace with the progressive enhancement narrative where it is important for us to leverage the platform [00:07:00] as most as possible and being able to accommodate and to and to only add. More functionality as it's necessary.

And so by having the rendering on the server, we are not only, we can not only ship less code towards the client, but also we can have the best performance, we can have most of the processing and also coming from. A guy with some skin in the game. Because I work in a database company, it's also safer. If you're rendering your app, your components, if you're handling your data on the server, it's best for you to do it also opens up possibilities in terms of caching, the artifacts of that that rendering and so on. And then what the server components do. They're actually not that much.

Different. If you look from afar as we're talking right now, they're not that much different of what we've been doing before. Like for example, if you look at the loaders in remix or if [00:08:00] you look at ga, server side props in next js what we were doing is basically server side rendering a component already, but that was like the page components.

So it was like a whole view. And now with this React server components, what we are actually doing is making it more granular and then we can. Go like little pieces of that UI and stream them down. So I see that as an evolution in this case and as all things go, you can maybe need to make it more granular or not.

As you mentioned, there's the case of having this intranet or like an app or high interactive single page application that's basically having a bunch of components that need to be interactive, that need to handle user input. Maybe that's not the best use case for a server components. Maybe you're going to have one or two somewhere, but most of your app's gonna be client side, which is okay.

Yeah. You mentioned some really interesting things just now. You mentioned it's server components kind of fulfills this progressive enhancement [00:09:00] narrative. Meaning and what I understand by that is the single page application model, meaning you, you load a shell and then you fetch JavaScript and then you fetch data and so on.

Cumulatively breaks a lot of progressive enhancement, right? Because there's nothing to progressively enhance. Two, you'd literally just have no page unless you have JavaScript. Versus with progressive enhancement, you have a form that actually works and JavaScript literally enhances the experience.

Would you say, I've heard some people say that in some way, Server components is react cleaning up its own mess. And I think that's a little bit crass. Personally, and I think it contributes a little bit to this discourse we're hearing, but do you think there's some truth to that statement?

I wouldn't say cleaning up their own masks because like we need to acknowledge the fact that a lot of the web is built on React and we have a lot of nice. Things that have been built with it. A technology that gets so popular, Reacted . It is gonna take some fire from the people that misuse it.

[00:10:00] It was the case with PHP back in the day, that people would talk bad things about php, but that's because everybody was using it. And yeah, some people are gonna use it probably in weird ways, but that doesn't mean the technology itself is bad. So I wouldn't say it's cleaning it's own mess. I would just say it's learning with.

What the platform can now offer and learning from the usage that people are having, which is also talks volumes to the other frameworks that are more recent than React. They're coming like, they're doing some very nice and interesting things like Quicks does with mobility. Solid js with fine grain reactivity.

They all learned from. What React has been doing in, in, in the sense and the way the way they are approaching the problem is one way. That's right for some people. The way reacts approaching the problem is another way That's right for some other people. And the, this plurality is nice and I wouldn't say [00:11:00] there is like a huge mess for anybody to clean up.

I just like to see things moving forward.

Good. Yeah, I agree. I also think you mentioned solid quick learning from React, and I think absolutely like the fact that. I could honestly, man, I could look at a button implemented in solid quick and react in J S X and I would not be able to tell you the difference for a long time unless I look very closely because they all use jsx and they all look the same because of React.

And that is reacts like concrete contribution to the ecosystem. JS X is here to stay. And I think a lot of the criticisms people have about Angular, for example, is the fact that there's. Formerly this decorator syntax that's going away, but there's this like decorator syntax that doesn't use J S X and it's like harder to reason about.

So I fully see and agree with that. You also just now said if you're in this like intranet type of setting or if you're in some setting where you have a high interactive. App that benefits from a client only model. You mentioned you could get away with maybe one or two server components, but you probably don't need it.

I'm curious if that's even [00:12:00] possible. Because the advice I've been seeing is start with the server and you, even if you want to have one server component, you would have to re-architect your entire application. To start with the server because server components can render client components that render server components, but client components cannot render server components on their own.

Because they're client components and server components can, do wacky things like import FS modules and things like that. So I'm curious, is there a world in ware? Say I have a fully client only app and I want to include one server component. Can I do that?

Yeah. So that's, yeah. I see what you're like. I ca I came in my point with, from a different point, from a different perspective. So the thing is, when you're going to use react server components, you're going to have. A little bit, some very specific in structure or infrastructure. If you may, in your app, like you're going to need a router, you're going to need a backend that is capable of handling this and.[00:13:00] 

Yes. If you have a single page application today that was not built with one of the frameworks, they're supposed to support React server components, you're gonna have a hard time, you're going to have a lot of refracturing to do. What I meant about getting away with one or two server components is if you're building something new today and you're using one of these frameworks that do already support the server components, you might have one in the root and another one in a few roots.

But then, As you go downwards and as you go to more interactive apps, you might want to bounce out, flip the default by using one used one used client at a higher part of your tree. And then from then on everything's client, so that can work. But yeah, if you are going to try to adopt on something that's already running it's gonna be a lot, it's gonna be a huge undertaking I imagine.

And I think this is probably why a lot of people are frustrated with server components, right? Because it's a big ask. It's a big ask to say, Hey, I need you to rearchitect your whole thing, to use this thing that you may not [00:14:00] even need. , but I think also the backlash comes from people just having.

Ill-informed or uninformed opinions about what server components even are, and I think you as a content creator and I have a responsibility to help that a little bit with our content. I look forward to your video on server components.

Yeah. I agree with that a hundred percent. And I also think that part of the confusion comes from the fact that React server components was announced or. Popularized in at the same time as the Abstracty on Next Js, and they were given to developers as a bundle. And then people cannot actually tell a difference about where's n js ends, where React begins, and how do I use React server components if I don't want to use n js.

So I think there's a lot that's going to change on this. View of things as other frameworks, as other library authors start implementing some kind of support. . I saw B Blink, a bling. I think it's from 10 Stack. [00:15:00] I also saw some work from Dai Chito, from Tai that has been doing some kind of work on having React server components working outside of an X js structure.

I saw some Twitter threads about remix people looking at it 

I'm a YouTube video tomorrow that shows people how to make their own server components without next year. Yeah I appreciate the content in this area. Coming back to your talk a little bit you mentioned, also not just your talk, just now, literally in this conversation you mentioned since React is so widely adopted, a lot of people use it and some people use it in maybe unhealthy ways and then turn around and hate react.

I'm curious what parts. Of those would you say led to the advent, so to speak, of server components? I'm talking about things like you mentioned in your top prop drilling or expensive renders, things like that. So I'm guessing, I'm rather hoping maybe we can tie together client components and server components through these things as a bridge, because I assume server components simplifies and solves those issues.[00:16:00] 

Yeah, exactly. So I mentioned those as in a way of trying to illustrate how client components itself because I heard a lot of. \ talks about server components, having a difficult to grasp mental model and what I was coming towards when I mentioned memorization and when I mentioned prop drilling was that client components are not exactly simple, it's just something that's been there for 10 years.

We got used to it. We learned as we went, like for example, Prop Drilling and the context API are uh, contact API is an API that came to improve our developer experience and the performance of our apps by avoiding prop drilling. So then we can have a prop that's skipping from the root to the leaf of our tree.

And we don't need to pass one by one. So that's one thing. That's something that came out to ease up our lives. And then memorization came for, from a lot of components that have like heavy [00:17:00] tasks that are heavy to perform, or components that have end up having a slow rendering. We can memorize some some callback.

We can memorize the rendering or we can even memorize just callbacks. We can persist elements and stuff like this. So those are all like very tough problems. There are problems that developers that have been working on React for about 10 years is still shoot their foods with there are still people that sometimes Like in a in bad ways, try to avoid renderings and then try to memorize everything and so on.

So we have ideas from like even the React team about react, forget and automating some kind of this memorizations turning, getting react closer to compiler, which is a whole different story. But these are all very tough problems to solve. And the thing is, once you move the rendering to the backend your components being rendered on the backend.

All this memorization story, all these pain points, they. Either they [00:18:00] lose importance or they become minimal because then you're in a controlled in a more controllable environment. You can check that for you, you can monitor that a little bit better, and even if something bad happens while you're rendering your component, it's on the server.

And the, your end user is only going to receive the artifact of this. So it's the static markup in this case, which then ends up saving your UX even if you mess up. So I think that there is, like, when we look at the pitfalls and the difficulties of creating client components, we get a little bit closer of understanding the why's in the house of server components, why they're like that, and getting closer to an, to like, Stopping thing, like realizing that yes, client components are a thing. I need to pause this thing right here and then learn server components first. And once I understand this mental model, then I can think about using them together. That was the point of my talk. [00:19:00] First we look at them separately and then we can put them together because the problem. That makes server components hard is if you try to use them with a client component, mental model, because then you're going to be shooting yourself in the foot and having some weird issues that are sometimes hard to track.

I guess

I love that. , so what I'm hearing from this, something practical that people can take and use in their day-to-day job that you also highlighted in your talk is understanding both. Separately. So client components are this and they're good for this, and server components are this and they're good for this.

And just understanding those two in isolation deeply will then help us compose them in the react composable component model better as opposed to I think the thesis of your talk, and correct me if I'm wrong, is that a lot of us are trying to and myself included earlier before I fully understood server components, was trying to.

Kind of shoehorn or fit server components into a client component box. And then I would get angry when they don't quite fit. And the takeaway is they're different beasts. You just understand them differently [00:20:00] and then you find their place. 

Yeah, so I also pulled my hair out. The first time I was using a server component. I thought why a hook would fit so well here. Like, why not? It's, but it's different. It's a different mental model. And then at some point our first impression is to, okay, I'm going to pass an object now. And then suddenly you have the serialization boundary that's picking you up and then you have some issues with that or also problems that.

As server components don't have that much of memorization problem or they don't have this the problem of the prop drilling, they will have a problem if we end up passing more props than we actually need to rendering. Which is something that client components don't have. uh, if the props are already at the runtime, we can pass down to the child components, the children components, and that might not be a problem.

It's gonna be way. There's gonna be a long time before you have some issue with garbage collection or whatever. Meanwhile, if you end up passing [00:21:00] too many props, if you end up like a big, the best example I can think of, if you're rendering a list and you want to pass the whole list to each item, then you end up creating a gigantic J S O N that's being passed on for each one of those server components.

And these are patterns that. We're harmless on client components, but can act can actually break your app on on server components. So the, it's a very, it's a, it's dangerous step to try to shoehorn the client component mindset into the server components. And I think once you, once we understand that, then we can understand how the server components work and playing around and using them for what they're good for.

Yeah. To help us prevent the shoehorning. I wonder if we can do a little exercise. I wonder if we can define Clearly maybe in a high level, so very hand wavy but abstractly enough that it [00:22:00] makes sense how client components work and in parallel how server components work.

And by doing that, we help people not shoehorn, but understand them, even if like just top, top contour and then let them go search more. So if I asked you right how do client components work? How do server components work? What's the difference?

Oh I wish I had somebody that wrote a book on React with me to help me explain this.

For the ones of you that who haven't heard, t is writing a book on React. And it's a really good book. 

So I think the best way , to understand how they work and actually have them in parallel working is understanding that react as. Like React render is going to create an abstraction of the dome we created. So whenever we are writing the J S X, we are writing this templating language, which react is going to turn into it's basically going to map it.

I don't wanna use like, Fancy terms, but it's going to map it as in a very Jason [00:23:00] like structure where you have these key value pairs and reacts going to map each one of them. What is the tag you're using? What are the children of that element? What are the props that element use and so on. And once react maps that it's going to have this little snapshot of how the dome looks like.

Once they have that, then react can turn that little map they created into a static markup, essentially html. And then once the HTML is rendered by the browser, JavaScript can kicks in. Reads that html and maps it back to that little rendering tree. And with that react then is able to compare the snapshots and do a little diff every time you make an interaction. So server components are gonna work in basically the same way, but now that JSON structure that we are thinking of are going to have some holes. And whenever you're going to take one component out, think you're taking an object of that json. [00:24:00] So you're taking a little key of that json away and you're leaving a little tag there.

So I'm going to say, okay, this component, thet component, and that's a little slot. And once that other JSON comes in, the one that I just took out is going to come. Synchronously because it's just rendered on the server. It's going to arrive and it's going to carry that mark. And then once my client side JavaScripts, they're making all the connections and seeing it's going to pick up that little snapshot of the dome and saying, oh, I have this hole right here that's supposed to come for the TE component and saying, oh, I just got the TE component now so I know where to put it and it's going to fit it like a puzzle.

So essentially there is going to be this JavaScript that's part of the react rendering. Or the framework that's doing whatever is doing and it's going to stitch them together in this little puzzle way and filling up the holes as the data is streaming now, because we know where the holes are and we know what the slots are, that's [00:25:00] where React suspense come in because then react Suspense is going to see, oh, I have all these holes over here and I have this fallback component that I'm going to use to cover the holes.

While the data is going to be streamed. So I don't know when this data is gonna arrive, but for a while I'm going to just leave it there. So that's how the whole idea of direct like server components work in a nutshell for us to understand the ranging paradigm. Did I make sense? They did I do Good.

that's whether you, I'm not gonna give you a grade, but I, it does make sense that Server components, I think execute, on the server and then come fill these holes. And that's why you can't have things like functions cuz it has to cross that serialization boundary and you cannot serialize functions.

You just can't. You also can't serialize the type of element it is because those are symbols and so on. So yeah, it, it does track. Excellent. You talked about Thinking in chunks. You say we should think in chunks. I often do think in chunks, but it's chunks of meat when I'm hungry.

I'm curious, what, I'm curious what think in chunks [00:26:00] means in the context of streaming and server components.

Yeah, so I think that React server components the architecture of server components, just take that whole component architecture that react salt was already 10 years ago and puts it on like on the maximum. Power or like on steroids or whatever you wanna analogy you want. So I think what it does is basically now instead of thinking about your rendering tree as a whole, you can think about how your components are rendering.

So those components are a little chunks of your app or chunks of your view or chunks of your ui. And then those components are going to be rendered independently and they have their own. Little tree. So what's gonna happen is that every time you render a component on the server, from then on they have this little prop they need to cascade down.

So in some ways, They're not entirely connected to whatever came before [00:27:00] because it rendered before. So they are connected. I'm sorry. Somebody's gonna come and say, so they are connected in a way, but they're rendered at different times. So they are asynchronously, but they still talk to each other.

It's not like you're working on islands or something like that. That's a different story. But they still render and they handle their own. Children then on. So in a way, once like you, we have this little chunk and I think the chunks are also good for us to understand how the serialization boundary works because every time you have a component rendering the server, the serialization boundary is there.

So now within our app, before then, when we were doing service or rendering, we had the serialization boundary as a straight line, like you have the rendering. Snap serialization boundary. Client now each component has this little bubble of serialization boundary, and then everything that comes goes between components [00:28:00] needs to cross the serialization boundary.

So I think the chunks help, I don't wanna say the word island, because there's island architecture. It's a whole different thing. But they work on little bubbles like this. And talking about these little bubbles and talking about the connection between them. I think it's important for us to mention.

How we actually put data in, because we just said we cannot pass props from one component to the other in this way. So I think we need to address the fetch, the duplication, right?

Yeah.

So the idea to put data inside our components is that now we can make multiple connections to our database to our data source, whatever it is.

It can be an external api, it can be a database, it can be whatever. What's going to happen then is that as some of you might be thinking now I'm going to fire the same request over and over again, and that's like a major problem. It used to be, at least when we were learning [00:29:00] how to work and we were working on client side only in single page applications, we needed to save the request.

So we need to do one big re ground trip and avoid them as much as possible. And server components are saying no, just fetch anytime you need. And that's because under the hood, reacts going to de-duplicate his request. Reacts going to go inside the fetch prototype polemic side. So it's going to go in inside this fetch prototype, and it's going to be able to de-duplicate each request on render.

So if you fire the Same request needs to be the same method to the same endpoint during the same rendering. It's only going to fire once, so I can have. Multiple items multiple elements, multiple components in this rendering moment and hitting the same endpoint over and over again.

Reacts going to fire once, cache it and persisted for a specific amount of time. So the heuristics really depend [00:30:00] on. First react itself because reacts gonna try to duplicate. And second on the framework that's going to be rendering react. So next Js, for example, has its own heuristic for having this persistent cache and stuff like that.

And, They have some automatic things that are going to cache it. As long as the framework understands the resource needs to be considered fresh, otherwise you can override them and say, oh, force dynamic, or never store it or force cache it.

That's really interesting cuz that also calls into. Purview. Again, this idea that it's a bit hard to tell where React ends and the frameworks begin, right? Because this whole fetch issue is it that react is adjusting, fetch for react and then next JS adjusts reacts I say adjust to not use the word monkey patching, but that's kinda what I mean.

Does react then adjust, fetch and then next Gs adjust, react. You know what I'm saying? So these questions I see why some of the discourse around this [00:31:00] is the way it is because it is, I feel like as engineers we care about the details, we care about how does this work? Not in a policing sense, but in a way of understanding underlying mechanism.

I think that's why a lot of us are even engineers in the first place. Cause we're curious people. For example, I don't use view in production, but I write view once in a while just to see what the single file components feel like and things. And when that curiosity is like limited or gate kept behind behind abstraction for me, this is really challenging.

So I say that I know dhi, Kato, Tanner Linsley, Dan Abramov are doing work to show you how to make server components from scratch to mitigate this. And so I say this acknowledging that people are addressing the gatekeeping off behind the abstraction. But still, I think that's a problem.

And that's why I'm thankful for content creators like yourself. But I didn't mean to interrupt you. You were gonna add something.

No, I was going to agree with you. And I think that's a very valid point, that also speaks volumes to the confusion that people think, because we tend to we were told in the very [00:32:00] beginning, react is just of viewing library and then suddenly react is changing the fetch prototype according to the spec.

And then so yeah. But I don't wanna discuss semantics. What's the library, what's a framework, what's a meta framework? And so on. But then at the same time, because React did this, the duplication and stuff like this next Js, in order to fit it into the model they have this incremental static revalidation.

So they said, okay, so that moment where fetch is going to be cached or not is. The perfect moment for us to define if a resource is going to revalidate or not. So then next JS went and extended reacts extension in order to be able to set up this revalidating time straight on your fetch. And this is important because then a framework like Next JS can realize, okay, so I have this route that depends on this component and this component depends on this request.

And. [00:33:00] How long I'm going to cash this thing. So I need to be able to know the caching time of each one of those and pick the smallest one. Otherwise, I may end up with this Frankenstein thing. When you navigate bef to some place and you see some stale data on one component and fresh data on another one,

, just let's not name names of apps that do that, and we use every day.

. I wanna take the conversation to server actions. You talked about this extensively in your talking Norway in both years. . You talked about it here in Norway this year, but also last year , you talked about remixing, optimistic ui and you also had a piece about actions there.

So you're, to me you're now forever the action guy. And I'm curious. In the context of server components and the new direction of React what are server actions?

Yeah, I think that's very interesting. I think server actions they're a pattern that's really cool because they allow us to. First one, use the platform because we're circling back to using [00:34:00] forms in order to send data. And then comes all the jokes about P h P and rub and rails.

Ha. They're nice and they have some sense, but the point of going forward is actually picking everything that worked before and trying to make it better. So yeah, there are similarities, but they're not the same. But then we have now different a lot of. Kinds of actions, but essentially , I could draw a line between each one of them and say that actions are a way to fire a data mutation from the client and.

Maybe that's a requirement, maybe it's not, but it's using a form component at this point. Every action use a form component, even if it's regarded, if it's remix next JS or even solid start, they're using a form component and they are connecting to method or a function that's going to execute on the server side. And , to me, that's , the biggest. Selling point of you [00:35:00] needing to have a framework built around it. Because the developer experience of using actions or server actions is amazing. Because basically you're writing a function just like you wanted, like just whatever you wanted. But you're saying either you're using a, something like create server action or you're going to use proma, like use server. Or you're going to define based on the DSL of the framework and saying, oh, the function name is. Named action, and that means it's gonna render like this, but essentially the framework or the compiler itself is going to be able to grab that and put it on your server side bundle, and then create the fch request appropriately to hit that endpoint and then execute that on the server, which means you can now have some very nice co-location you can have.

Good TypeScript inference because the code base is more or less it's the same and you can, as you're writing your logic, you can just focus on the [00:36:00] behavior of that thing. And , the server actions, in this case, the way they are implemented in every single one of them, they allow us to do very nice stuff like pending UI 

with just a conditional, so you can see if the request is still pending, if the request is success, if it's an error, et cetera. And they also can do optimistic ui, which is, if you can rely on your backend, if you know what kind of response the backend has. Basically the user is, Trying to set a certain kind of mutation, and you know how it's going to be how the response should be.

And then you can just give them a very snappy response. And at the moment they click send, you're going to do that. Meanwhile, your app is performing the action under the hood, and if it fails then you can prompt them for a retry. Again, You should only do that if you can actually rely on your server.

If your action is failing more than passing you have a problem, you have a bug. You cannot be optimistic about a bug, hopefully. But yeah, so that's the point. [00:37:00] And I think server actions are really great. Because of that, it kind of empowers you to just have a great developer experience and the best user experience in the end as well,

because the framework's handling the heavy load for you.

Yeah, that's really, I would love to dive into the details of how that actually works, cuz the moment you click a button, the server needs to respond with, Hey wait. Somehow. , so I guess it's almost like taking the stuff, the benefits that you get from libraries, like react, query, s w r, et cetera, and making them a isomorphic solution so they work on the server and the client as well.

But I wanted to ask you What your recommendation is, like what's the best case to use server components and what's the best case to use client components, given that both, you mentioned it's not one versus the other, the showdown, but they fit together perfectly.

I think the best scenario for server components are essentially if you have some component that might we can think about the biggest offenders from our client side only times, for example, a [00:38:00] date picker or a big translation or something like that. Things that end up shipping loads of J S O N to the .

Would bloat our bundle unnecessarily. So things that would otherwise ship like a huge amount of JavaScript or data that might not even be used. So for those, we can do them on the server now. And then , we never risk bloating our clients. So we can have, for example, a date picker that's going to have all your possible, like date formats and whatever on the server.

You can have a. Whatever translation page or whatever component that has all the possible languages of your app on the server. And whenever that needs to be rendered, it's going to ship only with whatever's been used. And if you need to make an interaction there, there's a server action for it. And then you can revalidate only that little component, only that little part.

So this is a big. Selling point, at least to me for server components, which is [00:39:00] making sure we are shipping the least code to our users and using the least code necessarily. And for the client components, I would say is still the interactivity. So if you have something that's like heavily interactive, if you have something that.

Depends heavily on interaction. I don't know if you wanna do a drag and drop or something like that, you are going to need a client component for that, and that would make sense to then have the data there at your hand. And as the user clicks and mix and matches the stuff, you can do a snappy response as well because of this. And again, there's still a case in my opinion, for the soft navigation, which is whenever we are navigating from one page to the other and doing the prefetch of those resources between different routes. In our app, soft navigation is when we trick the browser into not going all the way to the backend, just fetching the data And showing a navigation as instant so we can persist data across different routes as well. So I think that's a very nice use case for still [00:40:00] having the client components and the client side aspect of our apps.

I think that's actually , a great example of both, right? Because the client can respond to hover and click events on hover start, like Prefetching, and then it would then when you click the link to Navigate, or the button to navigate, instead of actually navigating, which would be a multi-page app style reload, you would.

Fetch the Js X for the new page and then just call react render on the new Js X. And so it's this awesome like client plus server component duo that you see. You really struck a chord of the soft navigation.

Yeah. So we have in , at least in next JS, we have now I dunno if any of your framework, I'm sorry I'm not entirely familiar, but there is like intercepting routes. Which are pretty great, which means that if I'm doing a soft navigation between one route and another, I can show that the second route as a dialogue.

But then if I pick the URL of that little dialogue, if I pick the URL that's on my nav bar and [00:41:00] send it to you, and you hard navigate to that, you're going to see the actual page. So I just did that on my movie database thing. It's X mdb Versal app. And if you click on a movie detail on your search result, it's going to pop as a dialogue.

But if you copy that page and hard navigate to the movie, you're going to see the movie details page. And that's a very good example of how. Powerful and a hybrid app can be by having the best case of a multi-page app. In the case, if you do a hard navigation, you get only what you are looking for.

But if you're doing, if you're actually navigating, interacting with the app, you get experience of single page app.

And that is truly progressive enhancement, right? Because it works even without JavaScript.

It's next to, yeah, so it still uses JavaScript all the time. I yeah,

I don't, I, 

an anchor link, will not just navigate to the new page if you don't have JavaScript like a

[00:42:00] ah, yeah. Sorry. Yes. I'm sorry. Yes. ,

like the app itself needs JavaScript, but the navigation part, yes.

Yeah, no, that's what I meant. Just this intercept, what is it called? Interception routes.

Yeah. Intercepting routes. Yes. In this case, this particular case, to be very precise, it's a combination of intercepting and parallel routes, but that's like next J as specific stuff. So intercepting is when you're going to grab a. A url and you say, okay, so I'm going to grab this url. Instead of showing component one, I'm going to show the other one.

And parallel routes is when you can determine on a specific route, based on whatever state your app is in, you're going to show one child or the other. So there's a combination of those, but essentially what makes the Magic works is the intercepting routes.

That's fantastic. Atilla, listen, I could talk to you for another hour, honestly and more. 

As we did before,

Yeah, exactly. I know you have a YouTube channel that's at, at [00:43:00] io on YouTube. We'll put a link to that in the show notes.

Is there anything else you'd like to highlight and shout out in terms of closing words here on the podcast?

No, I just would like to thank you all for having me and I had a blast as usual talking to Yout and yeah, just find me up on YouTube, Twitter, my, it's my name and last name as well, and pretty much every social network. So hook me find me there and yeah, let's talk shop. Let's talk server components and whatever else your mind goes to.

Fantastic. As always, my friend, an honor, a privilege, a great joy to talk to you. Thanks for coming on the podcast.

Thank you.