What is Resumability? What is the Qwik framework

So Qwik follows the same sort of patterns of React, and share a very similar syntax to React. So learning how to write a Qwik App is insanely easy.

There is no React happening in the engine, however, it just feels like writing a React app, but with incredibly good performance architecture.

Qwik is Resumable: What does this mean?

To answer this you must understand the state of web in 2023. Most web apps now are written in some Client Serving framework, the reasons for this, is because client based frameworks offered us so much really good quality of life developer features.

Virtual DOM on paper seems like a really great idea. React can perform some logic behind the scenes, saving some paint cycles, rather than drawing to the screen on every single state change. React can kind of bundle them all up together and do in one go. Or decide not to do any rendering changes, if there is no need.

Where were we before this? Server side apps. These are becoming more popular again with the sights of NextJS, Nuxt, etc. Instead of logic happening on the client, or bundling an entire website into small chunks on the client. With server side rendering, the user's browser makes a request to the web app server, and ask for a new page to be delivered.

However, this server side rendering only really worked when you are working on fairly static content. Something like a blog, where content is the same, when you make a request to the server, the same content would be shown. Not much interaction going on here.

So what is the issue here? Can't I just use the server side features of NextJs for my static content. And then the client based features for the rest of my app?

Well... Yeah. But what you notice is that within each page in the app. There is always going to be some Static content there. And then some more dynamic content. And also, you maybe even would have some staticly delivered content from the server, that now wants to be dynamic. Maybe fetch some additional stuff from the server.

You also kind of want your content to pause when they no longer need to be dynamic. Having listeners to document changes in a web page does have a fair bit of overhead. The fastest sites are always going to be 100% static, with absolutely minimal styling. This sounds like garbage collection handling, and all this complicated performance handling that web devs have spent decades trying to abstract away.

Qwik deals with this concept of Resumability It is built from the ground up with this very concept baked in. When developing your app, each component by default is 100% static. You can also easily, do some expensive tasks that get run on the server, just moments before the component is mounted on the client. No need to wait for component to mount on the client. And then call a third party api to render the rest of the component. This all happens before the user sees it.

Qwik also understands, you will also need some logic that runs on the client. For example, calculating the document height, and rendering a progress bar based on how much of the page a user has read. In the Qwik documentation they are quite explicit that we keep client based logic small, and only when absolutely necessary.

I am very excited to see the future of Qwik. There are some alternatives frameworks looking to solve the same client based problems, such as Astro. However, I see myself more aligned with the Qwik paradigm and their roadmap.