Introduction to Qwik, the fastest JavaScript framework

(source: BuilderIO/Qwik on Github)

Qwik starter CLI is a simple starter for you to try experimenting with Qwik first hand and to get a better understanding of just how different it is.

The CLI consist of these four examples, that will be expanded in the near future:

1. starter: A basic hello world.
2. starter-builder: A basic hello world integrated with Builder's Qwik API.
3. starter-partytown: A basic hello world showing how expensive tasks can be run on web-worker with Partytown
4. todo: A classic TodoMVC application.

Qwik is a unique JavaScript framework in that it is the only one that exists today that can hydrate out of order at a component level.

With the evolution of JavaScript and JavaScript frameworks, modern websites now require an enormous amount of JavaScript to become interactive. And, the more our site grows, the more increase we see in the site complexity which ultimately requires more code impacting negatively on the site start-up performance. Having too much JavaScript have two major impacts on the site i.e,

1. Network bandwidth: If our site has a vast amount of JS code, it would take a long time on a slower network to be downloaded on the client’s device.
2. Startup time: The start-up time of the site is affected as the entire JS code needs to be executed as part of hydration whenever the page is loaded.

As mentioned above, by eliminating the bottlenecks in the loading time, Qwik claims to achieve two important goals.

1. Instant load: Unlike other frameworks, quick is “resumable”, a new paradigm coined by the Qwik team to provide 0 hydration. This allows Qwik apps to have instant load interactivity, regardless of the size of the app or complexity. This means the app would load instantaneously without any lag on any network.
2. Performance: Qwik achieves this by delivering pure HTML, and incrementally loading JS as needed. This means, the site has extremely less JavaScript to be executed on load and downloads the code only on interaction. This makes it the “HTML” first framework.

How does Qwik achieve this?

Qwik basically achieves this through two important strategies:

1. Delay execution and download of JavaScript for as long as possible
2. Serialize the execution state of the application and the frame on the server and resume it on the client.

Let’s understand how Qwik implements these strategies.

Less JavaScript

As we saw above, one of the biggest problems for a site is the huge JavaScript that it has to ship to the client. Qwik straight away eliminates this by shipping out only the bare minimum JavaScript onto the client. In theory, a Qwik application only needs about 1KB of JavaScript to become interactive.

You might think if we are not shipping the JS code then how our app would become interactive? Actually, Qwik does ship it but not at the application startup but instead on the interactivity. Qwik uses a lot of information during SSR to start prefetching only the bits of interactivity of the current page as soon as possible, this way when the user clicks or interacts, the JS is already downloaded.

It’s similar to what we call lazy loading but Qwik takes lazy loading to the extreme level by progressively downloading JavaScript based on user interactions.

Hydration, we know, is the process of initializing the JavaScript framework after it has been rendered by the server. After rendering the HTML on the server, the JavaScript framework on the client needs to be reinitialized by installing all the event listeners on the DOM nodes, building up the internal data structure, and restoring the application state.

All current JavaScript frameworks require this step to make the application interactive. This hydration process is quite expensive and Qwik completely eliminates it which makes the Qwik application startup instantaneously. To achieve this, Qwik pauses execution on the server and resumes execution on the client.