你可能不需要單頁面應用
隨著 React、Angular、Vue.js、Elm 等前端框架的迅速崛起,單頁面應用在 WEB 中無所不在。對大多數開發者來說,單頁應用已經成為他們‘預設’工具集的一部分,在開始一個新的專案時,由於技術選型形成了思維定勢,一些開發者往往直接想到:一個提供 REST API 的服務端,和 React、Angular、Vue、Elm 中的一個前端框架。
這些工具有什麼問題嗎?當然沒有,實際上我喜歡用這些工具進行開發,然而我只會在實際需求將我推向那個方向時才會選擇這種架構。如果沒有明確的原因去開發一個單頁面應用,我在本週每一個工作日都會使用傳統服務端渲染的架構進行開發,這種架構很簡單並且開發起來更快:
-
無狀態請求傳統的 WEB 伺服器是無狀態的(HTTP協議是無狀態的),這意味著每個端點都可以單獨進行推理和測試。相比之下,單頁面應用必須在整個會話期間精確地定義狀態是如何載入,重新整理以及銷燬的,同時會引入一些快取和同步的問題,這些問題是傳統服務端渲染不存在的。
-
瀏覽器知道如何處理傳統的架構如果你要使用單頁面應用路由,你必須多寫一些程式碼用來模擬一些簡單的瀏覽器功能。我已經花了好幾個小時用來確保瀏覽歷史被正確的管理,比如載入動畫看起來是否平滑,使用者通過瀏覽歷史跳轉時恢復滾動位置等,真的糟心。
-
更少、更成熟的工具框架像 Rails、Phoenix、Laravel 等,它們已經出現很長時間了並且很穩定。我在5年前學習了 Ralis,並且我的知識依然完全相關。於此同時我還學了 Gulp,CoffeeScript、BackboneJS 和 SASS ,而這些都已經被新的技術取代 。我們應該減少對 JavaScript 的過度依賴避免JavaScript 疲勞
-
免費的搜尋引擎優化單頁面應用不得不新增一些基礎設施和程式碼,確保能夠被搜尋引擎爬蟲進行索引。如果你的動態頁面需要進行搜尋引擎優化,使用傳統的服務端渲染實現起來更簡單。
這些點意味著單頁面應用為開發者帶來了更多複雜度和認知負荷。在我的開發經驗中,負責度和認識負荷是導致軟體出現 Bug 和開發速度下降的最大的因素。
適合單頁面應用的場景
如我所說,大多數需求場景下預設的選擇應該是傳統的服務端渲染應用。然而,有些場景可能強制你選擇單頁面應用架構:
-
核心功能具有實時性的應用(如 Slack)
-
核心功能是富UI互動的應用(如 Trello)
-
不同場景需要共享很多狀態的應用(如 Spotify)
這些產品必須使用單頁面架構保證應用穩定執行,這就是為什麼對這些公司來說這種架構是正確的選擇。然而許多 WEB 應用沒有這些需求,那麼這些複雜度就可以被避免。
混合解決方案
即使你的應用需要一些實時性的能力或者富互動,你也大可不必對整個應用使用單頁面架構。一種好的方式是將小的前端應用嵌入到傳統架構中。
GitHub 就使用了這種混合方案,它們整個網站的骨架是傳統的 rails 應用程式,某些區域比如 project tabs 就是用嵌入式的前端應用。這是一種結合了兩種方式的優雅解決方案,這個方案牛逼之處方在於你可以從簡單的地方開始,然後逐步新增更復雜的 UI 互動。
我相信我現在的專案Plausible 會朝著正確的方向迭代。在未來這個應用的主要 UI 將會是富互動,但是剩下的部分仍然可以使用傳統服務端渲染的架構。
一切歸結於權衡
就像程式設計中的所有東西一樣,單頁面應用和傳統服務端渲染的比較中沒有唯一的答案。在一些場景下可以使用單頁面應用,比如開發一個時髦的實時應用。然而我們需要意識到對開發速度造成的影響。如果不需要單頁應用,我們可以避免在應用中加入一些複雜度,並且傳統的路由要快得多。
在工作時選擇正確的架構會對生產力造成巨大的影響,並最終取得專案的成功。我們要確保兩種架構都是我們的開發工具,這樣我們可以在不同情況下使用最優方案。