AI Generated Video Summary
1. Introduction to Mishko and builder.io
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
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.
4. Client-side vs Server-side Rendering
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.
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.
7. Server-side Rendering and Component Hydration
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
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
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.
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.
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
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?
Hydrating React Components and Quickify
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?
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
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.
QUIC and the Distinction between MPA and SPA
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.