用 Qwik 思考

Qwik 在較高的層面上與其他網頁框架非常相似。Qwik 是一個渲染元件樹以產生互動式應用程式的框架。

Qwik 的獨特之處不在於它做了什麼，而在於它如何實現其目標。Qwik 的目標是擁有即使在行動裝置上也能立即啟動的應用程式。Qwik 通過兩個主要策略來實現這一目標

1. 盡可能延遲 JavaScript 的執行和下載。
2. 將應用程式和框架的執行狀態在伺服器上序列化，並在客戶端上恢復。

Qwik 的目標是只下載和執行應用程式的最低限度程式碼。

延遲執行

盡可能延遲 JavaScript 的執行。

Qwik 應用程式的啟動速度很快，因為要執行的 JavaScript 程式碼量很少。（最簡單的情況下，Qwik 應用程式只需要大約 1KB 的 JavaScript 即可變得互動式。）

通過積極延遲應用程式的下載和執行，Qwik 可以提供近乎即時的啟動效能。目前這一代的網路框架都無法比擬這種實作方式。

Qwik 的速度快，不是因為它使用了巧妙的演算法，而是因為它的設計方式使得大部分 JavaScript 都不需要下載或執行。它的速度來自於不做其他框架必須做的事情（例如水合作用）。

可恢復性和序列化

可恢復性在這裡有詳細討論。可恢復性允許 Qwik 應用程式從伺服器停止的地方繼續執行。所有框架都需要跟踪有關應用程式狀態的內部資料結構。當前這一代的框架在從伺服器轉換到瀏覽器時，不會保留這些資訊。因此，框架的資料結構需要在瀏覽器中重建，重複伺服器上已完成的工作。資料結構的重建和監聽器的附加稱為水合作用。

在伺服器到瀏覽器的交接過程中，Qwik 會將監聽器、內部資料結構和應用程式狀態序列化到 HTML 中。因為所有資訊都在 HTML 中序列化，所以客戶端可以從伺服器停止的地方繼續執行。

問題是什麼？

現代網站需要大量的 JavaScript 才能變得互動式。過多的 JavaScript 會導致兩個問題

1. 網路頻寬：大量的程式碼被傳送到客戶端，在網速慢的情況下可能需要很長時間。
2. 啟動時間：程式碼一旦到達客戶端，就需要執行（作為水合作用的一部分），才能使網站具有互動性。

隨著 Qwik 應用程式變得越來越複雜，互動的保真度越來越高，這些年來程式碼量一直在穩步增長，而且沒有停止的跡象。簡而言之，Qwik 網站變得越來越複雜。而網站複雜性的增加反過來又需要更多的程式碼。所有這些程式碼都會對網站的啟動效能產生負面影響。

更糟糕的是，JavaScript 是單線程的；因此，Qwik 複雜的網站無法利用現代多核 CPU 的優勢。

我們是如何走到這一步的？

解決上述問題的方法既明顯又困難：傳送更少的 JavaScript。

顯而易見的是，使用較少 JavaScript 的網站效能會更好。

困難的是我們的工具並沒有幫助我們做到這一點。大多數 Qwik 工具解決問題的方式使得傳送更少的 JavaScript 變得很困難。這些工具在設計時只考慮解決特定問題，而沒有考慮它們生成的 JavaScript 程式碼量。

您是否需要解決渲染、樣式、動畫、A/B 測試、分析等問題？有一個工具可以解決這個問題。只需導入或添加一個 <script> 標籤，這些工具就可以解決您的問題，但代價是會使初始套件變得更大。

作為一個產業，我們常常忽略了軟體包大小的重要性。每個工具都各自解決了特定的問題，但大小從未被納入考量。當所有工具組合在一起時，大小就變成了一個問題，而到那時，開發人員已經無力回天了。

解決方案是什麼？

Qwik 從一開始就被設計用來解決軟體包大小的問題。小巧的軟體包大小是它的首要目標，所有其他的設計決策都以此為依歸。

Qwik 的重點不在於減少 JavaScript 的程式碼量，而在於不必在應用程式啟動時一次性將所有 JavaScript 傳送到用戶端。Qwik 是將「延遲載入 JavaScript」的概念發揮到極致的成果。

的確，Qwik 需要您以不同的方式思考和設計您的應用程式，但這樣做的結果是，初始 JavaScript 程式碼幾乎為零，並根據使用者互動逐步下載 JavaScript。

軟體包大小不應該是開發人員的問題

現今，軟體包大小是開發人員的問題。如果您遵循每個框架、工具等的最佳實務，您將會得到一個很大的軟體包。到那時，開發人員才會開始透過某種延遲載入邊界等方式來減輕問題。（但任何做過這件事的人都會告訴您：選擇很有限。）

業界的最佳實務導致了龐大的軟體包，網路上充斥著這樣的例子。

Qwik 的宗旨是，軟體包大小不應該是開發人員需要考慮的事情。它應該自然而然地成為框架設計的一部分。

Qwik 從一開始就被設計成可以產生許多可延遲載入的邊界。工具可以將您的應用程式分解成許多可延遲載入的區塊，而執行環境只會在需要時才下載它們。

為什麼不修正現有的框架／工具？

簡而言之，延遲載入的理念必須在底層完成，而且不能在不從根本上改變現有框架／工具的情況下，回溯性地加入它們。這種根本性的改變將與框架／工具及其各自的生態系統不相容，使其變得毫無用處。

當一個框架做出某些假設時，例如所有渲染都是同步的，那麼加入非同步延遲載入就會變得幾乎不可能。或者，如果一個框架從模板中恢復監聽器位置，那麼在網站可以互動之前，就必須先下載並執行這些模板。這些只是一些比較明顯的例子，但在實務上，有長尾效應的原因導致目前的思維模式不符合可恢復性的要求。

以上也意味著，現有的框架不可能將可恢復性作為一個功能加入。現有的框架永遠無法做到 Qwik 能做到的事情（而不破壞向後相容性）。

我們為什麼要開發 Qwik？

因為我們相信有更好的方式來建構網站。一種不需要在網站變得具有互動性之前，就必須在啟動時急切地下載大量 JavaScript 的方式。一種讓開發人員可以專注於添加功能，而不是如何將龐大的程式碼庫分解成更小的區塊的方式。一種讓網站能夠立即載入，以提供更好的使用者體驗的方式。而所有這些，都與應用程式程式碼庫的大小無關。

網頁速度真的重要嗎？

簡單來說：速度慢的網站會讓訪客卻步，讓企業損失數百萬美元。速度快的網站具有更好的 SEO、更好的使用者體驗，而且利潤更高。

以下是一些來自 web.dev 的例子