We spoke with Misko Hevery, Chief Technology Officer at Builder.io about Qwik, the HTML-first framework. Qwik offers fast load times, precision lazy-loading, and uses as little JavaScript as possible. Misko Hevery explains hydration and resumability, the benefits of lazy loading, and how developers can improve their Goolge PageSpeed score.

devmio: Thanks for taking the time to answer our questions! First of all, could you give us an introduction to the Qwik framework and how it compares to other JavaScript frameworks?

Misko Hevery: Today's web users expect highly interactive web experiences. The interactivity requires a lot of JavaScript to be downloaded and executed before the site can become interactive.

A fast site requires as little JS as possible. So we have a contradiction. We can either have a fast site with little JS and little interactivity or a highly interactive site, which will take a long time to boot up.

The reason for the slow bootup is that the frameworks we use today require hydration. Hydration is how the framework figures out where the interaction listeners should be on the page.

Qwik is different in that it does not use Hydration. Instead, it uses Resumabality. With resumability, the page can become interactive without downloading and executing JS on the client. Because JS is not executed on the page load, the page bootup is essentially instant.

The second part of Qwik is that it is progressive. This means that as the user starts to interact with the page, Qwik will start downloading and executing only the necessary code for that interaction. In this way, Qwik applications act more like streamable apps rather than downloading everything upfront before interaction.

Resumability is simple in concept. (Save the server state, move it to the client and continue where the server left off.) But it turns out that it is hard to implement in a way that will retain the great DX that developers are used to. The hard problem is that JS heavily relies on closures, so the hard part is a way to serialize the closures on the server and restore them on the client.

devmio: Could you explain exactly what hydration and resumability are and what the difference is between them?

Misko Hevery: Hydration is a way for a client framework to recover the state of the application. Listeners, component boundaries, data flows to name the few. The way the framework recovers the information is through re-executing the application from the beginning. This re-execution takes time, both in terms of download as well as execution. As applications become more complex the amount of JS increases and hence the startup performance decreases.

The reason why the hydration is wasteful is because the server already executed the application as part of the SSR. As the application was executed on the server the framework knew all of the information about the application, but it did not serialize the data. Because the data is lost the client has no choice but to recover the information through re-executing all of the application code from the beginning. This is why I often call hydration frameworks, replayable frameworks. Because they recover information about applications by replaying the application from the beginning.

Resumability is about saving all of the required information and serializing it as part of HTML. Then on the client the framework can just resume where the server left off. Because the client does not have to replay the application, the resuming is essentially instant.

Qwik is different in that it does not use Hydration. Instead, it uses Resumabality. With resumability, the page can become interactive without downloading and executing JS on the client. Because JS is not executed on the page load, the page bootup is essentially instant.

devmio: What are some of the benefits of lazy loading? Does it come with any downsides?

Misko Hevery: Having fast startup is about both downloading less JS and executing less JS. Executing less requires resumability. Resumability requires that closures such as listeners become entry points for the application. Because most of the closures have become entry points, lazy loading is essentially a free feature as resumability has already forced the code to be broken up.

The useful thing about lazy loading is the realization that a lot of code in the application executes exactly once, during application startup. Because that happened as part of the server, the resuming on the client does not require the code to be present.

The downside of lazy loading is that you have to ensure that code is ready before it is needed otherwise the interaction will have a delay creating suboptimal experience. To ensure that does not happen Qwik comes with a service worker which actively monitors the application state and ensures that all possible interactions have the code pre-loaded eagerly.

devmio: Do you have any tips for developers to achieve a better Google PageSpeed score?

Misko Hevery: Getting a better PageSpeed score is both simple and hard at the same time. The less JS you ship the better the PageSpeed score. It is that simple. The hard part is how not to ship JS and yet have an interactive application.

Resumability requires compilers to transform the code into a format which is conducive for resumability. The transformation is unlikely to be done by the developer because it creates unnatural code. The beauty of Qwik is that developers continue to write code in a way which they like, and the Optimizer transforms the code into format for resumability.

Getting a better PageSpeed score is both simple and hard at the same time. The less JS you ship the better the PageSpeed score.

devmio: How does performance and preventing bottlenecks enhance user experience? Should it be the number one goal?

Misko Hevery: Performance is but one of many UX considerations for the user. The goal of Qwik is to ensure that the applications have fast startup performance without the developer having to think about it.

The value is not focus on performance, but rather focus on what you think is important and Qwik will ensure that the startup is instant. Qwik takes the performance problem out of the developer focus.

devmio: What is the Qwik Optimizer and how does it work?

Misko Hevery: The hard part of resumability is creating entry points for the client to resume from. If the user clicks the "buy" button, we need to execute the "buy" button handler. This means that the "buy" button handler needs to be importable.

Usually the button handlers closures are hurried deep inside components and that makes them non-importable. This creates a problem. In order to become resumable the framework needs to invoke the handler, but to get the reference to the handler the framework needs to execute the component. In other words, it needs to replay the execution of the component to recover the closure.

The Optimizer refactors your code in a way which moves the button closure into a top level exported symbol. This allows the framework to just import the button code without importing anything else.

The hard part is that the button handler is the closure which closes over many references. The optimizer must translate the code in a way to recover the references of the closure so that the application can be resumed.

In essence, the optimizer's job is to create lot's of entry points into the application so that the application can be resumed from any point inside it.

The value is not focus on performance, but rather focus on what you think is important and Qwik will ensure that the startup is instant. Qwik takes the performance problem out of the developer focus.

devmio: How has your own work on Angular helped with development of Qwik?

Angular has exposed me to many different problems and solutions which exist in the framework world. This has allowed me to better understand the problem space and what actually matters for user performance.

I think the biggest lesson is that everyone looks at performance at micro level, and is trying to speed things up by being more efficient. We have done a lot of that in Angular. But in the end it is not enough.

The big realization is that it is not about doing things faster, but about just not doing things. It is hard to beat nothing. Qwik's magic is not in how fast it executes, but how good it is in avoiding doing any work. Qwik apps are instant because there is nothing to do on application startup if the framework is resumable.

devmio: Could you share any plans from Qwik’s roadmap with us? What are you currently working on and what do you hope to accomplish in the future?

Misko Hevery: Our goal with Qwik is to solve the personalization problem. The basic problem is that it is too expensive to generate personalized content on the server and then hydrate it on the client. This is the reason why eBay and Amazon do not use any of the mainstream frameworks. Because if they did they would lose the startup performance which their users come back to.

Most of the personalizations we see in the industry today are in the form of URL rewriting at the edge, these are crude compared to the level which Amazon or eBay produce. Qwik's goal is to create personalization on Amazon / eBay level without their engineering budgets. Qwik will use its reusamability property as an advantage to allow developers to create personalization which have cheap SSR and instant on clients.