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.
1st Generation of Web Apps
The first generation of rendering, as Hevery (The Creator of Angular and Qwik) said, was done on the server with technologies such as PHP. The server rendering was made interactive on the client with javascript (JQuery.) The role of the server here is to send a template every time it is called.
The server renders a sort of document that contains HTML and javascript. We use JQuery as a tool to add interactivity within the template.
So what’s the problem with this approach?
The issue is that we have to deal with two languages, one on the server (such as PHP) and another on the client side, which is undoubtedly Javascript which may cause confusion between the element that was written in PHP and its behavior in javascript and that leads to writing a functionality multiple times.
That's why this approach is hard to scale.
2nd Generation of Web Apps
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.
The concept is never reloading the page and only making calls to the server to update the state on the client side, but in the first launch, we load all the applications as a javascript code.
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.
Between 2nd & 3rd generation of Web Apps
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.
We pre-render HTML, and we hydrate it with javascript after that, so the result here is only to reduce the time of seeing a blank page. So, it’s not interactive until we hydrate it with the Javascript needed for the elements.
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.
For example, if we have a contact form at the bottom of the page and we are at the top of it, the contact form won’t be visible, and this way we don’t need to load the javascript needed for the form.
Only if we scroll down to the section where we have the contact form, this is when the hydration takes place to hydrate the components in our form with the Javascript needed.
3rd generation of Web Apps as the new era
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.
If you have the contact form at the bottom, we don’t call his javascript even if you scroll down, we call it only if you click on the send button. In order to understand this a bit further, let’s dive into some technical aspects.
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.
We load the javascript needed for the interaction only if we click on the button. The challenge here is how we do that.
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.
Conclusion
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.
Top comments (0)