Let us together see how web applications were built over different generational approaches. Before talking about Qwik, there is a history before it, which we can split by generations, each generation has a concept that changed everything.
Before starting here is our first article about Qwik:
So what’s the problem with this approach?
That's why this approach is hard to scale.
Here comes the second generation, the famous SPA (Single Page Application), the modern frameworks like AngularJS, Angular, React, or VueJS.
The first generation had an MPA (Multiple Page Application) approaches. Now, let’s return to SPA.
That was a revolutionary approach in the history of web development, but the history of the idea started with AJAX, which gives us the possibility to update data without reloading the page.
After that, JQuery came into play, which introduced an optimized approach to make dynamic pages or to give life to our pages, and other frameworks also, like KnockoutJS and BackboneJS, that tried to fix multiple issues.
Still, if we want to talk about the first SPA framework, it is by far AngularJS that was the most complete, because it contained dependency injection, two-way data binding, and templating.
All of that is based on an MVC (Model-View-Controller) architecture. The surprise here is what?
Misko Hevery, who created Qwik, is the same who created AngularJS, the first SPA framework.
So, what’s the problem with the SPA? It’s the first load, it will start with a blank page taking a long time to load, and it’s not scalable if we want to work on big applications.
Before the third generation, we should talk about the second and a half-generation, and its SSR (Server Side Rendering) with frameworks like NextJS or SvelteKit.
These ones introduced a different but not revolutionary approach. In SSR, we still build SPA applications but with a different concept.
For example in the process of loading JS, if the JS needed for a button is loaded we can interact with it, but the JS needed for a form is not loaded yet, the form is still not interactive.
Here comes another framework that tried to reduce the time consumed in this process, it’s the Astro framework.
Astro has a concept called Partial Hydration, so it doesn’t hydrate the page with JS until it’s visible.
The revolution has already started after the first revolution created by Misko Hevery. Here is the second one he created, Qwik Framework introduces Resumability.
We now have a solid understanding of hydration and partial hydration, but Resumability has an approach of “stop/resume,” resuming the application where the server left off in place of replaying all of the work.
The secret here is about entry points. Unlike other frameworks, Qwik gives us the ability to stop and resume the application from everywhere, and because it’s not limited to one entry point like modern frameworks.
The entry point provides us the possibility to download the code needed for a given interaction that we want to perform, whereas in the 2nd generation we can’t click on a button until all the application is loaded, and that’s the opposite of what resumability provides.
The question is quickly answered: Listeners!
Qwik has a global listener that ensures that every time an event happens, it searches for the specific listener needed and attaches it to the DOM in order to call the entry point needed.
It does that with the serialized information that is attached to the click event, for example.
In this article, we had a look at the evolution of rendering and how it used to impact the performance of web apps versus how it's impacting nowadays.
Now, a new generation is here, and Qwik is one among those who represent it in the best way. Other modern frameworks do not have the same approach because the difference is fundamental. It’s all about having (n) entry points so we can provide resumability and lazy loading.
Qwik is growing fast, and people like Evan You (the creator of VueJS) started to compare it with other frameworks and realized that something new is coming.