辛宝Otto

辛宝Otto 的玄酒清谈

北漂前端程序员儿 / 探索新事物 / Web Worker 主播之一/内向话痨
xiaoyuzhou
email

Understanding qwik - Theoretical Concepts

image

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

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.

image

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.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.