Qwik is one of the new frameworks in the town which you might have already heard of. Qwik is created by Miško Hevery who is also the creator of Angular. I was quite intrigued by the Qwik: Under-The-Hood demo by Tony Alicea which led me to explore Qwik.
I understood that this is not a similar framework to Angular, React, Vue, Svelte, and Solid. Qwik is a fundamentally different framework distinguished by its two main properties,
Need for a new framework
Before we understand how Qwik works, let us understand why do we need a new JS framework when we already have so many.
Every business wants to build a fast website that the customer can interact with, the second they load it. So that they don't lose the customer's attention.
You can read through this web.dev article to understand each of the rendering pattern well. I'll mention about two of them briefly over here, which are used to develop applications on the web.
Client side rendering - The entire app is rendered on the client side, this does lead to longer TTI because a huge JS bundle needs to be downloaded and executed before the app can become interactive. There are methods to reduce the TTI like lazy loading, code splitting, etc but still it doesn't help reduce the TTI much.
Server side rendering - As the name suggests the app is rendered on the server itself including all the date fetching, and an HTML is then sent to the browser. This does delay the FCP a bit but it makes the TTI much closer to the FCP. Hence the user can interact with the app faster than a CSR app.
Now based on these you might conclude that yes SSR is the way to go but what if you are missing something which if removed can make your app render even faster?
Even though the HTML does get rendered on the server side alongwith the data but the browser still needs to map it to the DOM and attach event listeners. This process is known as hydration.
This is what Qwik does with its resumability feature. Your code runs on the server and then as and when required for any interactivity the respective code is first lazily loaded and then only that part of JS is executed.
Imagine if you are watching a movie on your commute and then later the next day you want to finish the movie, what would you do - watch it from the start again or resume from the where you had left. A similar analogy can be drawn here to hydration and resumability.
The code execution in Qwik starts at the server and is then paused(serialized into HTML) and can be resumed at the client side. The state of the application, event listeners and the reactivity graph(what else needs update when something is updated) is serialized into a JSON within the HTML.
So these are the two main features of Qwik that I learned along with many other features that just blew my mind, like
Qwik doesn't execute the code which is below the fold
Qwik tree shakes data that component will not use/update in the client
I learned all this and more in the recent Qwik workshop conducted by Miško himself.
![My tweet about the Qwik workshop conducted by Misko](cdn.hashnode.com/res/hashnode/image/upload/.. align="middle")
I'd also like to mention couple of DX enhancements in Qwik compared to React
In React, to lazy load a component or any function you have wrap the component with Suspense, use React.lazy, import function with async/await, etc, whereas in Qwik you just define the component with
component$()and a wrap a function with
In order to prevent unnecessary execution of components in React we need to use React.memo, React.useCallback, React.useMemo. But this isn't required at all in Qwik since a re-render of component in Qwik does not cause re-render of children or parent components
So basically the amount of code that we write to optimize React app is completely eliminated when we use Qwik because the framework itself is built with the best optimization.
Lastly, I would like to say that Qwik is NOT just another framework, it is fundamentally different that most frameworks out there, in a sense it is revolutionary. But that being said if I had to build an app today I'd still use NextJS because first of all Qwik is in beta as of the day that I am writing this post and also it doesn't have the community support that Next has today. But I can say that most likely Qwik will be what Next is today in coming time and I can't wait for it.