How is Qwik reusability different from rehydration of other web-frameworks

Question

Web-frameworks that server-side-render (or SSG) require rehydration step, how is that different from Qwik approach of resumability?

Answer 1

There are many web frameworks out there. All of them have some form of SSR/SSG. The purpose of SSR/SSG is to precompute the HTML on the server/build time, because HTML is the fastest way to show content to the user.

The drawback of HTML is that it is not interactive. So while SSR/SSG can get your site painted quickly there has to be rehydration to make the site interactive.

What is rehydaration?

There are two reasons for rehydration:

1. The framework needs to attach listeners to the DOM so that the page can become interactive.
2. The framework needs to collect data about the component hierarchy. (Basically build up the component tree and all of the metadata to go with it)

Without the above two points, the HTML is really just static.

The reason why rehydration is expensive is that both of the above points require that the framework downloads all components on the page and executes their templates. During the template execution, the framework collects listener closures and attaches them to the DOM as well as collects component tree metadata.

The above is expensive in terms of bandwidth (download a lot of code) and execution (interpret a lot of code)

Is there a different approach?

Yes, and that is where the resumability of Qwik comes in.

Qwik, like other frameworks SSR/SSG and send HTML to the browser. A Qwik application just like other web-frameworks requires that

1. event handlers are attached to the DOM and
2. frameworks need to understand the component tree and its metadata.

So far the needs are the same, but instead of downloading and executing templates to collect the listeners and data, Qwik serializes all of that information into HTML in the form of additional attributes and elements on the server/build. This means that:

1. Qwik does not need to look for the listener in templates, instead, they are already in the HTML in form of attributes. Qwik just needs to register a global listener which can read those attributes.
2. Qwik serializes the application state as well as component hierarchy into HTML (in form of a JSON). Therefore on the client, Qwik does not need to download and execute the templates to rebuild it.

This is what is meant by Qwik being resumable. Because Qwik serializes all of the data int HTML Qwik gets to skip the rehydration step, to bring HTML to life. The rehydration step is often the biggest cost of all of the first-party code which executes on the browser on application startup. Qwik just resumes where the server left off.