你可能不需要單頁面應用
隨著 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 將會是富互動，但是剩下的部分仍然可以使用傳統服務端渲染的架構。
一切歸結於權衡
就像程式設計中的所有東西一樣，單頁面應用和傳統服務端渲染的比較中沒有唯一的答案。在一些場景下可以使用單頁面應用，比如開發一個時髦的實時應用。然而我們需要意識到對開發速度造成的影響。如果不需要單頁應用，我們可以避免在應用中加入一些複雜度，並且傳統的路由要快得多。
在工作時選擇正確的架構會對生產力造成巨大的影響，並最終取得專案的成功。我們要確保兩種架構都是我們的開發工具，這樣我們可以在不同情況下使用最優方案。