Understanding qwik - Theoretical Concepts

Quickly get an understanding, know the general things.

Background

If using Client-Side Rendering (CSR), the first screen will be slow, what should we do?

This will be separated later.

Hydration

SSR rendering can be used, first render the first screen, and then use JS for subsequent rendering
However, the JS still needs to be downloaded and go through the hydration process, which means associating the HTML with the corresponding JS. Hydration does not mean re-rendering, it adds event listening logic to the HTML. Theoretically, FCP (First Contentful Paint) is very fast.
During the hydration process, the JS will run twice, once on the server-side and once on the client-side. Theoretically, it increases the TTI (Time to Interactive).
With SSR, it means having Node.js, which also means having requirements for security, stability, and high performance.

Partial Hydration

Astro attempts partial hydration, also known as island
Next.js/Nuxt.js both have the concept of server components
But qwik is completely 0 JS, providing only HTML, so the performance is strong enough. Next, qwik will be introduced
How to improve SSR performance
- For example, caching

stale-while-revalidate=<seconds> experimental indicates that the client is willing to accept stale responses while asynchronously checking for a new response in the background. The value in seconds indicates the length of time the client is willing to accept stale responses. --from MDN

For example, island architecture
Load and initialize based on events such as requestIdleCallback scheduling, viewport visibility, interaction possibility, and product value
Different from the progressive hydration mentioned above, partial hydration of islands does not affect the performance of other units

No Hydration

qwik proposes that "hydration is pure overhead", the hydration process is completely redundant, hydration is pure overhead
The most difficult part of hydration is finding events and connecting them. That is, where and what, what is the closure that closes app_state and framework_state.
app_state is the state understood by everyone
The state of the associated mapping of the framework
Hydration process: download component code - execute component code - restore state and locate association - add event handling to the DOM

Claimed to be the world's first O(1) JavaScript SSR framework

Reference interpretation articles

hydration is pure overhead All interpretation articles are derived from here
There is an article on Zhihu SSR framework challenger in the new era: qwik
The Challenge of Efficient Hydration dev.to
Qwik-The Ultimate Solution for Frontend Performance?

The difference between SPA and island, island generates JS requests only when there is a click interaction

Server component

RSC can put the rendering of some components on the server, and the frontend only does pure display, and only the dependencies of RSC will not be packaged into the client. This way, if a component has a larger third-party dependency, the third-party dependency can be placed in RSC, and the component can be run on the server and the generated result can be transmitted to the browser for display.

For example, a chart, canvas, or markdown rendering is completed on the server. In this way, the client cannot access the rendering process.

Principle Introduction

How to achieve it?

Simply put, the HTML contains relevant information for executing JS, and additional JS will be parsed and triggered for download when necessary. This HTML containing additional information is called additional information serialization, such as events, states, etc.

Pasted image 20231022184321

Record the events and states of the current component on HTML attributes, called serialization
JS is also embedded to map and compare in order to achieve event recovery

This ability is called resum-ability.

For example, a counter tool, which displays a static page by default, and only downloads and executes JS when clicked. Before the user performs any operations, there is no JS download and execution at all, which is a complete lazy loading. During the build process, many chunks will be generated, each of which is small and has a small granularity.

Is this the silver bullet to solve all problems? Not necessarily, for example, lazy loading execution also involves an activation process. Use dynamic prefetch technology reasonably.

The build artifacts of lazy loading will not be very large. Will there be too many? Traditional build tools handle granularity segmentation.

No need to worry about performance leaks after execution.

Built-in component$ method, indicating the boundary of lazy loading

Full-Stack Framework

A single page will not satisfy the basic requirements, so there is the "Qwik City" suite, which supports routing, layout, loader, validation, middleware, caching, etc.

Supports SSR and SSG.

Qwik focuses on components and state management
Qwik City is a suite of functions.

Outlook

It feels interesting, actually the transition from Vue/React is not that big.