Qwik vs Next.js

[00:00:00]
>> Yeah, I was actually going to ask you to try and compare and contrast that against the React Server Components and streaming HTML with Nextjs.
>> Right, so React Server Components, I think React server components is like a mini-framework inside of the React ecosystem. And what I mean by that is, React Server Components have special rules, right?

[00:00:24]
If you have a React Server Component, first of all, you still need to ship the framework, right? So with React Server Components, framework is still have has to be shipped. The next problem is, you can have a React Server Component as a top level component, which can include other Reacts Components, and can include client components, but client components cannot include a Server Component, right?

[00:00:45]
So it's a one way trip. And it also means that, when a React Server Component calls into the client component, you cannot pass in functions. And passing functions around is a very common thing to do, right? The next problem is, React Server Components cannot have state, they cannot have listeners, whereas the client components can have state and can have listeners, but their client side rendered, right?

[00:01:09]
And so there's a lot of these different constraints in there. Qwik the one way to think about Qwik is that, there is no distinction between the server and the client. And Qwik has this interesting property where a component can start up on a server and then yet continue execution on a client.

[00:01:25]
So there's very kind of, it's almost like every component is a server side component and a client side component at the same time. So you can get all the benefits of React Server Components with QUIC, but you can also have listeners, you can also pass in functions, you can also basically, do all of these pieces that are not possible in React Server Components.

[00:01:46]
And there is no kind of constraint of like, a React Server Component can include the client, but the client cannot include the server, none of these constraints kind of exist in QUIC. And so, I think from that point of view, it's just a much better mental model. And having said that React Server Components still require you to do hydration for the client components, so you can't skip on that, right?

[00:02:08]
Whereas, Qwik doesn't do that. And so, React Server Components are definitely a step in the right direction, and it's improving it. And it's probably the best you can do given the constraints of legacy, existing technology's without breaking the backwards compatibility. But quickly just basically says, let's start a new and specifically have this goal in mind.

[00:02:31]
And so this is kind of how Qwik is different, right? And, yeah, so using mobility causes the old one, meaning that it doesn't matter how big your application gets. The amount of code that is initially executed on a client is one. And a lot of times we talk about lazy loading of JavaScript.

[00:02:52]
But really, I think that misses the point and confuses a lot of people, because then people immediately go down the path of like, that means that if I'm gonna slow connection, I click a button, I have to wait for it, right? No, it's not about lazy loading of JavaScript, it is about lazy execution of JavaScript.

[00:03:07]
Imagine the world where you upfront download all the JavaScript eagerly just like you do in the current system, but you just don't have to execute it. That's really what Qwik is about, right? We can also break up JavaScript, we can also lazy loaded, we can do all this other magic with it, but it's not the really amazing part.

[00:03:26]
The amazing part is, you don't have to eagerly execute all the code that's being downloaded, and that's what gives it the superpower, right? Because when you go to an existing system like React Server Components, even if you download the framework, and even if all the JavaScript is eagerly available and on the client and ready to go because it's the second time you visit it, right?

[00:03:48]
Even in that case, you still have to go through hydration and all of the execution and download, etc. And none of that stuff has to happen with QUIC, Mark.
>> Is that why something like Next.js ships a ton of state in the HTML?
>> So when you use something like Next.js, right, in order for the hydration to be able to work, one of the things that hydration requires is the state of the system.

[00:04:14]
In other words, is the menu open or closed? If it's a contact list, what are the contacts available? So when hydration happens, the state of the app is already on the client so that you don't have to go fetch the state of the system from the server, right?

[00:04:33]
So Next.js basically ships what they call next data, I believe, which is basically the serialized state of your application. Qwik does something very similar, Qwik also ships the state, but there is a big difference in that, Next.js, or basically, all of the existing framework, not just Next.js can only ship the state of the app.

[00:04:53]
But if you think about it, there is additional state in the system. The framework itself has stayed, the framework needs to know where are the component boundaries? Where are the listeners? What are the listeners, right? So if I click over here, what exactly am I supposed to do?

[00:05:08]
And all of these bits are not shipped with existing frameworks. And so, the framework has to get hold of this bit somehow. And so the way you get hold of these bits, is that, you re-execute the application. And as the application is re-executed, the framework collects information about the component boundaries, about where the listeners are, about the reactivity graph, or what have you about the system.

[00:05:34]
And once the application finishes executing, the framework is like, now that I know everything about your application, now I can do my magic, can be useful for you, right? And so, the trick that Qwik does is that not only is it sterilized the application state, but it also serializes the framework state.

[00:05:51]
And that's the magical bit that allows us to do reasonability. Just like Next.js can resume the application from the state that's serialized in the JSON, right? The state of the application is resumed, but it doesn't know how to resume the framework, it must execute all the JavaScript. We just took the step further and said, not only can we resume the application, in other words, we have this application state serialized.

[00:06:16]
We've also serialized location of the listeners, the reactivity graph, we basically serialize everything we need about the system. And that's what reasonability is right? So, let's let's look at a simple example. Let's say it's a shopping cart, there's a button that says Add to shopping cart and there's a shopping cart in the corner over here.

[00:06:35]
Clicking the button that required that the shopping cart updates with from 0 items to 1 item, right? The way existing systems work is great, I have the shot the data for the fact that this is a shoo in serialized into JSON and I know the price of the shoes utilizing the JSON and all that stuff.

[00:06:53]
All of those things are in the JSON in the next data bit. That's easy, but where are the listeners? How do I know that I need to go update the shopping cart? That information is not in the JSON. And so, what the framework has to do is execute the application.

[00:07:09]
But it's not just about executing the application, is like, you don't know where the listeners are. And the only way to do that is to start at the root component and visit every single component on a page and say, where's your listeners? Can you give them over to me, right?

[00:07:25]
And that execution is the thing that's hard and expensive. And once you execute everything, then the framework knows, when you click this button, I have to update the shopping cart, right? So if you can somehow serialize this information on a server then on the client, Qwik is resumable, because it says, I need nothing, you click on a button, great.

[00:07:47]
I wake up the listener for clicking on the button and that listener goes and mutates a particular state. And because I have a reactivity graph, I understand that that state is connected to the shopping cart over there. So now, I know I have to go wake up the shopping.

[00:08:00]
And so I wake up the shopping cart re-render, the shopping cart and I'm done. I didn't have to touch rest of the system, it doesn't matter how complex the rest of the page was, and how many complicated menu systems you had over there. I only had to wake up the button and the shopping cart and nothing else.

[00:08:15]
I think Mark had a question.
>> Yeah, so Josh was just clarifying that, so next data can be large, but even if download isn't the problem, the problem is the execution time.
>> Yes, speaking about this next data being large, one of the things that Qwik can do is that it can tree shake it.

[00:08:35]
In other words, Qwik can look at the data that the application have, and then recognize the fact that certain parts of the data can never be updated in the client. And therefore, that data never has to be shipped, because there is no code path that exists that would allow you to modify that data.

[00:08:54]
And because there's no code path that modifies the data, there is no code path that will cause a particular component to re-render. And because the component never re-renders, why are you shipping the data? Like, for example, let's take the title of the shoe. Let's say we're in a shopping cart, there's a shoe.

[00:09:10]
If I cannot change the title of the shoe or the item I'm looking at, and that will never cause the product to re-render, why am I shipping the information about that shoe into the client, right? It's already in the HTML and I can't edit it, and so let's not ship it.

[00:09:28]
So Qwik basically allows you to tree shake the data set that you're sending to the client, so that only the data that's actually modifiable can be sent. Tools like Next.js don't know how to do that. And as a result, they just send everything. And so, the HTML gets huge, sorry, the JSON in HTML gets huge.