作者丨Somnath Singh

　　譯者 | 胥磊

　　這是不是JavaScript框架的下一次革命的開始？顯而易見，是的！

　　通常的Web開發中存在一對不可調和的矛盾，即一方面需要更多的JavaScript代碼來實現你的客戶所期望的功能，而另一方面為了使你的網站能被更快速的加載，又不得不去考慮減少JavaScript的代碼量。作為一名開發者總在試圖去取得這兩者間的平衡。

　　如果現在告訴你，你可以隨意寫大量的JavaScript代碼，即使達到數千兆字節仍然不需要擔心應用的性能問題。更甚者是目前為止你所使用的每個著名的前端框架都在設計上存在根本性缺陷，你會作何感想？

　　首先我們要接受一個現實：JavaScript是不可避免的！這將使我們的工作更輕松。我們所處的困境就是我們太固執了，不承認目前網絡發展混亂的這個事實。很久之前我們就得出過這樣一個結論：從服務器端發送HTML到客戶端代價太高。于是就著手開發各種替代產品，這些年來我們不停地開發各種的框架與構建web的基礎做斗爭。

　　通過下面的說明，你就會完全明白我的意思。在一個典型的網絡應用中，我們將服務器端生產的HTML發送到客戶端，然后客戶端開始渲染它，當然現在你是不能與它互動的，接下來瀏覽器開始加載JavaScript的部分，最后就是執行相關程序和附加監聽，至此你才可以開始與它互動。

　　那么問題來了盡管服務器端已經將整個結構包括視圖都已經發送給客戶端了，但我們仍要等待直至能夠互動，導致整個過程的啟動時間被不必要地增加了。

　　加載時間過長的主要原因是每次都要從頭開始，整個過程稱為Hydration ，也就是瀏覽器讀取JavaScript部分，進而還確定各個部分的代碼又是屬于網頁上哪個位置和附加監聽。如果這就是整個問題的原因所在，難道我們不能通過懶加載來解決嗎？是可以這么做，但并不能解決問題！

　　試想一下，我們從服務器端發出HTML，到客戶端下載執行，其中特定的塊以懶加載方式完成。結果你可能也已經想到了，由于組件都是可見的，遇到懶加載的塊只能再次請求組件并完成Hydration ，這樣已經失去延遲加載的意義了。這也違背了我們最初使用懶加載的目的。

　　懶加載對既有系統起作用，主要是對那些不在渲染樹中的組件，對渲染樹中的組件來說，懶加載就是一種干擾。但是大家都沒有認識到這一點，當你反饋應用程序太大時，大部分人會主觀認為“只要懶加載所有東西就可以”，而沒有意識到實際上這并不容易做到，特別是我們上面提過的場景。

　　當然我們還可以采用島嶼架構，不需要在一開始就對所有的東西進行Hydration （代價有點高），而是在客戶與特定的組件進行交互時進行 。例如當我們與菜單進行交互時，只需要對菜單進行Hydration 。我們可以與任何特定組件互動，都只需要對特定組件Hydration 就行而不是整個應用程序。

　　雖然這是一種改進，但是如果這些 “島嶼”足夠大的話，島間的通信就成了一個問題。因為你剛剛把組件都變成一個個孤島，每個島都是一個獨立應用，應用間的通信問題就迫切需要解決。

　　現在Qwik來了！當我們和特定組件互動時，只要將這個組件加載就行，組件的父類和子類都不再需要隨同進行加載了。

　　Qwik還可以足夠智能地去識別當前組件是否還需要依賴其他組件（想象下電商網站上的添加購物車按鈕），并喚醒依賴組件。這時我們再打開網絡標簽就會發現初始頁面加載的JavaScript為零。

　　加載的頁面上沒有JavaScript并不稀奇，如果你所請求的是一個靜態頁面任何的框架都能做到這一點。Qwik的奇特之處也并非與此，它通過查看你的代碼判斷后得出結論“當前不需要任何JavaScript，現在不需要發送”。所以你會發現在我們點擊按鈕之前，JavaScript并沒有被加載。

　　單個JS加載時間看似“點滴”，大量累加很快就會變成 瀑布”。慶幸的是我們頁面的加載時間并沒有因此變長。因為依賴Qwik可以讓你隨心所欲地寫JavaScript，而不用再用擔心包的大小或性能過慢。

Next.js vs Qwik

　　此外，它還會很聰明的在后臺為網絡遲緩的用戶預加載文件，不用特意考慮就能實現令人難以置信的應用性。

獨創性通常被當成魔術

　　當我初次接觸虛機的時候就覺得非常神奇 “這不可能是真的，居然可以在一個系統中運行另外一個系統？”。看似神奇的東西，背后卻是純粹的技術。Windows系統里面啟動Linux當初對我來說是那么不可思議，但讓我興奮是另有原因。當你啟動Linux并登錄后，打開一個應用程序（例如文字處理器），接著開始打字，然后在某個時間你保存了虛機，然后把相關文件發送給你的朋友。當你的朋友通過文件恢復虛機時，顯示界面正好是當初我們離開時的，而不必經過開機，打開文字處理器，再找到最后離開時的輸入位置，這才是吸引我的地方！

　　這些也正是Qwik所提供的。應用在服務器端啟動，當達到一個特定的狀態后拍下快照，然后以HTML的形式將快照發送到客戶端，客戶端就可以直接展示快照時的特定狀態。從本質上講網站啟動慢的原因是我們必須全部加載后再進行Hydration ，整個過程代價是高昂的。

　　Qwik之所以快，因為它跳過了啟動，客戶端直接展示了服務器端的確切狀態，其中包含了我們想要執行的代碼，還可以訪問語法環境，用以更新可能被其他組件共享的狀態，當然狀態本身也是懶加載的。

　　“最好的代碼是完全沒有代碼”。Qwik的快并不是因為它的效率高，而是因為它善于避免工作，帶來了一種全新的渲染方式，稱為可恢復性渲染。這也是我們在線播放電影的方式以非線性的方式進行，由用戶決定他們想要應用的哪部分和什么時候要。所以Qwik開辟了一個全新的世界，支持你在多個后端的邊緣服務上渲染你的頁面，然后將它們合并作為一個完整的響應。

總結

　　幾千年前，釋迦摩尼就告誡我們要選擇中庸之道。但我們的開發太固執，仍然選擇走極端。有一群人告訴你要全部使用JavaScript，而另一群人則告訴你千萬不要選擇JavaScript，其余剩下的人則讓你以損失性能為代價，或多或少捆綁包袱來使用JS。

　　Qwik作為一股清新的空氣，與我們以前使用的框架都不同。在這我不是為某個框架做布道，但我們必須承認它的革命性。希望有更多的框架采用這種方式，它代表了前進的方向，否則我們將永遠限于循環中。

　　原文鏈接：https://javascript.plainenglish.io/react-and-next-js-is-dead-something-new-is-finally-replacing-it-for-good-c792c48806f6

　　胥磊，51CTO社區編輯，某頭部電商技術副總監，關注Java后端開發，技術管理，架構優化，分布式開發等領域。