Modern Approaches for Creating Extremely Fast Websites

Rate this content
Bookmark

In this talk is focused on performance-optimizations and standards-based approaches to achieving the fastest version of your site that you can have. We'll also talk about modern tooling and frameworks like Remix which help make your site fast with very little effort.

24 min
02 Jun, 2023

AI Generated Video Summary

The Talk discusses performance optimization in software development and engineering. It covers topics such as optimizing requests, anticipating future needs, and comparing single-page apps to multiple-page apps. It also explores the advantages of single-page apps and the use of Remix for building pages. The Talk emphasizes code splitting, optimizing data fetching, and solving client-side state. It concludes with a discussion on pre-rendering, Remix adoption, and prerendering with React.

1. Introduction to Performance Optimization

Short description:

Hi everyone, I'm super happy to be in Amsterdam. I teach React on a pretty regular basis and love it. Let's talk about performance. The fastest requests you can make is the one that you don't make at all. But what if you do need to make a request? Let's only get what we need. Anticipate future needs and fetch things in advance. Pick and choose what works for you. Get it nearby, like from a cache.

Hi everyone, I'm super happy to be in Amsterdam. It's been real fun, and thank you for having me. My name is Brad Westphal, I work at React Training. I teach React on a pretty regular basis, and I love it.

Let's do some cool things. I came up with this talk, like a lot of speakers do, you have like a general concept, and you don't really know exactly how you're going to make it or what direction it's going to go in, but I knew I wanted to talk about performance. I didn't know if I was going to talk about DOM rendering performance, or maybe animations, or all of the above, and make it just a big scatter of everything.

I started asking around, and I asked some friends and some people on Twitter and stuff, what do you think of when you think of website performance? This is one of the more common responses that I got. The fastest requests you can make is the one that you don't make at all. Have you ever heard that? Whenever I hear this one, I kind of do a little bit of a, like, what? Okay, that's kind of philosophical, they kind of mic drop and walk away, like, there you go, there is performance. But we're in the business of making websites. That make requests. I can't take away all my requests. It's not really practical.

So, I started thinking about this and I thought, okay, that's fine. If that works, if that helps. But, what if you do need to make a request? Because we're all going to need to do that. So, that's what this talk is about. Let's maybe only get what we need. Pretty simple? Sounds good. Okay. Advice. Moving on. Maybe anticipate future needs. For example, fetch things in advance when you think that you're just going to need them. Sometimes it might seem like these two are a little bit at odds with each other. But you kind of pick and choose whichever one works for you in this situation. Of course you're going to want to get it nearby. Like from a cache. That would be nice.

2. Optimizing Requests and Anticipating Future Needs

Short description:

Sometimes you need to request two things at once. And if you do that, I think we should try to do them in parallel. Only get what you need. Lazy loading images can make a website faster. Anticipate future needs by pre-rendering content.

Sometimes you need to request two things at once. And if you do that, I think we should try to do them in parallel. And don't let the slow thing hold up the fast things. So let's start right here.

If you need to make a request, only get what you need. Let's just start with something that's more standard and not so much React. With images, I'm sure most of you know, this has been around for a little bit now. We can do lazy loading, which is really great. So below the fold, if you can identify certain images as being something that doesn't necessarily need to be loaded. Maybe this is the fastest request you can make is the one you don't make at all, maybe. But only get what you need. Things that only need to be loaded when the user needs them. So the user scrolls, they get the image, very good. Okay. So that's what I'm talking about. Things that you can do to make a website just a little bit faster.

Anticipate future needs. A standard example of that would be maybe this is one that you haven't seen. Link, pre-render, lowercase l. This is not a React component. This is a standard HTML thing. I know, funny, right? Okay. So this is something that you can maybe use. If a user visits your site, whatever page they land on, imagine anticipating very easily what page they're going to go to next, because you probably have an idea, and you're downloading those pages behind the scenes ahead of time. And then the user visits the second page and then you're downloading the third and fourth possible pages they might want to go to. So this is really nice. MDN describes this as when the user navigates to the prerendered content, the current content is replaced by the prerendered content instantly. This is nice. You know why? Because it makes me feel like it makes me feel like the user is getting an experience like local development. Like, we all get the best version of our websites, right? Because we're doing local development.

3. Comparing Single Page Apps and Multiple Page Apps

Short description:

It's superfast. Let's compare building a classic multiple page app versus a single page app. The single page app responds sooner, but the multiple page app has a fully formed HTML file. The multiple page app fetches JavaScript for events, while the single page app fetches data. Requests in a single page app may be far apart and need to be done in parallel.

It's superfast. And then you put it on the network, on the internet, and it's a little bit slower, and you just kind of tell yourself, well, it's the internet. That's how it is, right? But it would be really nice, ideally, if we can have a superfast experience for our users like we have locally. That would be the ideal, I think.

Okay. So these two things. Let's compare what it's like to build a classic multiple page application versus a single page app. I'm sure a lot of you are familiar with single page apps because that's been the popular thing for like 10 years. But I've been around long enough to remember what it was like to build the multiple page apps and the burdens that they had. There's a tradeoff between these two things. Let's build this in layers. So we might have a main layout, like a sublayout, and a page, like a lot of these types of apps would have.

Okay. So let's kind of imagine what the network requests are going to be like for the different users that are visiting the same application. The first thing that might happen is the single page application user is going to get an immediate response from the server, but it's going to be mostly a shell of an HTML file. In the meantime, the multiple page app user hasn't gotten any HML because it's all being built on the server. So what's better? I don't know. Maybe it's subjective. Maybe too early to tell, but if we have to give out a trophy at this point, maybe because the single page app did respond a little bit sooner, maybe we award the trophy over to the single page app.

The next thing that probably happens is the multiple page app gets a fully formed HTML file while the single page app is still getting JavaScript, and then we have to build the HTML. But are these two things equal at this point? Not really, because the multiple page app user is experiencing a fully formed HTML file while the SBA user is getting loading spinners. So maybe we flip this around. Maybe the multiple page app is a little bit better right now. Now, the multiple page app does have to go and get JavaScript, but this is probably just for events. And so it really didn't diminish the user's experience too much. And then at the same time, the single page app is fetching data. Notice the distance here? Where was the data fetched when we were in the multiple page app? It was on a server talking to another server. They could have been right next to each other, right? Ideally, they could be near each other. With single page app, they're probably far apart, and you have to do the same number of requests, probably, if you're doing RESTful type of backends. Some of these requests can be done in parallel, sometimes.

4. Optimizing Single Page Applications

Short description:

Single page applications are prone to waterfalls because we're fetching within the components. Ideally, we would like to do these in parallel with each other. React Query and the new React router can help with this. However, building a single page app requires more work in terms of over-the-network traffic compared to a multiple page app.

But oftentimes, they're done in serial, creating the classic waterfall. So single page applications are prone to waterfalls because we're fetching within the components. Ideally, we would like to do these in parallel with each other, which you can do. There's things like React Query to help out with this. There's things like the new React router, which you can use the two of them in combination with each other, which is probably the best way to do single page applications, I think, for data fetching. But you can fetch data in parallel with the new React router, because it's not fetching from within the component. So that's nice for single page apps. But ultimately, it does take more work to build a single page app as far as over-the-network traffic than it does a multiple page app.

5. Advantages of Single Page Apps

Short description:

Multiple page apps lose when we want to go to page 2. Single page apps allow for state persistence and fast content. They provide less waterfalls and enable writing UI logic once. Link preload and pre-render are not applicable to single page apps. Building necessary UI and maintaining consistent state are advantages of single page apps. A hybrid approach combining the best of both is possible with Remix.

Okay. So multiple page apps we're winning until we want to go to page 2. This is the reason why we like single page apps, because with a multiple page app, JavaScript shuts down. It's very sad. We can't do state, persistent state, in the client when this happens. This is why in the jQuery days, where would we put our state? There was no Redux or state management libraries back then. Did anyone ever do those 2000s jQuery sites? You would put the state in the DOM.

So page 2, we have to build everything again, everything we already had. We already had all this stuff, and yet we're building it again now, it's almost like a page refresh. I mean, it really is. A page refresh. Okay? The single page application just says, oh, you want to go to page 2? Okay, bam, bam, let's just go and get page 2. So I think that this is a win for single page apps. We like aspects of both of these though, right? We like the fast initial content. We like the client side navigations over here. But over here, we like the less waterfalls, and over here, we like writing UI logic once. I mean, depending on how you're building your multi-page app, if you're doing one technology on the backend and then JavaScript on the frontend, sometimes that can be different than doing it in JavaScript on both sides. Remember these link preload things, or pre-render things that we were talking about? The reason why maybe some of you haven't heard of this is because you can't really use this on a single page app. It wouldn't even make sense because you're gonna do client-side transitions. So that's something that we get over here. What about only builds the necessary UI? We had to go back and rebuild everything all over again, right, when we did the multiple-page app. And finally, states in the frontend. Sometimes you need consistent, persistent state. And so it's nice to be able to do JavaScript and not have it reset in between page transitions. Okay. So for ten years, it felt to me, at least, like you kind of had to be in one world or the other. And today you don't. You can do a hybrid of the best of both. That's really what this talk is about. We're gonna talk about Remix.

6. Building Pages with Remix

Short description:

But it's not even really about Remix, because a lot of these hybrid concepts would also apply to Next or any of the other JavaScript frameworks that might be doing hybrids as well. Let's build this page with Remix conceptually. It's made from three layers: main layout, sublayout, and page. These three loaders are running in parallel, fetching data and giving their contents to their respective components to collectively make an HTML file. The JavaScript in this framework is a manifest file that knows everything about the page, including the components that built it and the option to transition to another page.

But it's not even really about Remix, because a lot of these hybrid concepts would also apply to Next or any of the other JavaScript frameworks that might be doing hybrids as well.

Okay. So let's bring in the framework. Let's build this page with Remix conceptually. And let's see. It's made from three layers. Right? So we've got a main layout. We have a sublayout. And we have the page. So you build different files for this, just like you would in Next. And there's a loader function, kind of like the get server side props, that would run only on the server.

So this is us making the request to the homepage, and it took three components to make the homepage. So these three loaders are running in parallel with each other, fetching data, giving their contents to their respective components, all together to collectively make an HTML file and return that. So at this point, it's really not all that different than... Well, it really isn't different than a multiple page app. We still gotta go and get JavaScript. Right? But what's in this JavaScript? This is where things start to change. Is it just events like the classic multiple page app situation? Not really. Is it every possible UI that we might ever want to go to, like a single page app? Not really. Because neither one of those is really ideal. So what is in here? This is a... We call it a manifest file. And it knows everything about the page that we're on, including the different components that built this page and if we were to go to page 2, because we have the... We know that page 2 is an option, because we have the links that we use to build page 1. It knows that if we were to transition to page 2, that we don't need everything all over again, because page 2 uses the same main layout and sub-layout, so theoretically it would only need page 2 information. So does that mean we have to do a whole page refresh, like a multiple page app, and just get that? Well, no, not really. Now that loader that was the thing that was used in conjunction with the component on the server to build HTML, now that loader can be duly used as a RESTful endpoint. When you want to click to go to page 2, this is going to be a client-side transition where we send back... We'll do two requests in parallel. We send back data from the loader and the JavaScript code to make that component.

7. Code Splitting in Single-Page Applications

Short description:

A single-page application that's already doing code splitting for you, and you don't even have to think about it. Not to mention it's doing code splitting in a way where it gets both those things in parallel.

Which is just a file, so it's cacheable. And now you're on page 2. So it's like a single-page application at that point. A single-page application that's already doing code splitting for you, and you don't even have to think about it. Not to mention it's doing code splitting in a way where it gets both those things in parallel. What would happen in theory if you were doing a single-page application and you wanted to code split one of your routes? You would have to go to the server to get that file, bring it back, it now wants to do some use-effects stuff, which would require a serial request back to the server to get data. This is all happening in parallel, because we know the whole story. Remix is built on React Router, and React Router knows the whole picture. Which is really nice.

8. Optimizing Performance with Remix

Short description:

Anticipate future needs and fetch them in advance. Remix can do a link prefetch intent, giving a few milliseconds head start. Prefetch render allows downloading contents for multiple pages in advance. This is faster than static websites. Caching data closer improves performance. Remix can be hosted in any JavaScript server environment, like CloudFlare and WebWorkers. No need for a CDN, as Remix is already as close as a CDN with JavaScript running.

Okay, so anticipate the future needs and fetch them in advance. Okay, so everything that I've explained is already pretty nice. But what if we hover over a link? Merely hovering over it, React... Sorry, Remix can do a link prefetch intent, and hovering over it will already start this process. So, it will give you just a few milliseconds of a head start. And that's kind of cool, but you know what would make it really fast? You can also do prefetch render. And being on page 2, and we're already downloading behind the scenes, all of the contents for page 2, 3, and 4. Or 3, 4, and 5, I should say. But this is not like the standard one that I showed you a second ago, that would have... For a multiple-page app, would have gone back and gotten full payloads of HTML and had them like primed and ready. This is just getting the bits and pieces that we need. This is maybe faster than static websites. At this point. Can it be faster? Well, if you're getting this prefetched data from across the world, that's one thing. But what if we cached it a little bit closer? Now you can get this prefetched data nearby. Could we make it even better? One thing that Remix can do is it can be hosted in any JavaScript server environment. I specifically didn't say node. So places like CloudFlare and WebWorkers are doing things like V8 in the servers at the edge. You can host Remix there. You don't even need a CDN at that point because you're already as close as a CDN would be but with JavaScript running. Could we make it even faster?

9. Optimizing Data Fetching with Remix

Short description:

With Remix, you can prioritize important data like user and products, and start the response early. The HTML page is fully formed and displayed to the user, and when the comments resolve later, they are streamed into the page with a loading indicator. This approach makes websites incredibly fast.

So let's say there's get user, get products, and get comments. Ordinarily you would run these in parallel which means you are waiting for the slowest one to finish before you construct the HTML page and return it, right? But one of the new things you can do with Remix is you can designate one of these as being not as important as the other one. So what if get user and get products are more important and they happen to resolve earlier? Why should we hold up what the user sees until we get the comments when the comments aren't as important? It would be okay if we had a loading indicator just for the comments but we had the real data showing for these other two. So what you can do is designate these two and you can start the response back early. Then the user is looking at an HTML file that's fully formed, SEO enabled and all that, and then when get comments resolves a moment later, it can be streamed into the position that it would have gone in on that page with a loading indicator.

10. Streaming and Deferring in Remix for Fast Websites

Short description:

The user can view a fully formed HTML file while waiting for the comments to load. The comments are streamed into the page with a loading indicator. Remix allows mixing promises into the page, making it incredibly fast. The client uses a loading indicator while waiting for the streamed results of the comments. Reacttraining.com has achieved a performance metric of 100. With prerender prefetch, the validity of the prefetch page depends on how caching is set up.

Then the user is looking at an HTML file that's fully formed, SEO enabled and all that, and then when get comments resolves a moment later, it can be streamed into the position that it would have gone in on that page with a loading indicator.

So here's what that ends up looking like. This is Remix and we have our loader and our component. So imagine we have this promise that is waiting for get user and get product. We have the awaits keyword there. Notice the next line of code is interesting. Get comments is returning a promise, but we're not waiting for it.

So we did have to wait for the first line of code to finish before the second line of code ran, but we're not in serial waiting for the comments. We're just immediately getting the promise and returning this thing called defer. Normally in Remix you return a function called JSON. But if you use defer, you can mix promises into this, and then it's like we're building the page from objects and arrays, whatever user and product is, but also a part that is a promise.

Now, you use the user and the products as normal, and you use the promise in this thing called await. You put it in this resolve. Once it's ready. So, this is all right now being built on the server, but it's been shipped up to the client at this point. And now the client is using a loading indicator while it waits for the streamed results of the comments. Pretty cool. This is what I've been building websites in lately, and it's been really fantastic. It makes websites incredibly fast. I just checked Reacttraining.com a few hours ago to see what its performance metrics were. They had 100, which is funny because in the States they had 98 or something, but they had 100 here. So, that's great. Anyways, hope you enjoyed. Thank you very much. Thank you.

Oh, a lot of good prerender questions. With real prerender prefetch, how long is the prefetch page valid? You just set up caching the way you want to in that response so you get to figure that out however you want. Great. Easy. Cache as you would.

11. Solving Client-Side State and Pre-rendering

Short description:

Remix solves the drawback of needing and sharing client-side state across routes by using classic context providers. The page transitions are client-side, so JavaScript is not dumped and reloaded. Regarding performance, I haven't used the worker API for fetching data behind the scenes. If you have a products overview page with many products, you may experiment with pre-rendering and streaming content below the fold. The pre-rendering on Hover is done behind the scenes with an Ajax request.

How has Remix solved the, quote, drawback of sometimes needing and sharing client-side state across routes? Client-side state across routes? You can use classic context providers. The page transitions are client-side so they're not gonna dump your JavaScript and reload it, so that's how I do it. There's other ways I'm sure, but that's how I've been doing it.

Speaking of performance and techniques for that, would you recommend, or have you used the worker API to fetch data behind the scenes? I haven't, so I don't know that much about that one. Sorry.

Okay, if you had a products overview page, say, and this page had 100 plus products and each product had their own page, should you pre-render everything? I don't know, if it's going to be like, if it's going to, I might experiment with it, but if it's showing like hundreds of products per page, maybe you separate on the server into that deferred value and have some things get loaded kind of ahead of time, but things below the fold could be streamed up. Maybe I would experiment with that, and then I'd probably just experiment with some other approaches. I don't know the perfect answer for that one because that sounds to me like architecture that you shouldn't have a perfect answer for something unless you play with it. So I would play with it. Maybe like an intersection type thing? Yeah, something like that. At some point on scroll? Yeah, that sounds good. I think... You want to return something so it's good for SEO. Yeah, exactly. But maybe if you can't see everything in a way. But you can't see everything when you first load the page, it's below the fold. So I mean, the user's going to think that everything was there. They're going to look at a few things. They're going to start to scroll. Those things are going to just be there and the images will be lazy loaded too, right? Yep. There you go. That sounds good to me.

Is the pre-rendering on Hover being done server side or client side? If the latter, won't moving the mouse everywhere slow everything down? Well, it's fetching things behind the scenes. So I mean, if you're on any big website like Twitter or Facebook, I mean, if you want to go to the network tab, it's always going to be doing all kinds of things behind the scenes. So I don't think it's really slowing things down. But when you go to Hover over something, we're just doing an Ajax request to get something.

12. Pre-rendering on Hover

Short description:

Is the pre-rendering on Hover done server side or client side? It's fetching things behind the scenes, so it doesn't significantly slow things down. Hovering triggers an Ajax request, which may use more bandwidth if not used. Use it sparingly for mobile devices. This talk focuses on speed.

Is the pre-rendering on Hover being done server side or client side? If the latter, won't moving the mouse everywhere slow everything down? Well, it's fetching things behind the scenes. So I mean, if you're on any big website like Twitter or Facebook, I mean, if you want to go to the network tab, it's always going to be doing all kinds of things behind the scenes. So I don't think it's really slowing things down. But when you go to Hover over something, we're just doing an Ajax request to get something. And if you end up not using it, I guess it's maybe using a little bit more bandwidth. So use it sparingly because if someone's on a phone mobile device, it's fetching more data but it's making an incredibly fast experience. Yeah. Mobile device is one of the interesting ones. This wasn't the save money talk. This was the fast talk.

13. Remix Adoption and Prefetching

Short description:

Do you know if Remix will adopt Reactor or Components? It seems like he's experimenting with it and it's giving him really fast performance. React Server Components may not make something that's already lightning fast. Remix is already pretty fast, whether they use them or not. It may come down to personal preference and specific architecture needs. Some people have concerns about prefetch and prerender, especially with limited bandwidth on mobile apps. You can create your own link component to handle different environments. We have a workshop on Remix if you want to learn more.

This wasn't the you have a bad day. Do you know if Remix will adopt Reactor or Components? I think so. If you would have asked me a month ago, I would have said probably not. I don't really talk to Michael and Ryan personally about that that much because they're both busy and I'm busy with React training and stuff. But I could ask Ryan, you know, what his thoughts are. But I get some of my information on Remix just like anyone else on Twitter. I try not to bug them too much. What's your take? Do you want to see that?

Well, it seems like he's experimenting with it. He just tweeted like a day or two ago that he was running experiments with it and that it was giving him really fast performance. But I think that he's aware of some shortcomings of doing so. It's a big trade-off. And I can't imagine that this is going to be really controversial. Is this still recorded? I don't think that React Server Components are going to make something that's already lightning fast. That one's faster. I think that Remix is already going to be pretty fast, whether they decide to use them or don't. I think it's going to come down to whether or not you just like the architecture or maybe have a situation where shipping less JavaScript and React Server Components might give you that. Maybe it comes down to those kind of things. I don't think it's going to give you a performance benefit over what Remix offers. Cool. Interesting.

There's a couple of questions that I'm going to bundle into one theme, which is not everyone is super sold on prefetch and prerender. One person says if you have limited bandwidth on a mobile app, it could screw with it, or... I thought about this question before they even asked it. I thought about it earlier today. If I was really worried about that, I might make my own link component, where you pass them onto the real link component, and in my link component, maybe detect if you're in mobile, maybe have a thing where we don't do the prefetching, but in a desktop environment, it would. You could do your own regular old React tricks to figure that kind of stuff out. Yeah. That sounds like it's worth a shot. Yeah. And we have a workshop on Remix, so let us know if you want to learn more about it.

14. Prerendering with React and Data Fetching

Short description:

Can we prerender using React without Remix? React on the server lacks a story for data fetching, so frameworks like Next and Remix provide solutions. React server components are the latest addition. Until React server components, fetching data on the server was limited. It's recommended to use a framework instead of a classic multiple page app.

Yeah. Summon them. One last question. Can we prerender using React but without Remix? I guess that would be maybe server components. Prerender. I mean, you could always use that standards version of prerendering, if you're doing ... The thing about React on the server is there's no story for data fetching, so that's why everyone uses a framework, because you have to ... That's why Next has the Git server side props, and we have the loader, and then they're doing React server components, which So there's no ... Until React server components, there's really no story for fetching data on the server, and so you could a classic multiple page app. Yeah. Or get a framework. Yeah, without doing ... Wait. Yeah. So I wouldn't really do that, but ...

Cool. Well, thank you so much for your time, Brad. Thank you, everyone. You can find Brad in person at the speaker booth after this, and if you're at home, spatial.chat, and you can ask even more questions.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
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.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
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.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions