Resumability

As previously mentioned, Qwik does not send JavaScript at startup; it only sends HTML and CSS. Upon launching the analysis on the site qwik.dev, the enormous differences with other approaches to the rendering process become apparent. To be honest, as has been previously stated, only 1KB of Javascript is sent. This script is inserted at the end of the page because the browser parses the HTML top-down and tries to resolve the various links, scripts, rendering of the HTML, and all the other tasks that the browser is asked to perform. This script is called qwikloader and is recognizable because, by inspecting the page, it can be seen.

Qwik Loader#

Upon analyzing the page of a Qwik application (Chrome Dev Tools --> Element Tab), the source code can be seen, and scrolling to the bottom of the page reveals this script.

xxxxxxxxxx

<script id="qwikloader">

((doc) => {

  [...]

})(document);

</script>

Inside this script, there is vanilla JavaScript code that contains a function IIFE, which, by its nature, is immediately invoked. It is used to make the application immediately ready to be interactive, and it knows how to download the rest of the application on an as-needed basis. Here's the magic trick that was being sought, but this is just the tip of the iceberg. Let's go deeper.

IIFE (Immediately Invoked Function Expression): It is a design pattern that is also known as a Self-Executing Anonymous Function and contains two major parts:

1. The first is the anonymous function with lexical scope enclosed within the Grouping Operator (). This prevents accessing variables within the IIFE idiom as well as polluting the global scope.

2. The second part creates the immediately invoked function expression () through which the JavaScript engine will directly interpret the function.

Source: MDN Web Docs Glossary

Ok, the code is minified, and it's not clear what it does, but by analyzing this code, it will be possible to fully understand the magic trick that Qwik is capable of doing. Well, there are at least two paths that can be taken. The simplest is to go to the Qwik repository and search for the file that declares this famous script called qwikloader within the framework. The project is open-source, so all the material needed to search and find this file is available. Starting from the root of the project, it's possible to simply try luck and search for a file called qwikloader; let's see if today is a lucky day.

Fortunately, now and then things go in the right direction and in fact, the first file is exactly what we need. We can read the code and try to understand what is being executed, we have more readable variables because the code here is not minified, we also have TypeScript which helps us understand the code better, but we cannot see the code in action and therefore it's difficult to follow the flow of the code and try to imagine how it will work in the browser. So we can try the other method that immediately comes to mind, let's try to insert a breakpoint in our browser and with the Chrome DevTools we go forward step by step to try to understand in broad terms what this piece of code does.

The same can be done to actively follow the debugging in the Qwik documentation site. First, it's necessary to open the DevTools; it's possible to search for qwik.dev and look for the element with (index) using the "Open file" function.