Speeding Up Your React App With Less JavaScript

Bookmark

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.

32 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.

1. Introduction to Mishko and builder.io

Short description:

I am Mishko, the creator of Angular and AngularJS. Currently, I work on QUIC and serve as the CTO of builder.io, a headless visual tool that allows you to build pages by NPM installing it. We believe in open source and have developed PartyTown and Mitosis. Our open source team includes Adam Bradley, Manuel, and Sammy.

Wow, you know what? Nothing makes me happier than seeing a packed room. Like you guys are really, thank you. Like this is amazing. And I have to take a picture. So smile. All right.

Yes. I like to start my talks with a joke on programming, because I'm a dad, et cetera. So here's your joke of the day. How do you measure functions? Well, you measure them in para-meters. OK, good, good. Thank you, thank you, thank you.

So hi. I am Mishko. I did this thing called Angular, AngularJS. And now I work on QUIC. And I'm a CTO of builder.io. Builder.io is a headless visual tool. It's basically a page builder. But what's unique about it is you do it by NPM installing it, rather than using it as a service. And that means you can put it inside of your application. And you can register your own components, which means your marketing can drag and drag your own components on your website. And means they don't have to bug you about doing stuff for the UI.

We believe in open source. We do a couple of cool things. There is PartyTown for taking your third party scripts and moving them into WebWorkers. There's Mitosis, which allows you to write code once and generate canonical output for all the frameworks out there. We include everything from Angular to web components and every other letter in between. And this is our open source team. Adam Bradley, who worked on Ionic, Manuel, who worked on Gin, which is a Go framework, and Sammy who works on Mitosis.

2. The Problem with Website Performance

Short description:

Most websites are slow, and Google has developed Core Web Vitals to address this issue. However, most real websites are still in the red, indicating poor performance. It's crucial to improve website performance as it directly impacts bounce rates, completion rates, and revenue generation.

So anyway, let's talk about what I see the problem to be. And the problem we're trying to solve is that most websites are slow. And it's such a big problem that Google is really focusing on this, right? Google has developed this thing called Core Web Vitals. And if you look at Core Web Vitals, you're going to find something interesting, that most websites, real websites, I don't mean like talk hello world kind of site where you put up and say, look, I can make this thing performant. No, I'm talking about real websites. Most real websites are actually in the red. And few websites like Amazon that actually have the money and resources to go after it are actually in the yellow. And that's kind of strange because there's a lot of data that shows that, hey, the better performant website is, the less bounce rate you have, the more completion to purchase out, et cetera, the more money you can make. So clearly there is something going on where people know that web-based websites are important, but nobody seems to be able to get there.

3. The Problem with JavaScript and Hydration

Short description:

The problem is JavaScript. The amount of JavaScript shipped to the browser has increased over the years, overwhelming the single-threaded JavaScript execution on startup. This leads to poor hydration scores. The more JavaScript you ship, the worse your startup performance. Hydration is a workaround for server-side rendering.

And so what do you think is the problem? Is it really the question? And I think the problem is JavaScript. You may or may not agree. Who agrees that too much JavaScript is the problem? Wow, not enough hands. OK, that's OK. I guess that's why I'm here. I'm trying to convince you.

So the amount of JavaScript that we ship to the browser has just increased over the years. And this is a graph showing how it just keeps going up and up and up. And it makes sense, because we, as users, expect more and more interactive websites. Like what was interactive and good enough last year is not good enough this year. We just want more and more interactivity. And that means we need to ship more and more JavaScript. And this isn't scalable, because JavaScript is single-threaded. And the single-thread gets overwhelmed with too much stuff that's happening. And all this JavaScript has to execute on startup. And so you get really bad hydration scores.

OK, so let me show you this interesting graph. I randomly chose a couple of frameworks. Well, totally not random. But anyways, the frameworks show, on the left, you see the scores you get average on Google Core Web Vitals. And on the right, you see the amount of JavaScript that's being shipped. And the point I want to make here is that these two graphs are essentially inverse of each other. The more JavaScript you ship, the worse your startup performance. And the less JavaScript you ship, the better your startup performance. This isn't like that crazy of an idea. It's kind of obvious, if you think about it. If you ship more code, you will have a worse startup performance. And so why do we have to ship so much code? And the answer to that is hydration is this weird workaround. Because before we had server-side rendering, the way this works, we sent HTML, which is a blank page. It was literally a white page, nothing on it.

4. Client-side vs Server-side Rendering

Short description:

JavaScript downloads, executes the app, and renders it, resulting in a client-side rendered application. AngularJS started this trend, and React popularized it. Server-side pre-rendering was introduced to address the issue of a non-interactive initial load. The HTML is sent, followed by executing the application and re-rendering it. However, this approach results in duplicate information, affecting performance.

And then JavaScript would download, and then we would execute the app. And then we would render. And then finally, you would have a working application. And this we would call this the client-side rendered applications.

And I think AngularJS kind of started this kind of a trend, and certainly React popularized it more. And so this is the point where you can interact with the application. The problem was this white box in the front. And if you were going to build an e-commerce website, the white box in the front is a problem. If it's a Gmail, this is fine. You don't care waiting for it for a while.

And so people said, we need to do server-side pre-rendering. So we send HTML, this time bigger. The box is bigger. And so now you actually send the image, or rather the website you want. The problem is, this appears faster, but it is not interactive. You cannot click on it. You can't do anything with it. And so then you go and rerun the JavaScript. You execute the application, and then you rerender it. Of course, now you don't call it re-rendering. You call it reconciling. We have to give it a fancy name. And you reuse the dom nodes if possible. But if not, you kind of recreate them anyway so it doesn't really matter. And you end up with the same exact UI.

And then at this point is when you can click on it. And it's actually slower, because the HTML you sent was actually bigger. And if you think about it, what's going on is, well, you're sending duplicate information twice, right? If you look for a string like hello world, that string is going to be found once in the HTML. And then again, somewhere inside of the JSX of your application that's being shipped as JavaScript. And so all this duplicate information is kind of part of the problem.

5. The Problem with JavaScript Hydration and Quik

Short description:

The JavaScript re-executes everything to find the listeners and attach them to the DOM. Partial hydration breaks the application into islands, but inter-island communication becomes a challenge. Quik can hydrate React components and provide intercommunication without adding more JavaScript. Different frameworks have different approaches to hydration, from full to resumable. React can adopt the island approach with Quik. Reasonability sends HTML over and the page becomes visible, with annotations indicating the code to run on button clicks.

The other part of the problem is that the JavaScript is re-executing everything that you had to go before. Now why do we do all of this stuff? Well, we do it because we want to get the red boxes. The red boxes are the listeners, right? So you start at the root of the application and then you walk your component tree, right? And you recursively go through all the components and you look for where the red boxes are. Those are your listeners. And once you find them, you can attach them to dom. I mean, that is what hydration is, right? Hydration is a process by which you find your listeners and those listeners also need your state of the application and the state of the application also needs to know where the component boundaries are in case we have to re-render. But all of this work has to happen before the application becomes interactive.

And so one thing you can do is you can do partial hydration. That is, you can break your application up into smaller islands and then hydrate those islands independently, lazily, or maybe on a visibility or something like that. And this is essentially what frameworks like Astro do and also Fresh, right? They claim amazing startup performance because they say, you know what? Most of the page you're looking at is static. There's really only a couple of interactive bits like for example, the menu or the shopping cart, et cetera. Most of it is not interactive, but this particular approach has a very important problem. And that is, you essentially create it with bunch of siloed applications on a page. And so you need to solve the inter-island communication problem. That is, how do these islands talk to each other, right? If the green box on the right represents add to shopping cart button, how does the add to shopping cart button talk to the box on the left that represents the shopping cart? How do they tell each other like, hey, I'm adding an item if they're in the separate islands. And normally this is solved by, well, the framework. The framework's job is to provide state and you push the state to your children and by sharing the state, you allow different components to communicate. But if you make islands, how exactly are you supposed to communicate? And so what you want, is you want something that creates islands but at the same time can do the communication between them. And so I'm gonna show you a particular solution, which is what Quik can do, is that Quik can hydrate React components and provide the intercommunication solution without actually bringing more JavaScript to the table. And so a little kind of a chart to kind of show you off is that you have frameworks that are full hydration and all these frameworks are exploring ways to do it by priority or something like that. And there are actually on the other end of the spectrum, there are frameworks that are fully resumable. Quik is the one I work on, but there is an internal framework at Google called Wiz that powers Google Search, Google Photos and those applications are amazingly fast. They also kind of have the philosophy of reasonability and eBay actually has a framework called Marco, which is actually extremely performant for these things called Marco version six. And of course we have these frameworks in the middle, which is Astro and Fresh that are trying to take the island approach. And so I wanna show you how React can also become the island approach with something like Quik behind it. So let's talk about reasonably very quickly and I'm gonna show a couple of demos.

So first of all, I kind of explain how hydration works and so let me show you what's different about reasonability. So you send HTML over, it's the same HTML as before and the page becomes visible. Now the thing that is interesting about this particular page is that inside of the page, you have annotations that tell you what code should be run if you click on a particular button. And so not only does it appear faster, you're actually ready to click.

6. User Interaction and JavaScript Download

Short description:

The framework eagerly downloads JavaScript, but it doesn't execute it until you interact with the page. By removing duplicates, the amount of JavaScript sent is smaller, saving time on application startup. Let me show you a demo of a basic render of a React component using Quickify, which lazy hydrates the component. The page rendered without JavaScript due to server-side rendering.

The user can go ahead and click on stuff and that click will be processed. And so at this point, the framework starts eagerly to download JavaScript. It doesn't execute it which is a kind of a big difference between the previous one and the current one. It's not executed, it's just eagerly downloaded as soon as possible so that it's ready to execution if it needs to be. But nothing executes until you go and interact with the page.

Now at this point you say, yeah, yeah, but you're cheating. Your JavaScript box is smaller. Like hey, you excluded a whole bunch of stuff. Yes, that's because click can remove duplicates. And so by removing the duplicates, the amount of JavaScript that actually gets sent is significantly smaller. But of course, there is no execution or reconciliation part that's going on. The whole thing just becomes immediately available. And so you save a huge amount of time on getting the application up and going.

So let me show you a couple of demos. Okay, so let's start over here. So the first demo that I wanna show you is just a basic render of, hello from React. So let me show you, let's see. Let's... Maybe I can put the pages next to each other. Here we go. So here is a basic React component. I'm sure you've seen that millions of times. Nothing surprising. The thing you can do is you can wrap it inside of a Quickify function. And what the Quickify function does is, basically, it can't make the React component resumable, but it can lazy hydrate it on some event. And in this particular case, we're just turning it and I'm showing it that you can use it inside of a Quick. And the end result is right here. Now, so far nothing really that interesting. What I do want to show you is that there is no JavaScript present. So the page rendered, because React on a server can do server-side rendering.

7. Server-side Rendering and Component Hydration

Short description:

We server-side rendered the component without interactivity or JavaScript. We need to hydrate the component before using it. Hovering over the component triggers automatic hydration. Communication between islands is essential for more functionality.

And so we server-side rendered the component as part of the rest of the application. We placed the React component in the UI. But because there's no interactivity, no behavior, that particular component never gets hydrated on the client. I'm filtering out beat and node modules because we're running inside of the DevModes. So I don't count these particular things, but I really just want to show you that as far as the code is concerned, there's no JavaScript present.

So let's look at the next bit, which is we probably want interactivity. Okay, so there's our counter. Oops. Okay, so let's make a simple counter. So I'm sure you have seen a counter in React done millions of times, right? But basically that's what a counter would look like. Now, again, we wrap it inside of the Quickify and we render it. And so here is our counter. And notice no JavaScript. And if I click on plus one, nothing works. Well, of course it doesn't work. We didn't hydrate React. And so at some point, we need to hydrate it before we can use it. And so the question becomes, what should be the event by which you can hydrate the component? And the most obvious one, I know it says click, but most obvious one is actually on hover. Sorry, it was playing around. Okay. So let's say that we would like to hydrate it on hover. So same exact thing, no JavaScript. And notice as I move the cursor over, the application automatically hydrates. And you can see that the React has come up because it says React dev tools, et cetera. And what you can see is that mainly, some of these, this is basically glue code. It knows how to bring it up to it. So in this way, you can have an island, but island is not that interesting, right? Like sure, you can have an island, but really you want to have some kind of a communication between islands. Like as I mentioned earlier, yes, you can bring a bunch of components on a page, but unless those individual islands can talk to each other, there's very limited things you can do with it.

So let's rebuild this example again. So let's do another example, which is this one right here.

8. State Management and Hydration Examples

Short description:

In this example, the state is moved to the parent component, allowing communication between the display and incrementor components. Only the necessary JavaScript is downloaded, and inter-island communication is demonstrated. Another example showcases a slider component wrapped in Quickify and hydrated based on specified rules.

And this example, and let me actually refresh so that the JavaScript disappears. So this example is essentially the same example, right? I can click on it and run. And as you can see, the JavaScript shows up when I hover over it. The question is how is this different? So let's have a look.

So okay. So the difference I'm gonna make here is what I've done is I've built the counter, but notice I moved the state outside of the component. Right, this is typical of what you would do, like when you have a component that, let's say a shopping cart and a shopping cart and an add to shopping cart button, you put the state in the least common parent, right? And so in this case, what I have is I have two components, display and incrementor. And display just shows the count and the incrementor just increments, you know, calls the callback button basically, is just a glorified button. And I move the state into the parent, which this happens to be a quick component. And by passing the state into, by having the state at the parent, now I can pass the state both to a display and I can pass a callback to the incrementor, right? And so in this way, I can have the incrementor talk to each other. And so what I wanna show you is no JavaScript is present over here, right? When I hover over this button, right, the JavaScript for the button shows up. So at this point, we woke up the component and hydrated the button itself only. So let me clear this for a second, so you can see. Now if I hit plus one, what we downloaded was just a piece of code that was the callback, just the count plus plus, right? So we downloaded this callback and nothing else, right? So just this callback downloaded. But once we modified the display, right, so once this signal modified, the system was like, hey, this signal is being passed to the display. And so as a result, we now have to also wake up the display. And so the second file that downloaded over here is the display, and this is just the React code for the display that gets hydrated and re-rendered, etc so that the count gets to update. And so what I really wanna show you is these inter-island communication. And I think this is the key, right? Without inter-island communication, the islands are really not that useful.

Okay, so let's do something more fun. So here is a slider component. Here, let me refresh the UI again. And so let's look at a slider. Slider. Okay, so what I did with the slider is notice I just took a material UI, as an existing library that's super popular at Qwik, React, and I wrapped it in a Quickify, and I specified the rules under which it should be hydrated. So I simply said, you know, when somebody hovers over this particular thing, I want you to hydrate it. Or there's other rules. You can say, you can do a specific event, like I'm scroll, or you can say I'm visible, or something like that, but let's just do hover for our purposes. And so taking this Quickify component, I can drop it in here. And I can also have a regular input, which is a standard HTML component.

9. Hydration and Intercommunication

Short description:

The code wakes up when hovering over the material UI slider. Dragging the slider updates the other side. Only the necessary code is downloaded. The system wakes up the other component when dragging the native component. Breaking the application into islands improves startup responsiveness. The table in Material UI eagerly hydrates when it comes into view. React wakes up and hydrates the component. Thank you.

And then of course, the state is up here. And so I can bind the state between the React island and Qwik component in here. And what I wanna show you is that the right thing happens.

So first of all, when I hover over the slider, the material UI slider, right, the code wakes up. Notice if I hover over the HTML one, nothing happens, but if I hover over the material one, it wakes up the code. Let me just clear this so that it's more obvious. And then when I start dragging it, it immediately goes and updates the other side.

Again, what you can see is that the code we downloaded is just the code for the callback, right? So the only code we downloaded is basically this code right here, where we're assigning the percent value to the value of the new slider, et cetera. And the reverse is also true. If I refresh, I have no code. Nothing is hydrated, right? And I start dragging the native component. The system realizes, like, oh, I have to go and wake up the other one. And so it wakes up the other component as well, and them you have a fully working kind of system as well.

And so again, what you can gain is to say like, hey, your application's too big. By breaking it up into islands, we can have a better startup responsiveness, but we need to solve the intercommunication problem. And then finally, I'm gonna show you one more thing, which is a table in material UI. What I find interesting about this table is all the components I showed up to this point, they actually server-side rendered, right? But this table doesn't have a server-side rendering capability. So this table has to eagerly hydrate. And so again, if I scroll up, if I clear the amount of JavaScript, when the table comes into view, it is at this point that React wakes up, and you hydrate this particular component. And from a UI point of view, where is the UI? Okay, so here's that table. I'm using this particular table, right? This table comes from table React, which is from here. And this is a, again, Material UI table, X Data Grid. And you set up your data, et cetera. So this is basically your normal React component that you would do. And then you finally wrap the whole thing and tell the system, like, hey, wake me up when I become visible. And the right thing just happens. Whoa.

Okay, so that's the main demo portion. I don't think I have anything else. Just wanted to say that thank you.

10. Using Quick to Improve React Performance

Short description:

I'm happy to answer any questions about using Quick to improve React performance. Builder.io itself uses Quick for its homepage. We noticed a significant performance improvement with Quick compared to other hydration frameworks. The difference in hydration time can be as much as 60 seconds versus 400 milliseconds on a modern CPU. For example, the site Rosa, Belgium, prioritizes sending the least amount of JavaScript for better performance, even in areas with slow network coverage.

I'm sure you have questions. I'm happy to answer them. I'm happy to answer them up here on the stage or afterwards outside. And I just wanted to show you how you can use something like Quick to make React more performance. Thank you. Thank you. Thank you.

First question that I have personally, which I ask mostly when I hear about these new kinds of technologies. Is there any user already that you know of that you're like, whoa, I can't believe products X is using this?

So we already have a couple of users. First of all, Builder.io itself is using it. Our homepage. We have a headless visual system for building UIs. And a lot of times people came to us and said, hey, I built a site using your technology, it's not as performant. And we would say like, well, yes, but like, it's not us. It's the underlying rendering technology. And of course that sounds like you're passing the blame. And so it was really important for us to be able to showcase our technology actually being performant. And so the nice thing about builder is that we can generate output through mitosis, either to quick, react, angular view, et cetera. And the thing we noticed is it doesn't matter which hydration framework you pick. The performance is about the same. But the moment you go to a resumable system like quick, the performance just skyrockets. And it's obvious not just in that sense, but also when you go to the performance tools of Chrome, and you just see like how much JavaScript executes and you compare the before and after, and you see huge difference. You see a difference between 400 milliseconds of hydration on the modern CPU versus like 60 seconds of hydration, right, it's a huge difference. And that difference has an impact. We see sites, for example, the site called Rosa, Belgium, which allows you to book appointments for doctors in Belgium. And so for them was extremely important that even on a slow network, somewhere in the village, which doesn't have the best coverage, they're able to book something. And the way they can do that is by sending the least amount of JavaScript, right? And so technologies that send the least amount of JavaScript are important for the startup performance. Really nice. Yeah. I remember at a company where I was working, we did some performance improvements without Qwik, was before Qwik, and then suddenly the app became so fast that we didn't trust that it was working anymore.

QnA

Hydrating React Components and Quickify

Short description:

The distinction between eager download of code and lazy execution of code in production. Utilizing a secondary CPU core to eagerly fetch code is a good performance improvement. The code only gets executed or loaded into the VM when you click on it. Quickify makes it easy to retrofit in an already big project. Quick solves the inter-island communication problem, making it easier to break up your application. React context can work between the React islands with Quickify by using a Quick context.

Is this a known problem for you? That is a good story, yes. You just have to trust it. Gonna go to the audience questions. Can I get the audience questions up here?

What happens with hydrating the Reacts component on hover when there's a slow internet connection or no internet connection at all? I should have covered that because that is the number one question that everybody asks. So what I showed is that mode, and in that mode, things are lazy to kind of demonstrate what's going on under the hood. But in production, there's a distinction between eager download of code and lazy execution of code. And I know that sounds strange because up until now, everybody thought of that too as the same thing, but you can actually have a service worker that unload immediately, eagerly starts to fetch the JavaScript and places it in the browser's cache, but you don't actually load it into the V8 or whatever the VM that you happen to have in your browser. So you don't actually load it in there. And so you don't get penalized for this in Core Web Vitals. And also it kind of makes sense because the service worker runs on a separate thread and most even mobile devices have multiple CPU cores. And so the fact that you are utilizing a secondary CPU core to eagerly fetch your code is actually a good performance improvement. And then the code only gets executed or loaded into the VM when you actually click on it. So provided that when you first navigate to the page, you can fetch the JavaScript associated, and as I pointed out, the box of JavaScript is smaller than you would normally fetch because many of the components will never actually render ever on the client, provided that that happens eagerly, right, which does in a normal systems anyway, you can go in a tunnel where you lose connectivity and the button still works.

Yeah, it also looked like it was really easy to retrofit in a already big project. You can just say, hey, this is a component that's slowing me down a lot. And it looks like you can just retrofit quick on there and really easy.

Yeah, that was our- That was our... Haha. Sorry, sorry. That's a part of the joke. Definitely, we spent a lot of time on Quickify because we wanted to make sure that it's a good experience. And as you saw, like really the only thing you have to do is you create a separate file at the top. I forgot to mention there's a JSX pragma to tell the compiler to use the react.jsx rather than quick.jsx. So you have to do that and wrap it in the Quickify component, right. And that gives you a quick component that you can then just use, as you can say, as you can see anywhere else, right. And a big point that I really wanna make is that while there are other technologies that do island hydration, I think the difference with Quick is that it solves the inter-island communication problem, which is something that without it, it makes it difficult to break up your application.

All right, next audience question. Does React as context work between the React islands with Quickify? Ah, good question. Does context work? Sort of, it's a qualified question. So it doesn't work out of the box, but what you can do is you can use a Quick context, and then whenever you do the Quickify wrap, you can just grab the Quick context and reinsert it as a context inside of the Quick.

Contexts, Testing, and Jokes

Short description:

You can get contexts working between the islands. Quick code works without any transformation, enabling lazy loading. Tests for the React component can continue running without updates. Export both the counter components and Quickify counter components. Entertain the audience with jokes while looking for questions.

So it requires a little bit of extra glue code, but yes, you can get contexts working between the islands. And people can find examples of that? Yes. All right, great.

Next question, I can't read it, I need to stand up. How does Quick handle big JS loading? It disappeared on me. Can you have fallback components while loading? No, don't disappear, stop asking questions.

How does the lazy hydrating process affect testing? How does the... I don't think there should be any difference in testing. One of the requirements we were building Quick was that the code should be testable without doing any kind of special loader for the test runner. So the Quick code works as is without any sort of transformation. The transformation really only enables you to do lazy loading, et cetera. So all of this stuff should be testable, a straightforward beat test or just test or whatever you happen to have.

So if I have my counter components and I wrap it with Quickify, I don't need to update my tests? No, well it depends whether you are testing the React one or the wrapped one, right? So presumably you have a test for the React one so you just continue running the React one. Yeah, so I need to make a new export of the counter components and an export for the Quickify counter components. Correct. Oh, yeah, okay, good, gotcha, gotcha, right. I need to get the questions here then. Sorry. We should moderate.

While you're looking for questions, I'm gonna entertain the audience by telling them a joke. Okay, also good? How do functions break up if they stop calling each other? Two-factor authentication. Ah, so you're asking me about this, I was like, what does that have to do with anything? That slows me down a little bit. All right, so you're saying I should come up with another joke? Of course. Why you shouldn't write with a broken pencil because there's no point. Oh wait, wait, wait, hold on. Why did the JavaScript programmer quit? Because he didn't get a raise. All right, I'm in. I'm in. Except all cookies. Thank you, EU.

QUIC and the Distinction between MPA and SPA

Short description:

QUIC can be used with both server-side and client-side rendered apps, providing startup performance benefits. The distinction between multi-page applications (MPA) and single-page applications (SPA) is primarily due to hydration. Without hydration, the line between MPA and SPA becomes blurry, and the distinction is unnecessary when approaching the problem from a different perspective.

QUIC is only relevant for server-side rendered apps, right? No, you can use QUIC with client-side rendered apps as well. Of course, the main benefit that QUIC provides is the startup performance. So the best place to use QUIC would be in like multi-page applications or landing page applications or e-commerce, et cetera. But it turns out that even in client-side rendered applications, there is a benefit. Like imagine you would have your Gmail and all of a sudden your Gmail would start up faster because you don't have to download the whole Gmail before you do anything, right? So I think while there is this distinction between MPA and SPA, I think this distinction is mainly caused by the fact that we have hydration. If you take hydration away, it turns out that the line between MPA and SPA becomes extremely blurry and there is really not much difference. So I think it's one of those distinctions that we created ourselves that was unnecessary once you kind of change your point of view and you look at the problem in slightly different way.

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 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 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
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.
But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
React Summit 2023React Summit 2023
24 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance
&
user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!


Workshops on related topic

React Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
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 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Workshop Free
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites
- Good understanding of JavaScript or TypeScript
- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications
-
Preinstall Node.js, npm
- We prefer to use VSCode, but also cloud IDEs such as
codesandbox
(other IDEs are also ok)
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Workshop Free
- Introduction
- Prerequisites for the workshop
- Fetching strategies: fundamentals
- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)
- Test your build and serve it on Vercel
- Future: Server components VS Client components
- Workshop easter egg (unrelated to the topic, calling out accessibility)
- Wrapping up
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
Workshop Free
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:
What’s CLS and how it’s calculated?
How fonts can cause CLS?
Font loading strategies for minimizing CLS
Recap and conclusion
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.