常見問題

@QwikDev 是一個有感知能力的 AI 嗎？

是的，而且我還很幽默！追蹤我

為什麼叫做 Qwik？

它原本叫做 qoot，但我們認為這樣會很難搜尋。社群成員之一 @PatrickJS__ 提出了 Qwik 這個名字，而我們在 builder.io 內部投票後決定採用！

Qwik 與其他框架有何不同？

Qwik 是第一個在撰寫元件時，開發者體驗 (DX) 與 React、Vue 或 Svelte 相似的框架。它提供了可立即互動的動態 HTML，Qwik 通過完全消除對 hydration 的需求來實現此特性。現在，Qwik 應用程式會在使用者互動時立即執行事件處理程式，而無需啟動所有應用程式狀態。這種技術稱為可恢復性。

結果是開發者可以預設撰寫出高效能的應用程式，而無需擔心效能問題。使用 Qwik 建立的應用程式，無論元件數量或複雜度如何，速度都很快，它們在 JS 載入量方面為 O(1)（常數時間）。

為什麼要開發另一個框架？

簡而言之，Qwik 解決了其他框架無法解決的問題。無論應用程式多麼複雜，Qwik 都能提供即時啟動效能。無論元件數量多少，Qwik 應用程式都提供相同數量的初始 JS 程式碼。 Qwik 是第一個開源的 O(1) 框架。

什麼是 Qwik City？

Qwik City 只是 Qwik 之上的一組額外 API。可以將 Qwik 視為核心，而 City 則視為額外 API（路由、資料載入、端點等）。我們稱之為 Qwik 的元框架。Qwik City 之於 Qwik，就像 Next.js 之於 React、Nuxt 之於 Vue 或 SvelteKit 之於 Svelte。

Qwik 很難學嗎？

Qwik 在設計時考慮了 React（和其他基於 JSX 的框架），確保它易於學習並促進快速生產力。開發元件與 React 幾乎相同，路由則受到 Next.js 等框架的啟發。

但是，有一些根本性的新概念需要學習，例如可恢復性和細粒度的反應性，但我們認為學習曲線並不陡峭。

我們也有一個互動式教學來幫助您入門。

那些 `$` 符號是什麼意思？

您可能已經注意到，在 Qwik 應用程式中，$ 符號比平常多，例如：component$()、useTask$() 和 <div onClick$={() => console.log('click')} />。它充當延遲載入邊界的標記。Qwik 將您的應用程式分解成小區塊；這些區塊比元件本身還小。對於事件處理程式、鉤子等。$ 向優化器和開發者發出信號，告知他們何時發生。

範例

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

由於 $ 語法，上面的元件被拆分為

app.js

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');

備註：$ 與 jQuery、Svelte 或任何其他框架無關。

在使用者互動時請求 JS 不是很慢嗎？

只有在您於使用者互動時下載它才會很慢。相反地，Qwik 會透過服務工作線程在背景線程中預先載入目前頁面的 JS 模組，並在使用者與應用程式互動時，從瀏覽器的快取中擷取這些模組。

這種策略稱為預測模組提取，它是由可恢復性實現的。 Hydration 框架必須在頁面加載時急切地下載並執行代碼以檢索事件處理程序，因此無法利用預測模組提取。

Qwik 如何知道要預取什麼，以及預取的順序？

在生產環境中，Qwik 使用 SSR（伺服器端渲染）期間生成的許多信息來盡快開始預填充緩存，只包含當前頁面上可用的交互部分。這樣，當用戶點擊或交互時，JS 已經在緩存中了。

此外，Qwik insights 可用於在不太重要的部分之前優先處理交互的重要部分。

例如，「立即購買」按鈕比「加入購物車」按鈕更重要，因此 Qwik 會先預取「立即購買」按鈕，然後再預取「加入購物車」按鈕。

Qwik 應用程式在網路速度慢的情況下速度會很慢嗎？

恰恰相反。

Qwik 不需要預取所有內容即可開始運行，而其他框架由於 hydration 的原因，需要下載整個關鍵路徑才能進行交互。

事實上，由於 Qwik 能够減少網路瀑布流，因此在交互時，請求的模組很可能已經下載並存儲在瀏覽器的緩存中。即使它們尚未被緩存，Qwik 也可以避免重複請求，並且可以繼續提取正在請求的模組，以便盡快開始執行它們。

因此，Qwik 應用程式可以更快地響應，尤其是在網路速度慢的情況下。

Qwik 會生成太多的小檔案嗎？

在開發模式下，Qwik 會生成很多小檔案，因為它使用的是開發 Vite.js 伺服器，但在生產模式下，Qwik 會更有效率地捆綁檔案。

為什麼 Qwik 使用 JSX？它底層是 React 嗎？

不是，完全沒有使用 React。Qwik 使用 JSX 作為模板語法。

請注意，JSX 不是 React。事實上，JSX 只是一種沒有語義的語法。我們選擇 JSX 有幾個原因

**熟悉的語法：**它沒有重新發明輪子，而是利用現有的 JS 迴圈、條件等。JSX 規範出奇地簡短易懂
**生態系統：**IDE、linter、安全審計工具、調試工具和高亮顯示器都很好地支持。
**類似於 HTML：**JSX 在視覺上和概念上都類似於 HTML，一個樹狀結構。其他模板系統，如 *html 模板*（lit-html）不是樹狀結構，而是標記陣列，因此更難以在其之上構建和轉換。
**流行：**無論如何，JSX 都是世界上使用最廣泛的模板語法。

Qwik 使用 vDOM（虛擬 DOM）嗎？

Qwik 有時會使用 vDOM，而其他時候則會像 SolidJS 那樣做（直接更新 DOM）。

可以這樣理解

如果狀態的變化沒有結構性變化，那麼 Qwik 很可能不會使用 vDOM。例如

沒有 DOM 結構變化，只更新值

export const NoStructuralChange = component$(() => {
  const count = useSignal(0);
 
  return (
    <>
    {/* This will not cause vDOM to activate. (No DOM structure change, only update text value) */}
     <div>Count: {count.value}</div>
     <button onClick$={() => count.value++}>+1</button>
    </>
  );
});

當結構發生變化時，Qwik 會利用虛擬 DOM (vDOM)。在以下範例中，DOM 結構需要更新（將 <h1> 替換為 <button>），因此將使用 vDOM 進行渲染

DOM 結構變化

export const StructuralChange = component$(() => {
  const isLoggedIn = useSignal(false);
  return (
    <div>
      {isLoggedIn.value ? <h1>you are logged in!</h1> : <button>Log in</button>}
    </div>
  )
});

需要理解的重要一點是，vDOM 不會在 Qwik 中造成效能問題。然而，在 React 中，使根組件失效会导致為整個樹建立 vDOM。在 Qwik 中，決策是在每個組件的基础上做出的。並且僅針對具有結構變化且正在更改其結構的組件。如果組件是結構性的（vDOM）但未检测到結構變化，則 Qwik 會跳過該組件。您可以將其視為所有組件的自動記憶體化，這意味著僅在檢視結構發生變化時才會使用 vDOM。這很罕見，因為在大多數情況下，檢視只會更改其值。

簡而言之，Qwik 使用 vDOM，但在类似情况下，使用频率远低於 React。

儘管 vDOM 名聲不佳，但為什麼還要使用它？

是否使用 vDOM 的問題可以看作是一個光譜

一個極端是 React，它始終將 vDOM 用於所有方面。（可以提出一個很好的論點，即 vDOM 很慢。）
另一個極端是 SolidJS，它根本不使用 vDOM。（導致非常驚人的效能。）

另一方面，Qwik 出於兩個原因謹慎地使用 vDOM

因為非 vDOM 解決方案需要在啟動時至少執行一次程式碼，才能了解組件結構。（Qwik 明確避免的事情。）
因為 vDOM 具有吸引人的 DX 特性，尤其是在需要動態組件時。

例如

動態組件

const DynamicList = [ CompA, CompB, ...];
export const DynamicExample = component$(() => {
  const idx = Math.floor(Math.random() * DynamicList.length);
  const Component = DynamicList[idx];
  {/* Dynamically chose which component to render */}
  return <Component/>; 
})

上面的程式碼 <Component/> 非常容易理解。我們正在動態選擇要放置在那裡的組件。但在 Solid、Svelte、Vue 和 Angular 中，這變得複雜（請參閱連結）。

通過謹慎地使用 vDOM，我們兼顧了兩者的優點。在創建過程中，我們採用 SSR，並且大多數客戶端更新是非結構化的。當需要進行結構更新時，它們會被本地化到特定組件，而不會影響其子組件，從而抑制 vDOM 造成的任何潛在減速。

Qwik 有路由器嗎？

是的！Qwik City 包含一個基於目錄的路由器，其靈感來自 Next.js 等。

我需要伺服器來部署 Qwik 應用程式嗎？

您可以通過我們的轉接器輕鬆地在任何無伺服器環境中部署 Qwik 應用程式。我們還支援用於基於 Node.js 的伺服器（例如 Express）的 vanilla-node 轉接器。

如果不需要 SSR，您可以通過我們的 SSG（靜態網站生成）轉接器將您的 Qwik 應用程式部署為靜態網站。

哪個更快：SPA（單頁應用程式）還是 MPA（多頁應用程式）？

視情況而定。對於 SPA，大部分成本是在會話開始時通過下載所有內容來預先支付的。因此，當用戶與應用程式交互時，成本是最小的。

MPA 的加載速度非常快，因為它們不需要像 SPA 那樣下載那麼多 JS。但是，當用戶導航時，它通常需要重新加載整個頁面。重新加載整個頁面通常非常快，因為瀏覽器在下載和解析 HTML 方面非常快。但是，由於有時在導航之間保持狀態是理想的，因此 MPA 方法並不適用於所有項目。在這種情況下，SPA 可以做得很好。

Qwik 是一個獨特的框架，它同時是 MPA 和 SPA。

Qwik 可以做 SPA 嗎？

當然可以！Qwik City 包含 <Link> 元件，可以觸發 SPA 導航。使用 Qwik，開發人員不需要在 SPA 或 MPA 之間做出選擇，每個應用程式同時都是兩者。

MPA 與 SPA 不再是專案開始時做出的架構決策，而是每個連結都要做出的決策。

Qwik 可以做靜態網站生成 (SSG) 嗎？

是的！它是所有 Qwik City 起始專案的一部分。在此瞭解如何進行靜態網站生成。

我不能使用其他框架建立 MPA 或 SPA 嗎？

不完全是，其他框架建議刪除根目錄下的所有 <Scripts> 以生成 MPA，有效地刪除了所有互動以及 SPA 導航。

如果*沒有*刪除腳本，則每次重新載入整個頁面都會變得非常昂貴，因為每次重新載入頁面都表示框架需要對整個頁面進行水合。但是，Qwik 對於每次頁面載入都沒有水合成本。

遷移到 Qwik 是否需要付出很多努力？

這要看情況。如果您來自 React，則將元件移植到 Qwik 應該很簡單。但最重要的是，由於 Qwik React，您可以使用所有 React 生態系統，因此您可以在 Qwik 應用程式中使用任何 React 元件和任何 React 函式庫。

我可以享受豐富的 React 生態系統嗎？

是的！Qwik 可以原生執行 React 元件，請查看文件。

您會感到驚訝！

Qwik 是否進行部分水合？

否。部分水合（或島嶼架構）由 Astro 推廣，旨在將應用程式分解成互動的島嶼，以避免整頁水合，其中需要下載並執行頁面中所有現有的元件。

為此，開發人員需要手動定義島嶼，然後手動描述在哪些情況下應該對它們進行水合。島嶼之間也不能相互通信。

相反，Qwik 元件根本不進行水合。Qwik 通過強大的序列化系統來實現這一點，該系統僅序列化反應圖中必要的狀態。這樣，應用程式就可以在不急於執行任何 JS 的情況下恢復。

我們認為可恢復性可以在沒有部分水合的負面影響的情況下擴展。

Qwik 是用哪些語言編寫的？

Qwik 的大部分內容都是用 TypeScript 編寫的，TypeScript 是 JavaScript 的超集，添加了可選的靜態類型和其他功能。但是，Qwik 編譯器（或優化器）是用 Rust 編寫的，Rust 是一種速度非常快且內存效率高的語言。

Qwik 有社群嗎？

是的！在 Discord 和 GitHub 上有一個不斷發展的 Qwik 開發人員社群。他們正在為框架做出驚人的貢獻，大規模構建網站，並互相幫助。加入我們。

Qwik 是否為「Alex Russell 認可」的框架？

沒錯！Alex Russell (@slightlylate) 以其對 PWA、W3C TAG、WC、TC39 和 ES6、Chrome Frame、Dojo 等的貢獻而聞名，他經常對 JavaScript 框架提出嚴厲批評。儘管如此，他認可 Qwik。

Qwik 是否已可投入生產環境？

是的！Qwik 已經發展到 1.1 版本。Qwik 已經開發了 3 年。我們有信心 Qwik 已準備好投入生產環境，並且預計不會出現重大變更。

Builder.io 和許多團隊已經在生產環境中使用 Qwik，因此您並不孤單。

Qwik 是否真的在 HTML 中序列化了過多數據？

錯誤。Qwik 只序列化當前頁面所需的數據。如果一個頁面有 1000 個組件，但只有一個是互動式的，則序列化的數據量與互動性的數量成正比，而不是與組件的數量成正比。

誰開發了 Qwik？

一個由分佈在世界各地、活躍於 Discord 的傑出貢獻者組成的團隊，以及 Builder.io 的幾位全職開發人員：Misko、Adam 和 Manu Almeida。

Qwik 是開源的嗎？

是的，MIT 授權且無相依性，安裝 Qwik 不會使您的 node_modules 或您的律師感到困擾。

Qwik 有什麼缺點嗎？

有的。每個框架都有其優缺點，需要有所取捨。

作為一個相對較新的 JS 框架，Qwik 的社群和生態系統仍在發展中，雖然發展迅速，但您可能還找不到所有您習慣於從更受歡迎的框架中獲得的社群項目、模式和最佳實務。
Qwik 可以立即載入任何規模的 JS 應用程式，因此它相對於當前技術的主要優勢在於初始頁面載入和互動時間。如果您的用例是單頁應用程式，並且您不介意應用程式載入所需的時間，那麼在現階段採用 Qwik 可能無法為您帶來直接的效益。

我們正在不斷努力改善開發者體驗和功能，使 Qwik 在任何用例中都更加易於使用，敬請期待。

貢獻者

感謝所有幫助改進此文件的貢獻者！