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,

• Resumablilty

• Progressiveness

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.

There are different types of rendering patterns that most of the frameworks provide to render an app faster - namely CSR, SSR, SSG, ISR, etc.

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?

Hydration

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.

It can take a while before the DOM components that were received from the server are fully hydrated. Before the components can be hydrated, the javascript has to downloaded, processed and executed.

So basically your javascript code kind of ran twice, once to create the HTML on the server and once on the client to hydrate the HTML. What if you could prevent the second run of the code and still have the interactivity on the client?

Resumability

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 main problem that Qwik solves is not just downloading lesser javascript but to execute lesser javascript.

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.

Progressive

Qwik progressively downloads and executes the required javascript as when it is required when the user performs an interaction with the app. The components are in the paused state when they are initially on the browser, and when an event is fired based on the user's activity the respective component's event listener code is lazily loaded and executed.

Now an obvious follow-up question that might arise is that what happens when the user faces an abrupt network issue, the app will become unresponsive or crash since the respective javascript code is not downloaded?

No, Qwik uses service workers to eagerly load the relevant javascript the a user might potentially interact with. So in case the user faces an abrupt network issue, the respective javascript will be already available to the browser and will get executed.

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.