譯者 | 李睿

審校| 孫淑娟

Qwik對響應式用戶界面（UI）的工作方式進行了大膽的反思。其核心前提是框架從頭開始構建，以使用最少的JavaScript交付HTML，只要足夠的JavaScript就可以根據需要逐步引入交互性。

Qwik使用一種細粒度的模型來隔離應用程序的分段，這些分段根據需要進行水合。通過從基本原則出發，Qwik可以實現其他無法實現的性能，并代表了前端JavaScript的另一種發展路徑。  

Qwik的狀態  

Qwik仍處于早期版本中，但它已經推出了一段時間。在StackBlitz中有一個功能完整的示例，一個REPL游樂場和一個命令行工具。Qwik也已經發展到支持對開發人員更友好的、類似響應的語法。其底層仍然是一個高級的、獨一無二的響應式引擎，它定義了狀態、模板和偵聽器的響應邊界。

（1）可恢復性

Qwik使用了巧妙的服務器端和客戶端渲染的組合，以避免當代框架在兩次（一次在服務器上，一次在客戶端上）執行水合工作時重復。

正如Qwik的創建者Misko Hevery所寫：Qwik的基本思想是它是可恢復的。它可以在服務器停止的地方繼續。在客戶端上只需要執行最少的代碼。

或者換一種方式：讓服務器設置一個功能盡可能完整的HTML頁面，并允許客戶端執行盡可能少的工作，以便繼續或恢復用戶的進程。

帶有服務器端渲染（SSR）的響應式框架中的典型流程是，首先在服務器上生成應用程序的版本，然后將其發送到客戶端，客戶端渲染架式應用程序。在這一點上，客戶端應用程序接管了任務，基本上必須再次引導同一應用程序，以便將一個正常運行的客戶端連接在一起。

這個過程被稱為水合作用。有幾種巧妙的方法可以提高水合作用的效率，但Qwik放棄了這些方法，采用了一種名為“可恢復性”的新方法。  

可恢復性意味著客戶機可以從服務器中斷的地方開始，而不必在客戶機上重新構建應用程序。

（2）交互時間  

Qwik努力提升的指標是交互時間(TTI)。這是指用戶向網頁發出請求和網頁響應用戶交互之間的時間間隔。

加載時間(TTL)跟蹤客戶端完成接收所有所需數據所需的時間(因此是一個主要由文件大小和網絡速度決定的指標)，交互時間(TTI)考慮了現代JS框架的一個突出事實：一旦下載了數據，客戶端就必須解壓縮，并執行所需的JavaScript代碼，以使頁面具有交互性。

響應式引擎需要做很多工作。引擎必須分解/解析所有標記(如JSX)，這些標記通過變量和表達式來根據狀態的變化修改所顯示的內容，以及根據代碼的行為。  

另一端是一個簡單的HTML頁面。一旦瀏覽器掌握了它，頁面就可以開始移動了。這就是谷歌的PageSpeed Insights給Reddit.com這樣的頁面打32分(滿分100分)，而原始HTML打100分的原因。

（3）閉包和偵聽器

Hevery將快速TTI的技術障礙描述為“死于封閉”。簡而言之，每個閉包必須維護封閉的信息世界這一事實意味著運行時應用程序是一個急切加載代碼的“千層餅”。  

Qwik采用的解決方案是使用與序列化監聽器交互的全局事件監聽器。換句話說，通用事件偵聽器用于編排按需實現的偵聽器，而不是下載并封裝在閉包中(不管它們是否實際執行)。  

Qwik的目標是提供與HTML一致的響應性，使其可序列化。根據標記中封裝的信息，只需要一個很小的可執行文件就可以在運行時顯示響應性。  

（4）代碼拆分并進行微調  

從另一個角度來看，Qwik正在執行微調的代碼拆分。當用戶需要時，它會根據需要加載交互代碼。如果有必要，捆綁器可以將這些塊打包成更大的塊。  

Qwik從頭構建，有三個獨立的函數，用于創建狀態、模板和偵聽器。這允許框架只加載手頭任務所需的內容。

狀態、模板和偵聽器這三個邊界一度由開發人員直接編碼。多虧了一個新的優化器工具，它可以將類響應式語法轉換為這些幕后邊界，可以得到一個相當熟悉的DX。優化器的工作是將實際代碼轉換為一組微小的存根，以便在必要時以小塊恢復應用程序。  

在優化器中，模板和偵聽器用美元符號表示，而狀態由useStore鉤子處理。稍后將看到這個語法。  

Qwik代碼的最終輸出看起來與其他框架不同，但是將Qwik與優化器一起使用可以使其與其他框架相媲美。Qwik還推出了QwikCity，這是一套更高級的功能（例如路由），可以讓構建完整的應用程序更容易。  

使用Qwik進行操作

現在已經理解了Qwik背后的概念，以下了解一下如何使用它進行編碼。清單1顯示了用Qwik編寫的一個簡單組件。(這個例子來自Qwik FAQ。)  

（1）清單1.簡單的Qwik組件  

import { component$ } from '@builder.io/qwik';
export const App = component$(() => {
  console.log('render');
  return <p onClick$={() => console.log('hello')}>Hello Qwik</p>;
});

清單1顯示了Qwik中的一個組件被定義為一個匿名函數，從Qwik庫傳遞到組件$函數中。每當在Qwik中看到美元符號$時，這是在讓優化器知道它需要做一些工作。Qwik將在應用程序的美元符號部分設置其細粒度延遲加載邊界。  

清單1中的onClick$是Qwik特殊語法的另一個例子。Qwik將使用一些技巧，在實際需要時只加載支持該功能所需的JavaScript。  

清單1中的代碼將被優化器分解為幾個片段，如清單2所示。  

（2）清單2.編譯后的Qwik組件  

/ The app.js file itself
import { componentQrl, qrl } from "@builder.io/qwik";
 const App = /*#__PURE__*/ 
 componentQrl(qrl(()=>import('./app_component_akbu84a8zes.js'),   "App_component_AkbU84a8zes"));
 export { App };
 // app_component_akbu84a8zes.js
 import { jsx as _jsx } from "@builder.io/qwik/jsx-runtime";
 import { qrl } from "@builder.io/qwik";
 export const App_component_AkbU84a8zes = ()=>{
     console.log('render');
     return /*#__PURE__*/ _jsx("p", {
         onClick$: qrl(()=>import("./app_component_p_onclick_01pegc10cpw"),  "App_component_p_onClick_01pEgC10cpw"),
         children: "Hello Qwik"
     });
 };

  // app_component_p_onclick_01pegc10cpw.js
 export const App_component_p_onClick_01pEgC10cpw = ()=>console.log('hello');

在清單2中可以看到，Qwik沒有包含實際的組件功能，而是使用庫中的componentQrl()函數包含了一個引用。這個函數接受一個qrl()函數，該函數使用匿名函數導入生成的組件文件。組件之間的這種關聯都是由優化器在后臺管理的。開發人員不需要直接考慮這個問題。  

QRL代表Qwik URL，這是Qwik引用將被延遲加載的方式。基本上，只要框架需要延遲加載某些內容，它就會插入一個QRL，由特定于QRL的消費者包裝(比如組件、狀態或模板函數)。  

例如，組件QRL可以在子組件中找到的代碼的正確時刻加載，而父組件可以快速顯示其布局。與onClick處理程序類似：當單擊發生時，可以對它進行計算。

（3）Qwik CLI  

該命令行工具可從npm獲得，具有所期望的基本功能，包括創建、開發模式和生產構建。Qwik CLI使用Vite作為構建工具。可以使用npm create啟動新應用程序qwik@latest，這將啟動一個交互式提示。

如果創建一個簡單的應用程序并運行產品構建，會得到一個dist目錄，在那里可以看到前面描述的所有獨立的可惰性加載的應用程序塊。  

Qwik調整  

了解Qwik語法的一個有趣的地方是Qwik Cheat Sheet，它提供了Qwik和React代碼的并排比較。人們可能會發現，這并不是一個很難的過渡。有些領域非常相似，有些則主要需要思維的轉變。更大的收獲是，Qwik中的響應式系統與類響應式框架完全不同，盡管優化器實現了相似的語法。  

Qwik對代碼拆分和延遲加載的創新方法為前端JavaScript提供了一種新的發展方式，而了解事情的發展將會很有趣。

原文標題：??Intro to Qwik: A superfast JavaScript framework??，作者：Matthew Tyson