Quick: A mindset for efficient website production and programming

Let’s take a brief look at the history of web frameworks.

In the beginning, when the web was created, the pages were completely static and connected to each other in a very simple way. However, the problem was that these statistics did not meet the needs of businesses. If we wanted several pages to have common elements, we had to repeat them and there was no way to get dynamic data from the database and display it on the pages.

For this reason, in the popular programming languages ​​of that time, frameworks were created to give us the ability to generate dynamic pages.

Many of you are familiar with these frameworks. For example, PHP, ASP.NET, Django, etc.

However, the market has proven that the growth rate of its needs is always higher than the available market facilities.

With the expansion of websites and access to more people, speed became an important issue.

It was no longer acceptable to wait a few seconds to open a website and suffer from downloading a few megabytes of data.

Having to wait for the page to reload by clicking on each link or button was not very attractive.

Solutions were provided to solve these problems. For example, compressing necessary resources such as scripts and styles or loading resources from several static domains. However, these solutions had limitations in increasing the speed, which did not please the taste of the market.

For this reason, newer infrastructures were formed. These infrastructures are used to remove resources that were not used during the compilation phase (tree shaking). And they combined different files together (bundling) and by removing their empty space and renaming their components, they made them smaller (minification).

And they provided the conditions that the whole program is first loaded in the browser, then it is executed. This made the user interact with the program, and go to different pages very quickly and the program reacts very quickly by pressing keys and links because the resources needed to display the next page were already loaded (SPA).

But this paradigm shift brought with it new challenges. The most important of these challenges was that search engines could not easily understand the content of such sites. For this reason, the sites and software that were produced in this way, although they were very pleasing to the user in terms of speed, suffered from the lack of marketing capabilities in search engines, which is one of the key pillars of the financial success of companies.

For this reason, we faced yet another change. This time, these frameworks, like the previous frameworks, first render the pages on the server and then send these pages to the user. This made it easy for search engines to understand the content of the pages and display them in their list (index). However, this meant that the user could not interact with the pages. The pages had turned into static and purely display elements.

If we were to add JavaScript separately to make them dynamic, we would practically return to the problems of the past. So what was the solution?

The solution was that these frameworks do two things. In the first step, render the pages on the server and send them to the user, and send so much side data from these pages that they can recreate a dynamic version of the pages (virtual DOM) on the user’s side (inside the browser).

This decision, which was made in many frameworks, is called hydration.

Hydration means watering. It’s like a static web page is a dry land without water and grass, and we water it (make it dynamic) with JavaScript to turn it into a garden or a green field.

But this had created a new problem.

The problem was that hydration took time. The pages were loading very fast at first (SSR or SSG), but when the user clicked on the buttons or swiped, they didn’t get any response.

This failure to receive a reaction sometimes lasted for several seconds (even tens of seconds). Search engines don’t like this. Therefore, in the basic vital signs of web pages (core web vitals), they considered an index called time to interact or the time required to activate a web page.

Frameworks try to reduce this time. But they had limitations. The time complexity of this task was O(n). That is, with the increase in the size of a page and the number of interactions of a page, the amount of code required to be executed on the user’s side would increase, and in the same way, the time required for a page to become dynamic would increase.

It was clear that with the increasing needs of businesses and the increasing demand of users to interact more with web pages, this time could not be reduced.

This is where Qwik came into play.

Quick was a framework whose mission from the beginning was:

Reduce the interaction time from O(n) to O(1) while keeping all the advantages of all previous frameworks.

Quick checks all project components during the build. In this phase, several issues are identified:

• Which components have no interaction with the user
• Which components have no way to change state at all
• What are the components that have a changeable state (including user interaction)?

Then all the components that do not have a changeable state are completely rendered on the server side, which is similar to the server components in React and NextJS.

But Quick’s masterpiece is building components that can be changed. Quick extracts the codes related to different parts of these components in very small and separate packages.

According to Mishko Hevery (creator of Quick who also created Angular), Quick breaks your code into millions of small parts.

And this different technique in the build makes it possible to load the site without sending all the codes related to the client to the user. In this case, the TTI of the site will decrease significantly. Because at the time of initial loading, only a small script with a compact size of less than one kilobyte is sent to the user and executed in the browser.

Then this primary script, which is called Loader, listens to all user interactions and browser pages. Whenever the user starts an interaction (such as pressing a button or opening a menu), this Loader notices and immediately requests the small piece related to that interaction from the server side.

Due to the low volume of the code, and due to the use of the prefetching technique, this small script is much faster than the ability of the user to visually understand the loading and execution page, and the user’s request to interact with that page element is answered.

In fact, it can be said that the dynamism of Internet pages in Quick is done at the smallest level. That is, instead of a large and complete script being requested and executed from the server side at the beginning of the page loading (for example, 200 KB and 4 seconds of time required for execution), each small part of the page that requires interaction is loaded and executed separately ( For example, 2 kilobytes and 50 milliseconds only for this button that was clicked).

This simple and very artistic technique has enabled Quick to be known as the first framework that will always display a fast page to the user, regardless of the size and size of your project.

So with Quick, whether you design a few simple interactions (equivalent to less than 50 kilobytes of script) or thousands of complex interactions (equivalent to several megabytes of script), the page loading speed will be the same in the browser.