1. Introduction to Hydration and Off Islands
Today we'll discuss hydration, its challenges and issues, and the concept of off islands introduced by Jason Miller in 2020.
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.
2. Introduction to Islands and Their Benefits
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.
3. Introduction to Re-zoomability and Lazy Approach
Islands might not be a great fit if you end up with many islands and miss the point. Re-zoomability allows pausing execution on the server and resuming on the clients. OPA, Meteor, and Quik are examples of languages and frameworks that embrace resumability. Traditional hydration has an eager approach, while resumability takes a lazy approach. The client leverages deserialization to avoid redoing work.
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.
4. Resumability and Concurrent React
Resumability improves start-up and rendering performance by re-rendering only the change of components. Preloading critical page interactions and leveraging QUIC are recommended. Streaming-SSR, combined with Selective Hydration, allows faster interactivity and prioritizes hydration for user-interacted parts. This concurrent React approach eliminates waiting for slow components and improves overall page streaming.
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.
5. Introduction to React Server Components
React server components (RSC) were previously known as React Flight and were introduced in late 2020. RSC allows for ahead-of-time rendering during build time on a server and is integrated with data fetching and bundling. RSCs are similar to islands but do not have a clear boundary between server and client. The code for server components is not shipped to the client, providing better performance. RSCs also allow access to the backend from anywhere within the tree and can be refetched while maintaining client-side state. However, concerns remain about potential data over the wire and the orchestration of RSCs for framework and app builders.
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.
6. Introduction to Server Components and Co-location
RSCs bring an interesting discussion of co-locating client and server code. JacksR, a library from 2008, had similarities in coordinating client and server code. There's still much to learn about server components, with livestreams and side projects like Wacoo and TenStack Query. These projects explore colocation and extraction of client and server code.
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.
7. Future Trends and Holotypes in Rendering
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 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.
8. Reflection on Past Ideas and Future Considerations
It's important to consider what's different now and what ideas from the past have become lost arts. React draws inspiration from techniques like double buffering in the game industry and previous experiments with Marcos. Addressing the complexity of network conditions and device capabilities is a challenge, similar to the unpredictable screen sizes faced in responsive design. Trusting future predictions and speculations can be misleading, as there is no silver bullet. Identifying core metrics, including business metrics, is crucial for performance optimization. I'm a front-end engineer at Medallia, a teacher at Tech Labs, and a Google expert in performance.
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.