Hydration, Islands, Streaming, Resumability… Oh My!

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more

Our ecosystem can be overwhelming! First, we had the rise of SSR and SSG—and each had its own gigantic pile of frameworks and tools. Then partial hydration enabled us to hydrate only some of our components on the client, which we've seen in React Server Components. 


But what about islands? Do they relate at all to Streaming SSR? Moreover, what is resumability, and why do I keep hearing about it? […] Oh, did anyone say rendering on the Edge?


Well… There are many approaches out there, and all of them argue that their philosophy is best. In this session, we’ll go over these architecture/rendering patterns, to help shed some light on how some are implemented and the concepts behind them.

This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

Challenges with hydration include associating DOM elements with event handlers, updating app state, recreating the DOM hierarchy, and dealing with the uncanny valley. The uncanny valley is the period when the initial HTML is painted but interaction is not yet available, often due to slow JavaScript downloads, parsing, and execution.

Islands refer to the concept of selectively and progressively enhancing server-side rendered HTML with client-side JavaScript. This allows small, focused chunks of interactivity within SSR pages, often with multiple entry points. Tools like Astro, Quik, and Markle support this approach.

Resumability refers to pausing the execution on the server and resuming on the client without replaying and downloading all application logic. It improves start-up and rendering performance by leveraging deserialization and only running event handlers when necessary. Quik is a notable framework that implements resumability.

React server components are a feature that allows code for server components to never be shipped to the client, enabling access to the backend from anywhere within the component tree. They can be refetched while maintaining client-side state, and are integrated with data fetching and bundling. They are mostly leveraged by Next.js.

Using islands reduces the amount of JavaScript code shipped to the client, enabling faster page loads and better metrics like TTI (Time to Interactive). It also improves SEO by making key content available faster and allows for more specific enhancements compared to other progressive hydration approaches.

Concerns with resumability include the need to preload critical page interactions, which can lead to preloading a lot of content if many critical interactions exist. Currently, the only framework that fully supports resumability is Quik, which limits its adoption.

Advantages of React server components include the ability to never ship server component code to the client, access backend functionality from anywhere in the component tree, and refetch components while maintaining client-side state. This improves performance and user experience.

Islands differ from traditional server-side rendering by selectively enhancing parts of the page with client-side JavaScript, allowing for independent loading and hydration of these parts. This approach provides more specific and focused interactivity compared to traditional SSR, which handles the entire page uniformly.

Streaming SSR (Server-Side Rendering) allows parts of a web page to become interactive faster by prioritizing the hydration of components that the user interacts with first. It combines with selective hydration to allow the browser to do other work concurrently, improving metrics like TTI (Time to Interactive).

Hydration is the process of attaching behavior to declarative content to make it interactive. It involves associating DOM elements with their corresponding event handlers, updating the app's state, and recreating the DOM hierarchy. Hydration comes with challenges like the uncanny valley, where everything is painted but not interactive.

Matheus Albuquerque
Matheus Albuquerque
26 min
20 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Today's Talk introduces the concepts of hydration and off islands, explores the benefits of islands for enhancing server-side rendered HTML with client-side JavaScript, discusses the lazy approach of re-zoomability and its advantages over traditional hydration, highlights the use of resumability and concurrent React for improved rendering performance, examines the features and concerns of React server components, touches on the co-location of client and server code, and explores future trends in rendering and navigation. The Talk also reflects on past ideas and emphasizes the importance of identifying core metrics for performance optimization.

1. Introduction to Hydration and Off Islands

Short description:

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.

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.

2. Introduction to Islands and Their Benefits

Short description:

Islands are a way to selectively enhance server-side rendered HTML with client-side JavaScript, providing small focus chunks of interactivity. They allow for more specificity in enhancing the page and can be delivered and hydrated independently. There are various tools and frameworks available for building islands, such as Astro, Quake, Markle, Preact, Solid, and Svelte. Markle and Astro offer interesting combinations of features, including streaming, automatic partial hydration, and customizable loading strategies. Islands help reduce JavaScript code shipped to the client, resulting in faster page loads and improved metrics like TTI.

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.

3. Introduction to Re-zoomability and Lazy Approach

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

We'll be discussing routing, revisiting MPAs and SPAs, overcoming hydration challenges, achieving zero kilobytes JavaScript, and code extraction. The future may involve coordinating both client and server code, such as importing components with type clients. Solutions in rendering and navigation depend on the app's requirements. The Application Holotypes post explores different app types and their rendering and navigation approaches. The evolution of rendering HTML on the server has progressed from basic form submissions to pushing boundaries with initiatives like LiveWire, HotWire, and server components.

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.

8. Reflection on Past Ideas and Future Considerations

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.