Hydration, Islands, Streaming, Resumability… Oh My!

So, hello, London. It's just great to be here at this amazing conference again. And, yeah, I'm Mathias Apkarky, and today we're here to discuss about hydration, islands, streaming, resumability, and, wow, we should probably start, right?

So this is what we wanna cover today. We'll talk a little bit about the past and the future of things. And then we'll go to islands, resumability. We'll also talk about streaming SSR and how it combines with selective hydration. We should talk about React server components, right? And then we'll draft some closing thoughts on top of things.

And let's just start with hydration because, yeah, we wanna cover that. So if you're not familiar, I love this definition by Mishko, that hydration is the process of attaching behavior to declarative content to make it interactive. And hydration comes with a few challenges. So first, and obviously you have to associate the DOM elements with their corresponding event handlers. But also as a user, for example, triggers one of these handlers, you want to update the state of your app. And not only that, but once the state is updated, your framework needs to recreate the DOM hierarchy and everything. So hydration comes with challenges and hydration also comes with issues. And that's one of the most common ones. It's called the uncanny valley. And it happens exactly, so you got your initial request, you got your HTML and then you have your view painted, but then you have to wait for to arrive, to be executed, parsed, and everything. So the uncanny valley is this moment where everything is painted, but you don't have interaction, which is bad. And if we break down, it all starts, for example, when we get the HTML. And that's mostly fast, of course, but then you have to download JavaScript, and that can be slow depending on the network conditions of your users, as you probably know. Also, you have to parse and execute JavaScript. And that can be also slow depending on the capabilities of devices of your users. And also on the amount of JavaScript you're sending over the wire. And last but not least, your framework also has to recover, state, and bind all the listeners. And that can be slow depending on, for example, the amount of done nodes you need to go through. And also the amount of references that you need to rebind to those listeners. We could be here the whole day talking about the challenges and the issues with hydration, and you also have a lot of interesting posts out there. But the point is, throughout the years, people were trying to think of creative ways to fix or address, at least some part of this problems. And it was in 2020 that we started to listen a lot about the term off islands. And we got this name from this post by Jason Miller, the creator of React and also the creator of other amazing open source stuff.

But if we dig a bit back in time, we find posts like this. So this is called Declarative JS Components with Vloader.js. And it was posted back in 2013, and it was about the idea of attaching JS behavior to chunks of HTML. So you can see that people were thinking about something like that.

And that's what islands are. You are selectively and progressively enhancing bits of server-side rendered HTML with some client-side JavaScript. And you have small focus chunks of interactivity within those SSR pages. And it's a bit of a mind shift, because you're going from this model where you have a single app in control of the full rendering of the page. To a place where you have actually multiple entry points. Also, usually with an island, this script for the islands can be delivered and hydrated independently. And it allows the rest of the page to be just a static HTML. But differently from other approaches to progressive hydration here, you have more specificity around how this enhancement occurs.

Another thing great about islands is that these days we have many ways to leverage them, so we have stand-alone implementations like Astro, Quake, Markle, and many others. And you can also use different tools to do islands with Preact, with Solid, with Svelte. And one interesting thing about islands is Markle. So Markle was there since 2014, it was open-sourced a few years later. But Markle shipped with this very interesting combo of streaming, with automatic partial hydration, and a clever compiler that would basically generate optimized code depending on where it was going to run on the client and on the server. Markle also had automatic partial hydration that basically allowed those interactive components to hydrate themselves. And the hydration code, of course, was only shipped for the components that needed interaction. Years later, we got Astro, and most of you heard about Astro, so in 2021. And Astro again had a very interesting combo. So by default, it was shipping 0 JavaScript, and every island could be loaded in parallel. Markle was also multi-framework, so you could build islands with React, Preact, Vector, and many others. And Astro allowed you to specify the loading strategy for each of your islands. So for example, if you're using a React JSX component with Astro and you're importing it, and etc., you can do things like this. So you can specify if that's going to be hydrated upon loading or when the browser's idle or only when your component gets visible. And you can do even more complex stuff.

That's what's great about islands in general. You're reducing the amount of JavaScript code that is shipped to the client also you can get faster page loads and better metrics related to that like TTI and others. And overall, you're making the key content of your site or your app available faster to the user.

Not to mention that you're getting the traditional benefits of SSR like improved SEO. Where I see that islands might not be a great fit is depending on the amount of interactivity you have, you might end up with dozens or hundreds of islands and then you might be missing the whole point.

Also in 2021, we got re-zoomability. And I think that a good way to think about the model of re-zoomability is if we picture that a lot of the things we have in the isomorphic landscape these days, they started on top of frameworks that were not initially fought for that. So for example, this is a post from 2013 where the Airbnb team was experimenting with server-side rendering backbone. And if we remember at the time, that's mostly what we had. People were experimenting with server-side rendering Angular or React or other frameworks. But what if we did the opposite? What if those frameworks, they started with server rendering in mind in the first place?

In 2011, we had this language, OPA. Has anyone ever heard of it? Okay, not us. One hand, wow. So OPA went way beyond just partial hydration. So you basically wrote programs and the compiler would slice client and server concerns for you. And that was amazing. Years later, we got Meteor, which had some of that in mind and also got some traction. And in 2021, we got Quik, which probably most of you heard about. So that's the idea of resumability. It's about pausing the execution in the server and resuming on the clients without having to replay and download all of the application logic. So pretty much it. Do some work, pause, resume where we left off. And you use what happened during the execution on the server to avoid extra work when the app boots in the browser. Also, it does that by attaching global event handlers at startup time, but only running then when it's necessary upon interaction. If you compare that with traditional hydration, I'm not talking about progressive or selective none of that, with traditional hydration, we have an eager approach where the event handler creation happens before those are called or triggered. Also, things are a bit more speculative. So all of them are created regardless whether they are used or not. And you also have the client redoing work and the framework has to download and execute the components to figure out their hierarchy. With resumability, you have the opposite. So you have a lazy approach where the event handler creation happens after the event is triggered. And also only the triggered events are the ones that are created and registered. So this happens as needed. Also, the client is not redoing work because it leverages a lot of deserialization.

So yeah, it requires a lot of important information to be included in the HML. If you're interested, there's this very great stream with Ryan from Solid and Mischka where they ideate the whole idea of resumability for a couple of hours. But that's what's pretty much great about resumability. It tends to improve your start-up performance and basically, also your rendering performance because it ships with other cool ideas like for example, only the change of components are re-rendered. Also, it brings fine-grained laced loading and progressive interactivity.

What concerns me about it though is that it's a best practice to preload your critical page interactions. So if you happen to have a lot of critical page interactions, you might have to preload a lot of stuff. Also, the only option we have these days to leverage Resumeability as it is defined is QUIC. So most of the discussions around it are in the QUIC community and builder.io itself, even though some people would argue that Marcoversion 6 brings something similar to Resumeability. But anyways, I have to say that I think that QUIC is a perfect example of outside-of-the-box thinking that sometimes is needed to fix issues in the web.

At the same time, it started in 2017, but it got more traction in 2022. We started talking about streaming things and then selective hydration. So Streaming-SSR was actually shipped with React 16 and only few of us were paying a lot of attention because we were discussing hooks, Suspense, the new Context API, and a lot of other cool stuff that also happened during React 16. Some people were leveraging Streaming-SSR at the time, but it got more traction after, mostly last year, after it was combined with Selective Hydration and other cool things from the concurrent React umbrella.

And it's good if we see how things happened before. So before React 18, hydration could only begin after the entire data was fetched and rendered for your page. So because of that, your users, they couldn't interact in the page until the hydration process was complete for all of that. And the bottom line here is that the parts of the app that were fast, they ended up having to wait for the slow ones. So it looks like this. All of these are sequential and blocking steps. So we fetch the data on the server, we render the HTML in the server, and then we get our first byte. And then we load it on the client, and we get our FCP. And only after hydrating, we get our first, our TTI. With StreamySSR and selective hydration, we can turn things into this. And now, React is going to prioritize hydrating the parts of the app that the user interacted with before the rest of the page. And because of that, components, they can become interactive faster by allowing the page to do other work, allowing the browser to do other work at the same time as hydration, because it's concurrent React. And of course, React no longer has to wait for components to load to continue streaming the HTML for the rest of the page. And when that specific part is available, it's going to be streamed and inserted in the right place by Script Tag. A lot of companies, by the way, they build interesting cases around this. Vercel has some numbers how they improve the Next.js website, some core web vitals in the Next.js websites by using that, including their INB.

So you might want to check it out. And then a year later, we also start to hear about React server components, which is funny, because if you've been watching discussions, it was there for a lot of time under the name of React Flight. So we just discussed the F things, like forget. So it was React Flight in 2018, 19. And then, in late 2020, we got this post introducing 0-bundle size React server components. And after that, it was a lot of the community, us, the team, like how did this piece together with suspense, transitions, and et cetera? So in my opinion, a good approach to get a grasp on server components is to think of them as if you could have ahead of the time rendering that can happen during build time on a server. But it's also a routing paradigm that is really integrated with data fetching and even with the whole way you bundle things. And as it might seem, it's not necessarily related to SSR or even hydration. Since we discussed islands, we can say that actually RSC is really identical to how islands work. But the thing is, when we were doing islands with Astro, for example, we had a clear boundary, what's Astro and what's React. With server components, we don't. That's why we have things like used client. Used client is marking a boundary between these two module graphs, the server and the client one. And of course, with RSC, each component can decide whether it's going to be a server component or a server plus client component. And I think that three things are amazing about RSCs. The first and, of course, probably what you hear mostly is the code for the server components is never shipped to the client, which is actually great because in a lot of SSR implementations we have these days, we end up having code bottle and sent over the wire. The second thing is, you get access to the back end from anywhere within the tree. And a lot of people see this as a bad thing, but actually, it's amazing. Imagine what you do with Next.js, for example, that at page level, you have things like get server side props, but now from anywhere within the tree. And the third thing is probably what I love the most is, those can be refetched while maintaining client side state inside of the tree. So think of an input components that you can refresh, re-render, but maintain, focus, hovering, that kind of stuff. So Ben prepared a really good example in this RC from scratch post. So this is an example of navigation without server components. And you can see that when you navigate, you lose the state. And here is the same thing, but with server components. And you can see that you navigate. And the state is not blown away. What concerns me about server component is that perhaps we might have situations where we get a lot of data sent over the wire on every re-render. Also, both from the perspective of framework builders, but also app builders, this orchestration of how this is going to work. And the final developer experience for me is still blurred.

But a lot of things about it are still experimental, in the end. And you have few options to leverage RSCs, mostly Next.js with the app router. But for me, RSCs bring a very, very interesting discussion that is this thing of co-locating client and server code, and how that's probably going to be the future. And it reminds me a lot about this thing called JacksR. Does anyone here know JacksR? Cool. No one. So JacksR was here back in 2008. And here's some of the official examples of using JacksR. But I want to highlight this script tag where you had this runAt attribute. And you could specify, for example, runAt server or runAt both. And if you put side by side the documentation from that library from 2008 and the state-of-the-art documentation, for example, with server components, you will see some similarities. Of course, they're not the same thing, but you can see that the idea of trying to coordinate the two was there. Anyways, I think that a lot of us, myself included, still need to learn a lot about server components. We had very interesting sessions. After me, Tejas is coming, and I'm pretty sure he's going to cover it really well too. There's a lot of livestreams on the topic you might want to watch, and also a lot of interesting side projects involving it. Wacoo, by Dai Shikado, is one of them. Where he's basically building his own implementation of RSCs. And you even have implementations in other ecosystems, like in Go, or even OCaml. And there is TenStack Query, TenStack Blink, sorry, by the same creators of TenStack Query and others, where you don't have RSCs per se, but it's a very interesting project to play with colocation and extraction of what's client, what's server code.

Wow. We covered really quickly a little bit of hydration, resumability, streaming islands, et cetera. And I feel like we could be here the whole day talking about a lot of other things when it comes to rendering patterns, but I wanna jump and talk a little bit about what I think is coming down the line.

So, yeah, I had to use a meme. But I think that we'll be discussing a lot routing and revisiting this whole thing of MPAs and SPAs, and where we wanna handle navigation, and revisiting this community decision of moving towards SPAs we had a decade ago. We'll also be discussing a lot about hydration and new and creative ways to overcome the challenges of hydration. We'll be discussing a lot whether we wanna have zero kilobytes JavaScript or not, and how to do so. And I think that we'll be discussing a lot code extraction. And as Dan pointed out a couple of years ago, I think that the next wave of technologies is gonna be about coordinating both clients and several code in a very, very fancy, in the best way possible. And have you seen, for example, this import attribute thing? It's an Akmah proposal. It just made it to TypeScript as a language. And with that you can do, for example, import JSON with type JSON. So I wonder if in the future, for example, we won't be able to do things like important components with type clients or both. I would love to see something like that. And more than ever, we'll be talking about why a given technology is the future.

So a few closing thoughts. As you probably notice, when you find a solution to your problem, you're probably just changing the problem that you have. And while a lot of these solutions, they seem competitive, I think that most of them are actually complementary. They don't solve the same issue all at the same time. Instead, they focus on different parts of the same problem. And that's why the same pattern can be good or bad, depending on which app, which part of your app, et cetera, which case you have. That's why I really like this thing. It's a post called Application Holotypes by Jason Miller, where he basically explored the different kinds of apps you can build, like a social network, an e-commerce, et cetera. And he proposes, OK, how do you want to build rendering for that? How do you want to build navigation? And Ryan Corneado even expands a bit more on that, talking about, for example, how do you want to do hydration? How do you want to do routing for each kind of these holotypes? So I really like it.

Another meme, and I think it's easy to think when we see all these examples with the app router, for example, and these new technologies, to think that we're just going back to rendering HTML on the server like we did back in the day. But the thing is, with PHP and Rails, the boundary, basically they were rendering that HTML and taking form submissions, and that was pretty much it. Years later, Marco tried to push the boundary further, but I guess most of us were busy building SBAs. And then, more recently, we had the PHP in the Ruby community and the Elixir community initiatives like LiveWire, HotWire, and et cetera, where they tried to push this boundary, but coming from a back end background. I think that quick and server components are an interesting attempt coming from a front end background to push this boundary while fully respecting what's client and what's server concerns. Also, as you probably noticed, software development is always going through cycles.

And it's important that we think that we're very likely not the first ones trying something. So it's important that we think, what's different now? And what was a great idea in the past and just turned into lost art? And I have two examples on that. The first one is this tweet by Andrew, also core committer of React, where he pointed that a lot of how React works with fibers and the whole tree comparison mechanism, et cetera, it brings inspiration from this double buffering technique that's been in the game industry for decades. And the second example is that when Dan posted that a lot of the cool things they were experimenting with React back in 2020 they were figuring out in Marcos back in 2014. And this post from Marco's team that he links links to another post that was posted back in 2005.

I agree it all sounds really complex, and I think it should, because we're trying to address a complex problem that is the variety of network conditions and device capabilities of our users. And if we think about back in the day of responsive design, we had a similar challenge. In 2010, we had to face an unpredictable amount of screen sizes, screen resolutions, and et cetera, so complex solutions for complex problems. That's the last one.

So you know what they say that a picture is worth 1,000 words. So this is me about a decade ago, and I was in this iOS meetup, and I was so hyped about Ionic back then. And I told them, you know what, stop building those native apps and just start using Ionic, because Angular's going to be the future. And here I am trying to talk about the future of React to you. So yeah, don't always trust those feature predictions and speculations and et cetera, because the cliche is true. There is no silver bullet. That's why it's important that you do identify your core metrics, and not only things like web vitals and et cetera, but actual business metrics, bounce rates, conversion rates, et cetera. Those performance metrics, they are important when they are matched with your actual business metrics. This is me. You can find me everywhere as wide accommodator. I'm a front-end engineer at Medallia. I teach front-end students at Tech Labs, and I'm a Google expert in performance. The links for this session and other sessions I have about internals of React, performance optimization, et cetera, you can find here. Thank you so much. I think we'll have like four minutes for questions, so thanks for having me. Thank you.