Misko Hevery on Why Qwik Will Improve JavaScript Frameworks
A new JavaScript technique or library seems to make its rounds in the developer community every week. The necessity of most of them is debatable, but Builder.io CTO Misko Hevery says his newest project answers a long-standing problem. Qwik is a DOM-centric JavaScript framework built to make “instant applications” possible, by focusing on “resumability of server-side-rendering of HTML and fine-grained lazy-loading of code.”
Hevery is best known for being the creator of Angular, the influential JavaScript framework that was released by Google in 2010 (then known as AngularJS). So if you’re making a list of people who could fix the state of JavaScript frameworks, Hevery would be high on that list.
He initially spoke out about resumable applications at the 2019 Angular Ng-Conf. During that presentation, he gave two rules for what a framework should do to create applications that start instantly: only download and execute code that is strictly necessary to handle the user interaction, and don’t duplicate work that the server has already done.
It was from these ideals that Qwik was created. “Frameworks set the rules of the game, and developers have to follow them,” Hevery said in an interview with The New Stack. “Because current framework rules are hydration to make the site interactive, all complex sites are slow to start up. To get out of this trap, you need a framework with resumability rather than hydration.”
The Benefits of Server-Side Rendering
In January 2021 Qwik began development, starting as a project where Hevery was “mostly toying with how far I could push the idea of delaying the execution of code on the client.” He says the original syntax didn’t have the tooling and therefore left a lot to be desired. Still, learning on the job provided to be fruitful.
“When I joined Builder.io in June 2022,” he said, “it became a full-time effort, and I was joined by Adam Bradly and Manu Martinez-Almeida to work on it full-time. Turns out that between the three of us, we have a lot of experience building frameworks, so we had a clear idea of what we wanted Qwik to be.”
To give a better understanding of Qwik’s appeal, Hevery describes how it stands up against other frameworks. “Current frameworks only care about client rendering. SSR [server-side rendering] is really an afterthought. As a result, client hydration is the only way to make an application work, and hydration is expensive and results in slow application startups.”
He continued, “By taking on the whole problem end-to-end, SSR is not an afterthought but a central goal of Qwik. The result is a vastly better start-up performance of the website. Qwik can deliver most sites with zero JavaScript and then download only the code that is needed to process a specific user interaction.”
For example, when you navigate to a product page on Amazon you will encounter numerous pieces of the site. The shopping cart, ratings, product details, menu, etc. all have to be loaded. But, as Hevery notes, “as a user, you don’t need all of those parts at once.”
“It would be expensive to delay the first interaction until all of the code is downloaded and executed, yet that is what hydration does,” he continued. “Instead, Qwik sends pure HTML — and a tiny polyfill of about 1kb — to the client. If the user clicks add to cart, only the code to add the item to the cart and update the cart component is downloaded and executed. This makes the amount of JavaScript on the browser light, no matter the complexity of the overall application.”
Refined Lazy Loading
Qwik boasts “fine-grained’ lazy loading, which refers to the way Qwik breaks applications into smaller pieces and grants servers the freedom to decide what large bits of code should be sent to the client and when.
“With current frameworks, lazy-loading falls as the responsibility of the developer,” said Hevery. “In Qwik, the lazy-loading falls on the framework. Each callback (effect, listener, render function) is lazily loadable. This fine-grained nature, with the ability to render components independently, gives Qwik the power to not download code if the code is not strictly needed.”
Hevery went on to explain that the closest technology to Qwik is in fact a staple for Google (where he worked from 2005-2021). “Internally, Google has a framework called Wiz that powers Google Search, Photos and Gmail, among others. Wiz has instant-on properties for the application and, depending on how you look at it, you may say it is resumable. Strictly speaking, there is no server execution of JavaScript that is paused in Wiz, so there is no ‘resuming’ going on, but the effect is the same. Wiz has an open source portion called jsaction that, as far as I can tell, has pioneered the idea of serializing listeners into HTML. Qwik’s listener serialization is very similar to that of jsaction.”
Hevery said that Qwik is vastly different from Wiz at its core and in its implementation and syntax, but the goal is the same — applications that start instantly.
What’s Next for Qwik?
Qwik is currently available on Builder.io’s GitHub. Hevery adds that the project is getting close to general availability. “We are pretty confident in Qwik, but want to have a complete solution before declaring it so. For this reason, we are also working on Qwik City, a meta-framework for Qwik that allows us to build websites with file-based routing. Additionally, we are working on Qwikify React, which allows migration from Qwik sites and allows Qwik to use React ecosystem libraries, such as Material Components.”
Hevery says Qwik gives developers a new approach to building web apps. “Fine-grained lazy-loading and resumability results in instant-on applications and SEO solutions from the start,” he promised.