Speeding Up Your React App With Less JavaScript

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.