Hydration, Islands, Streaming, Resumability… Me, Oh My! with Matheus Albuquerque (2) === [00:00:00] Hi, and welcome to PodRocket. I'm Tejas Kumar, and with me today is a good friend an occasional co speaker at conferences, Mateusz Albuquerque. Mateusz is a senior front end engineer at Medallia, and he's been on the pod before, so we're happy to welcome him back. Today, we're going to talk about hydration, islands, streaming, and resumability. That's resumability, not reusability. Mateusz, welcome back to the podcast. Cool, thank you. It's great to be back and it's great to be sharing a podcast with you, Tejas. Yeah um, I'm equally excited , um, you did a great talk titled Hydration, Islands, Streaming, Reusability, oh my and I think the title of the talk kind of alludes to this notion of concept overload, but I want to hear from you in your own words \ maybe speak to the talk and the motivation behind it and the content you covered So, Basically the idea for this session started about... It was... Mid last year, actually in the beginning of the last year that I felt like there was a lot of things I [00:01:00] still hadn't catch up with in our whole ecosystem. So I was reading a lot about those. Discussions of NPAs versus SPAs, routing how to bundle things and et cetera. And I found myself a bit in that momentum we had in 2016, 17, where we were discussing the whole JavaScript fatigue and et cetera. But back at the time we were talking about fatigue when we had Angular, Vue, and React. That's the choice we had to make. And nowadays we have a lot more of options and choices, and not only of frameworks, but also of rendering patterns and etc. When I started ideating this session. I wanted to shed on some of these concepts, yeah. Wow. That's really profound. Now that you mentioned also, I agree, the decisions we have to make these days factor in a lot more variables. We still have to choose right between angular, quick, solid, etc. React, maybe the [00:02:00] choices. aren't so much just about the libraries, but they're about how the libraries work, because some really champion islands, and others really champion reusability. In fact, the only other one that champions reusability is QUIC. . You start the talk, asking, like, how and where do I want to render content? Because now we can also, based on the, even just the title of your talk, we render in multiple places and rendering used to mean really one thing back in the early days, right? But now it, means multiple things and it also happens in different environments and it also can be asynchronous or synchronous, like rendering has become so much of a loaded term. So I guess the question I'm trying to ask you is if you could highlight the differences between rendering, for example, on servers. That is web servers or build servers, because even that's different or clients or the edge. Yeah, so that's one of the things I explored throughout different sessions of the different sections of the talk. For example, a lot of people let's, let's grab React Server Components. That is one of the things[00:03:00] you also have been talking a lot about recently. I still notice a lot of confusion on the whole idea of React Server Components. And a lot of people think. That server components are directly inherited to server side rendering, SSR and related things. And one of the things I focus on showing is that how a build server can mean like different stuff and same thing for rendering on the client and et cetera. And even on the edge. So a lot of us front end engineers we think that because. People have been talking more in our realm about The Edge recently, mostly after 2017, then a couple years later, Versaille and others also released. Support for running on the edge and things like that. So we tend to think that this is a recent thing, but actually the whole idea of being on the edge is not new. The first CDNs [00:04:00] started back in the nineties and people , have been using the edge on different industries for a lot of time now, so it had IOT devices or security or even medical monitoring things running on the edge. So I feel like I deviated a lot, but the main point, one of the main points was that the answer to where you want to render things, it depends a lot on the use case and choosing the most suitable thing is going to impact a lot, not only your UX and your product, but also your developer experience and how your team is going to move forward and et cetera. So that's like the initial discussion that I proposed. And also I raised these questions because I wanted to bring in this fatigue I mentioned a couple of minutes ago. So how did we get in a point where we have to answer, where we have so many questions to ask when the whole topic is just rendering? Yeah,[00:05:00] I want to touch a little, you've said edge like 18 different times in the past answer. So I want to talk a little bit about edge. And maybe we can start by, by clarifying what edge means. This is probably more than just a. A basis for you to is it you to, is it the right, some band has a dude named edge. I think it's YouTube. What is the edge to those of us who aren't maybe that deep in the network side of the world. And then we can talk about some more implications for it. cool. So the idea of edge computing consists of bringing what we have in the servers or in the cloud. Or perhaps in centralized service, et cetera, closer to the end user. So that was, for example, when traditionally a couple of years ago, we would have Heroku with, I don't know, 10 to dozen data centers distributed across globe, some in the US, some in Europe, Asia, Americas, et cetera, to a point where we have a couple of hundreds, for example, and then that means that you can have, for example, [00:06:00] lower latency and that kind of stuff. And , this has a lot of use cases, but most recently we started rendering like front end stuff on the edge. So , there was Cloudflare workers. And then after there was Dino land and then Purcell edge functions. And what we all noticed throughout the last couple of months. Perhaps 12 or 24 mouses that every single framework or meta framework has rolled out support for edge functions and et cetera. So at this point for us, we can deploy like two variety of serverless and agile frames and et cetera. And I think this, and this didn't change a lot how we developed, but still it improved a lot, like latency and I think that's a really good description of the edge side of the world. But now that then presents another question you mentioned, we just started rendering things UIs on the edge. Why [00:07:00] is that? Because you mentioned also that the edge isn't new, right? We've had edge servers for a very long time. CDNs have been around for years. So then why did we recently start using the edge for things like rendering and functions? one of the things I would suspect is that basically we noticed a lot of demand for that after the whole rise of serverless. So serverless did solve some problems and et cetera, but at the same time, it introduced the whole monster of cold stores. And things like that. So I think that when we started noticing that edge and not only rendering like a reactor some other front end on the edge, but also serving as functions and that kind of thing could be a potential answer to the latest introduced by cold stars and et cetera. I think that was one of the triggers, , and also the way that the JavaScript ecosystem involved into [00:08:00] more runtimes. We got, as I mentioned, Deno and Workers, and there's also Bond that is an amazing working product. So we got smaller and more efficient run times for JavaScript. Not only the Node. js or the other browser engines we're used to. So I think that also helped a lot. But I'm Cloudflare or Vercel would have a better and more appropriate answer to that. You mentioned web servers, build servers, and the edge. I'm wondering if we can dive a little bit deeper into the distinction there between web servers and build servers. You kind of talked about it before, but there's effectively, Two different kinds of servers as far as rendering is concerned, if not more. How do they work together? Do they work together or are they like exclusive? So that's the thing. It really depends in some of the patterns. They do work together in some of the, then in some of the interdisclosive. So basically that's one of the historical context to try to bring. So I go way back in the past when we had PHP and Perl[00:09:00] and that was like one of the rises off of service. Apps were really simple and there wasn't a lot of interaction and then everything was happening on the server because back at the time the server was the powerful part of the network. So the browser didn't have a lot to do. The browser only had to interpret html and show the information that was there. So that's when we started talking about web servers and etc. And then As time went by JavaScript as a language evolved a lot, CSS evolved a lot, all of the specs evolved, and so did browsers. Basically, there was more responsibility and there was more work to be done on the client. And that's when we started talking about client side rendering and also SBAs and etc. There was, like, about 10, a bit more than a decade ago. So with client side rendering and et cetera, we also started talking a lot about build servers and this distinction between web servers and build servers.[00:10:00] And then on more recent patterns, like incremental, that kind of thing, then they're not very exclusive. And also with React server components, where you can have a server, you can have a build server. it depends on the case. So yeah, it's a lot of the questions in this topic. The answer is it depends. Would it, Would it be fair to say that a web server serves a website or web app to clients? And then a build server never really interfaces with clients. It just either generates static HTML or it generates like server component output or something, but it doesn't directly interface with clients. Is that fair to say? I guess so. At least I cannot think of any edge case right now that would Good, good. Yeah. I'm just trying to make sure I'm following what I'm hearing. And this is part of my way to make sure I understand this and just say it back to you. You talk a little bit about. What rendering content was like in the past. And I'm really curious about [00:11:00] this because like when I started developing for the web. I would see in my FTP upload panels dating myself here, but if I would look at these various directories, there was this directory called public underscore HTML, and that's where I just put my stuff, but there was also this CGI dash bid. I didn't know what it did back then. I don't know what it does today. I'm curious if you could speak. What is that? How is it used in server rendering? Was it used in server rendering? So it's funny you say, because I didn't know if that was elsewhere, but at least in Brazil, I remember we had a specialized. Career path that was the webmaster person that was this person that would know how to write ECGI scripts. They would also be able to upload no matter if that's a simple HTML with some CSS and perhaps to query or like a whole WordPress or whatever website to one of these servers. And it even writes some configuration, sometimes [00:12:00] Apache configuration so this has a lot to do with the previous topic that is basically these languages, they came out and they basically allowed for the first time websites to have like dynamic content and serve things from a database or something like that. And that was a revolution. But again, because there wasn't a lot of interaction and you were just displaying content. It was dynamic content. It would change based on the user and et cetera. But the demands for interactivity were like that big. And when they start rising, then you had to query. And after time, sometimes Zepto and et cetera. But the thing is when this demand for interactivity began to grow. We have the client side rendering. So that's when we have Angular other frameworks like Backbone and etc. React came after, but, and for the first time we had two great things because everything was not [00:13:00] everything, but most of the things were done via a build step, be it on a build server or sometimes even locally. Basically you had a chance to cache a lot of things and also you had like really good performance because for a while we had, until we started facing problems like shipping stuff to different networks, different devices, but for some time, if you had a really good connection, you had a really good, great user experience. And that was it. And then problems started to happen and then we're like, okay, we faced problems with hydration, some things turned out to be slow and that's when we were like, okay, let's go back to the syllabus and that's when we started doing SSR and that, that kind of thing. so if I understand correctly, CGI has nothing to do with computer generated images. No. That, That was one of the, I don't recall right now what the acronym was about. But I remember that when I first saw that, because I wasn't taking any formal [00:14:00] bootcamp or anything like that at all, back at the time. And I was aware of the CGI acronym of computer generated stuff. And when I first saw that, and I had my very simple host set up. And when I saw like CGI scripts, I was lost for a couple of hours because I was like, what does it have to do with, but yeah, no, nothing. yeah, I think that's, I think a lot of people trip over that. In fact, if you're listening and you trip over that, go on Twitter or X now and tell everyone. about your confusion with CGI like ours. So you mentioned just now in, in your final few sentences, you mentioned, we started with CGI and we wanted more interactivity. So we went to client side rendering and made these highly interactive SPAs or single page apps. But then we started doing server rendering and hydration and then things got slow again. And so now we're back to the server. So I'm curious if you could speak to that. Hydration and slowness. What, why, how does that work? What are the challenges with hydration? So the thing is. It's [00:15:00] perhaps not suddenly they were slow again, but suddenly we realized that some parts they were slow. So sometimes it's, we never noticed the problem was there, but it was, and it took us to, to realize the problem was there. So when it comes to the challenges of hydration, I kind of split these in two. So if you are building a framework, a matter framework, a library or something like that. Then I'd say that's mostly when you face the challenges of hydration versus, so you have to think about associating done elements with event handlers. You have to figure out, okay, this triggered this event handler. So we need to update app state and okay, the app state was updated and then you need to go through the whole hierarchy of components to make sure it reflects the changes. So there are a lot of challenges from the perspective of someone who's building a framework. And by the way. There are really good posts about this by both Ryan and Misko, like the challenges they face when building a [00:16:00] framework, like the hydration challenges that are usually faced and for like the people building apps and that kind of stuff. So the rest of us it's not like we face a lot of challenges. We sometimes face the drawbacks of hydration. So probably the most common of them is what's called the uncanny valley. So basically it's that one specific part of time where the bottle is there, but you still need to load it, parse and execute to have interactivity. That's one of the worst parts, and then also the execution itself can be really expensive and depending on what you have, it can block the main thread or something like that. These are the challenges and the problems and addressing them isn't easy, I would say. Uh, I mean, From what I see, it's not like I've tried to address them building a new framework, but addressing them [00:17:00] isn't easy. So the uncanny valley being this place like where you get some server rendered mockup in your browser. And maybe your component that, that exists both on the server and on the client because we didn't have server components around this time um, would render something like the current time, right? And then the string would make it to the browser, but it would be server time, and then during hydration that would. That would change to client time. But the uncanny valley, is this place between where you have server markup, Hydrogen hasn't happened yet. And the app's kind of a bit Frankenstein because it isn't yet localized in a way to your browser, to your client What I see about Canning Valley most of the times, and I've even experienced that in, in the past. It wasn't that bad but it's about in interaction. So it means that, think of it as a button or a button is not usually something heavy, but imagine like some filtering components or that kind of thing. So the thing is visually there, but because hydration [00:18:00] hasn't happened, it can be unresponsive for a while. So that's like one of the bad scenarios with the Uncanny Valley thing. Yeah. And then people start clicking on things and nothing happens and they get really frustrated and they abandon your app. This happened to me. Yesterday, I was booking something and I would tap the input field. It was actually, man, I don't know if I want to publicly shame them like this, but it was on Slack. I was using Slack and there was a text input for my two factor authentication code and I tapped on the input field, but it didn't focus. And I don't know why it should even focus. Cause it's just a native element. It's not anyway. But yes I've been there. I feel the pain. And I'm glad there's work being done. against that. If we think about some of the ways we're solving hydration I keep hearing that resumability is different to hydration and I keep hearing from specifically Mishko Hevery that it's better than hydration. I'm curious if you could speak to that. Does it solve these challenges of hydration? So I think that one of the great [00:19:00] selling points that I see when talking about resumability is people recapping the problem of, for example, the Uncanny Valley and stuff like that. For those who are listening and are not very familiar with the idea of reasonably, it is basically what the name suggests, the idea of doing some work on the server and pausing and then restarting from where you left off, but on the client, and that's basically, I think it's like a really good example, the whole idea, not only how quick implements it, but the whole idea is a really good example of thinking outside of the box. That is needed from time to time in the web, because basically you're in a way allowing the framework to avoid doing extra work and et cetera. I guess that the pros and cons really depends on where, on how you're comparing, because if you're compared to the traditional approach to hydration, where you're going to have any of those partial, selective, et cetera, hydration. Then you're going [00:20:00] to see in resumability, a lot of pros, but if you compare it to more modern, let's say approaches to hydration, like partial hydration, or even the idea of islands, et cetera, then you still have like interesting pros, let's say like that, but the list is fewer, I would say. So I'm. And that by the way, surfaces one of my main issues with resumability. That is basically, there's not a lot of resources out there. Everything that most of what we have in resumability comes from either the quick team or builder. io and I myself haven't even seen other big players. Implementing like the idea, like we have others talking about fine grained loading things and that kind of stuff, but resumability per C as it is implemented with QUIC, you don't have. And that's why I'm [00:21:00] still like in the momentum where I want to see where this is going. But I love the approach. I love the metal model. It's undeniable how it improves, for example, startup performance or. How you have things being progressive, things related to interactive, interactivity, loading progressively, and that kind of thing. Yeah, but the thing is, it depends on which kind of hydration you're talking about. Can we dive a little bit into the different types of hydration? So I've heard a lot about what is called selective hydration. I've also heard about progressive hydration. And I guess there's traditional hydration. So this is a bit of a sensitive topic for me personally, because I, as I gave the talk at React Nexus, where you were next a number of talks followed and my parents were in the audience and my mother leaned over to me and she was like, Hey, Tejas, can you explain to me what is hydration? Everybody keeps using this word. And so I had to explain to her. Hydration. And [00:22:00] I'm curious if you would do the same service for those listening specifically, I think the developers here listening, I think most would be familiar with hydration, you talk about selective, progressive and traditional, and I'd love if you could break down those concepts a little bit. Yeah. Yeah. When he does this whole thing I remember when your mom asked this question and that reminded me a lot of there's this tweet that is why are JavaScript developers so thirsty and talking about hydration and stuff like that. Before digging into this, I wouldn't say that traditional hydration is not a term perceived before. I don't want to create, I don't want to introduce a new kind of hydration by saying traditional hydration, but So first the whole idea of selective hydration and et cetera it's good to, to visualize this by grabbing one example from react. So basically if we remember how react was before react 18 with this concurrent features, umbrellas [00:23:00] and selective hydration, a lot of things that introduced. So basically we had this problem that in hydration reacted could only be after the entire data was fetched and rendered. And because of that, the users couldn't interact with the page until the process was complete for the whole page. And the bottom line is that parts of the app that they would. that in theory they could load faster. They have to wait for the slow ones. And then with React 18, they introduced this idea of selective hydration. That is, React was now prioritizing selecting the parts that the user interacted with to be hydrated before the rest. And the result is that by doing so, components could become interacted faster, especially because that also had to do with The concurrent rendering thing and et cetera. So the browser could do other work at the same time as hydration. And now React didn't have to wait for the slow components to ship[00:24:00] the markup for the fast ones. So that is like an example of selective hydration with React, but actually you can see some other related work out there with others. And then there is progressive hydration and it's crazy because the idea of progressive hydration and even the idea behind islands architecture, for example, islands are a new term from 2019 to 2020. But if you look back there's a post I always link people, it's from 2013, I don't remember the name of the guy, but it's basically building declarative components with the loader. js. So that was a decade ago. And. The model proposed there was really similar to what we call nowadays islands. So we would have those chunks of interactivity and then we could have a lot of things that are server [00:25:00] side rendered and shipped the way they are and then you would have isolated chunks of interactivity. And you could come up with different strategies for hydrating these that is what Astro by the way does these days, we have the directives, and then you decide if you want to hydrate things on load or depending on a certain condition to be met, that kind of thing. So I guess that's a partial hydration is a lot about that chunks of interact interaction that have like on. Strategies for when they should be hydrating, and then you have progressive hydration that is like more of how of when partial hydration is a lot about what progressive hydration is a lot about when you hydrate things. But in a lot of times you will see that these terms, they overlap each other or there's a solution that implements one of them or merges them. So it's sometimes it's a gray area, [00:26:00] but that's like the scene in hydration. I appreciate that. I appreciate that deep dive. Thank you for that very long and well thought through answer. So then, if I understand correctly, resumability. Is in a way close then to what we call progressive hydration because it loads or it doesn't hydrate at all. I want to get that very clear. I already see people getting upset at me and coming at me with water guns, no, but I think so resumability is not hydration, but resumability To people who maybe aren't looking as closely can feel close to either selective or progressive. I think progressive hydration, right? Because like what ends up happening is the element you interact with, you intend to interact with becomes interactive on demand with resumability. And am I right in saying that's a little bit close to what you describe as progressive hydration? Yeah. Because quick and the idea of presumability brought, [00:27:00] borrow the idea of progressive interactivity. So even though you didn't have hydration to call that progressive hydration, but you have the thing the progressive idea of making something that in a traditional, let's say like that hydration scenario would be eager and turn that into a lazy or when needed or that kind of approach. So Good. I'm glad. So I feel like for some people. I already see memes happening where it's this like Scooby Doo unmasking the villain of and the mask is Erasmobility, but underneath is progressive. I'm wow people are going to be so upset with me for saying that But I didn't say it. Mateusz did anyway, i'm joking totally joking. You talk you talk also in your talk about streaming SSR or streaming server side rendering. And this is a really interesting topic. And also it's frankly a buzzword. I feel like streaming that's not to say it doesn't have value. I'm curious if you could elaborate on that specifically. What [00:28:00] streaming is maybe even the HTTP level. I know, for example, that, All webpages that are just strings are streamed over HTTP. They're not necessarily rendered in one place as a finished blob and then sent over, but they cumulatively are transported over the network. I'm curious how that fits into SSR or server side rendering and maybe what are some of the trade offs there? Yeah, I love that you asked because in my opinion when react 16 was out A couple years ago, everyone was talking about hooks and people who were not talking about hooks, they were talking about suspense and these two were just great. But there is another thing that shipped with 16. It was the initial support for streaming SSR in react. But I feel like back in the time. Some people were talking about that, mostly library maintainers, because they had issues adopting I remember some people building, for example, [00:29:00] stylesheet libraries and that kind of thing they had issues for, with streaming. So library maintainers were the very few people talking about streaming when React 16 came out. And then we only started talking a lot about streaming and SSR in React when 18 came out. And then you, because then you have. Streaming combined with the selective hydration and the whole other thing of the concurrent react umbrella. So Basically to simplify, streaming allows you to load data over the network in multiple chunks. Um, It's a beta, I don't have the slides here, but when you visualize that through time, so you see like the chunks being downloaded and then the time it takes to parse and then to execute and etc. And then when you break that into chunks, you see how that improves some of your metrics, for example. Streaming is this idea, it started in 2017, it got a lot of traction last year. And there are a lot of interesting concepts when you talk [00:30:00] about that. For example, the idea that these chunks, they can be loaded out of order and parallel, so that's another way of optimization. And of course, if you are implementing them on your own, then you also because if you use next or some other matter framework, then a lot of these things, they just come out of the box for you to leverage, but otherwise, then you. See, for example, how that works under the hood and how that you, you have this pipe to node stream and then get to talk about node streams and et cetera. But yeah you mentioned that's working. One thing I would like to clarify is a lot of people when they see streaming and that kind of thing, they think that it's somehow using WebSockets. That's one of the questions I got after the session. Not after the session, but after some rehearsals. So is this using WebSocket somehow and et cetera. So that's one network in detail that you should pay attention to. It's not based on WebSockets or anything like that. [00:31:00] It's as you mentioned same thing over HHB and et cetera. Yeah, I think , part of the problem is understanding HTTP itself, right? Unless you explicitly close an HTTP connection, you could just keep it open and keep sending stuff across the connection. That could even be considered streaming, where if you have on your backend or server side, a stream that is a data structure that Emits data occasionally over time. This is also the definition for RxJS, a stream library. Then you just open an HTTP connection. And as data becomes ready on, over the course of time, you just send things over. And once your stream is fully consumed, then you close the HTTP connection. That's how I understand it anyway. And I see you nodding, so I think that's, that tracks. So what you're telling me now is with React 18, selective hydration and streamed SSR are just generally available, meaning I could build my own streaming server renderer if I wanted to.[00:32:00] Yes. You would check the documentation for. React server and et cetera, you would check the proper methods. You would have to proper use suspense and on the client, you would have to use pipe to node stream and that kind of thing. And if you're using like framework that is built on top of React 18 onwards, like next and by the way, they even have Vercel has a really good. Use case study on how they used concurrent umbrella with streaming SSR and selective hydration to improve some metrics of the web page for the next JS website. So in their case study, they were focusing in IMP. But the thing is with streaming you tend to be able to try to improve a lot of other metrics, like even time to first byte and that kind of thing. And another thing that people don't talk a lot about streaming is it's, and because you said you talked about building your own [00:33:00] stuff and et cetera, it's really interesting how streaming is a resource of handling server backpressure. So if you're server side rendering things and et cetera, and you get a lot of requests and stuff like that. It's usually not a problem because servers nowadays, they scale really well and that kind of stuff. But it's also an interesting part of training. It scales well on the server. Fantastic. Yeah, because of back pressure being this ability for the stream to. Slow down effectively if the client is full or the consumer, maybe I, or the sync, I think there's a technical term. Fantastic. Now we've covered a lot of things, right? We've talked about hydration. We've talked about streaming. We've talked about resumability somewhere in this soup, there's react server components, or maybe it's not in the soup, but around the soup. How does server components fit into all of this? So basically that was one of the last sections I added to my talk, because nowadays it's impossible to have a session on rendering strategies and not [00:34:00] talk about server components. But in my opinion server components could be a whole separate session and they are, by the way, you have a whole session for a minutes about them, but my session, the part about server components, I focus on providing like a brief overview and how they can be seen as a routing paradigm that is integrated with data patching and also bundling. And et cetera, and how this is quite different from SSR, for example, and how it could lead to significantly smaller bundles and et cetera, but also I focus on some other hidden benefits and other best efforts around server components, including, for example, and I have a side by side comparison, this slide that is just this project called Jaxer, and it was about a decade ago and you would Literally write script text and you would have an extra attribute called run at, and you could have client [00:35:00] or client and server or server. So one of the things I focus a lot is talking about past work on this idea of co location. What goes on server, what goes only on the client, what could go on both. And also focus on previous work in the React team, like the flight, what was called flight infrastructure a couple of years ago, that turned out to be server components. Yeah in my opinion, and I know like I could be canceled for saying this, but I still see like a lot of work in progress in the whole server components idea. So I myself, for example, haven't burst server components for production, fortunately, because I haven't had a chance. But the thing is, it's a very interesting compliment to server side rendering, and I'm really enthusiastic to see what's coming down the line. Not only in terms of React, but in Parallels server component initiatives, like the ones we were discussing the [00:36:00] other day at the effort. Waku by Daishi and other similar projects. So yeah. Interesting. You say it's a great compliment to server rendering, which tells me. It isn't server rendering, even though server components are rendered on the server. Yeah. I saw someone tweeting the other day that it just like some other things. This was like a terrible choice of naming. I'm not saying that, but I've heard multiple times this comment that people were confusing silver components with server side rendering. And other things, and then you have a lot of educational work to deconstruct this vision that is generated by the names of the components. But I'm not sure if I would have a better name for that as well. yeah I think there was Theo or someone on twitter who said They're called, he proposed a really, a better name, at least I think for client components, somebody, I saw the proposed interactive components, and this is pretty nice because then server components also, you don't make the [00:37:00] mistake of adding on click event handlers and so on in your server components, because what are you going to click on? It's rendering on the server. So that's a, that's an idea there for sure. Um, As we wrap up, I'm curious, I see you Mateus is some type of visionary always trying to forecast things and, with really profound accuracy. What is the future of rendering? I'm talking about things like routing, hydration, zero KB JavaScript. For example million. js is this new thing, right? Which is this really fast VDOM that is The fastest VDOM renderer on earth. Probably. I'm curious if you could speak to that and what you consider the future of rendering. So before moving forward that I do have a disclaimer. There is in not all of my sessions, but some sessions where I'm trying to forecast the future. I do have a picture of me in an iOS meetup that was like nine years ago. And literally in this meetup, I. I approached the iOS guys and told them, Hey, you know what, Angular and Ionic are going to be the future. So you should stop building native apps [00:38:00] and et cetera. And basically half of the audience was mad at me. So done by every, all of my forecasts but yeah it's crazy because I think that we are in a momentum that. We're going to see a lot of prediction, exactly predictions on why something is the future or on the other way, why this other thing is pure overhead. So a couple of years ago we had Virtual Dawn is pure overhead. And then for a while there was Svelte and then Solid and et cetera. And now there's a complete revamp with the block Virtual Dawn approach that MediaNJS has. So the future right now we'll have a lot of predictions, a lot of. Reasons why something is pure overhead and et cetera. One thing that I I think we'll see a lot is our new approaches to rendering related techniques. So MedianJS is a good example of a new approach to virtual DON. I [00:39:00] think we'll have also new approaches to the current approaches. So for example, here we discussed like three different types of hydration, not to mention resumability that is no hydration at all. And I remember I was watching one of Ryan Cremiato's streams the other day and he was mentioning something like that he called lakes architecture that I didn't quite get the graph, but the point is, I feel like we're going to have more and more approaches to hydration and these other techniques. And I feel like we're going to have a lot of discussions revisiting. Things like MPAs versus SBAs. Are we taking a full cycle on web development or not? So if I had to summarize, I feel and that's one of the things I focused during my session. A lot of things, they're cycling back. A lot of the ideas we had, a lot of the brilliant ideas we, and there's even a tweet, I think by then. That a lot of the brilliant things that we had in 2020, 2021 were actually implemented in Marco five or six years before. [00:40:00] So we'll be revisiting a lot of ideas from the past, but with some recent discoveries, and we'll be revisiting a lot of the decisions we took do we actually want to go from back to MPAs or SBAs or partially, that kind of thing. So that's my abstract prediction. I think it's important also to recognize that while we keep going back to things we used to do, we don't go back to them. Directly we go back and take the good stuff and leave the bad stuff. So it's not more of the same, but it's, it keeps getting better. And I think that's worth repeating quite a few times. Yeah, exactly. That's by the way, what I, in all the areas of front end, actually same thing with CSS and T Wind and et cetera, that people compare T Wind and Atomic CSS to a lot of things we had 10 years ago. And some of the ideas are actually from 10 years ago, but with a lot of evolution and a lot of lessons learned, I think it's the same thing with rendering patterns. Yeah, I [00:41:00] agree. . Hey, listen, it's been an absolute pleasure. As always, I could talk to you for hours and hours. In fact, we do and did in airports and on planes. But let's call it here. Thank you for all of the information. We covered how and where to render. We talked a little bit about web servers and build servers and hydration, for his mobility man. You're a treasure trove of. Engineering information. And I want to thank you for coming on the podcast and sharing this with the listeners. Thank you so much. It means a lot, especially coming from you. And it's always a pleasure to chat. Thank you, Matthews. Thank you for having me.