辛宝Otto 的玄酒清谈

Get a quick understanding and know the basics.

Background#

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

This will be discussed separately later.

Hydration#

• SSR rendering can be used to render the first screen, and then use JS rendering for subsequent screens.
• 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, but rather adding event listener logic to the HTML. In theory, FCP (First Contentful Paint) is very fast.
• During the hydration process, JS will run twice, once on the server-side and once on the client-side. In theory, this increases TTI (Time to Interactive).
• With SSR, we have Node.js, which means we have requirements for security, stability, and high performance.

Partial Hydration#

• Astro attempts partial hydration, also known as islands.
• Next/Nuxt have the concept of server components.
• However, qwik provides 0 JS and only offers HTML, which is powerful enough in terms of performance. 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 updates. The value in seconds indicates the length of time the client is willing to accept stale responses. --from MDN

• For example, the island architecture.
• Load and initialize based on events such as requestIdleCallback scheduling, viewport visibility, interaction possibility, and product value.
• Unlike 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" and the hydration process is completely unnecessary. hydration is pure overhead
  The most difficult part of hydration is finding and connecting the corresponding events, which are the "where" and "what". "What" is the closure that closes the app_state and framework_state.
• app_state is the state understood by everyone.
• The state associated with the framework's mapping.
• The hydration process: download component code - execute component code - restore state and locate associations - 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: The Challenger of SSR Framework in the New Era: qwik
• The Challenge of Efficient Hydration in JavaScript Frameworks dev.to
• Qwik-The Ultimate Solution for Frontend Performance?

The difference between SPA and island, island triggers JS requests only when clicked.

Server component

RSC can put the rendering of some components on the server, and the frontend only does pure display. Moreover, the dependencies of only RSC will not be bundled into the client. Therefore, if a component has a large 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. The client cannot access the rendering process.

Principle Introduction#

How to achieve it?

Simply put, the HTML contains relevant information for executing JS. When necessary, additional JS is parsed and triggered for download. This HTML with additional information is called extra information serialization, such as events, states, etc.

• Record the events and states of the current component on HTML attributes, which is 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. The static page is displayed by default, and the JS is only downloaded and executed when clicked. Before the user interacts, there is no JS download and execution at all, which is a complete lazy loading. During the build process, many small chunks are generated, each with 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 prefetching techniques 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.

The built-in component$ method represents 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 seems interesting, actually the transition from Vue/React is not that big.