在大前端盛行的今天，似乎前后端分離的開發模式才是大勢所趨，而SPA的概念更是應運而生。現在隨便構建一個web應用程序如果你不是使用SPA的話，就會感覺有點low，但是真的是這樣嗎？今天這篇文章我們就來一起探討下，構建現代web應用時該如何進行選擇。
作者：依樂祝
博客園鏈接：https://www.cnblogs.com/yilezhu/p/10626459.html
目前大伙都知道的是可通過兩種通用方法來構建 Web 應用程序：在服務器上執行大部分應用程序邏輯的傳統 Web 應用程序，以及在 Web 瀏覽器中執行大部分用戶界面邏輯的單頁應用程序 (SPA)，后者主要使用 Web API 與 Web 服務器通信。 也可以將兩種方法混合使用，最簡單的方法是在更大型的傳統 Web 應用程序中承載一個或多個豐富 SPA 類子應用程序。
但合適使用傳統 Web 應用程序，何時使用SPA呢？針對這個問題最近在看微軟《使用 ASP.NET Core 和 Azure 構建新式 Web 應用程序》白皮書的時候。里面如是說：
何時應使用傳統 Web 應用程序：
- 應用程序的客戶端要求簡單，甚至要求只讀。
- 應用程序需在不支持 JavaScript 的瀏覽器中工作。
- 團隊不熟悉 JavaScript 或 TypeScript 開發技術。
何時應使用 SPA：
- 應用程序必須公開具有許多功能的豐富的用戶界面。
- 團隊熟悉 JavaScript 或 TypeScript 開發。
- 應用程序已為其他（內部或公共）客戶端公開 API。
此外，SPA 框架還需要更強的體系結構和安全專業知識。 相較於傳統 Web 應用程序，SPA 框架需要進行頻繁的更新和使用新框架，因此改動更大。 相較於傳統 Web 應用，SPA 應用程序在配置自動化生成和部署過程以及利用部署選項（如容器）方面的難度更大。
所以如果你要使用 SPA 模型改進用戶體驗時必須權衡這些注意事項。
Razor 組件
ASP.NET Core 3.0 引入了一種新模型，用於構建稱為 Razor 組件的豐富的、交互式和可組合的 UI。 Razor 組件允許開發者在服務器上使用 Razor 構建 UI，並使用名為 WebAssembly 的 JavaScript 庫將此代碼傳遞到瀏覽器和執行客戶端。 ASP.NET Core 3.0 仍在開發中，但你應該會期望在本電子書的 3.0 更新中看到有關此技術的詳細信息。 有關 Razor 組件（名為 Blazor 的代碼）的詳細信息，請參閱 Blazor 入門。
何時選擇傳統 Web 應用
以下內容詳細介紹前面提到的選擇傳統 Web 應用程序的原因。
應用程序的客戶端要求簡單，可能要求只讀
對許多 Web 應用程序而言，其大部分用戶的主要使用方式是只讀。 只讀（或以讀取為主）應用程序往往比那些維護和操作大量狀態的應用程序簡單得多。 例如，搜索引擎可能由一個帶有文本框的入口點和用於顯示搜索結果的第二頁組成。 匿名用戶可以輕松提出請求，並且很少需要使用客戶端邏輯。 同樣，一般而言，博客或內容管理系統中面向公眾的應用程序主要包含的內容與客戶端行為關系不大。 此類應用程序容易構建為基於服務器的傳統 Web 應用程序，在 Web 服務器上執行邏輯，並呈現要在瀏覽器中顯示的 HTML。事實上，網站的每個獨特頁面都有自己的 URL，搜索引擎可以將其存為書簽和編入索引（默認設置，無需將其添加為應用程序的單獨功能），這也是此類情況的一個明顯優勢。
應用程序需在不支持 JavaScript 的瀏覽器中工作
如需在有限或不支持 JavaScript 的瀏覽器中工作的 Web 應用程序，則應使用傳統的 Web 應用工作流編寫（或至少可以回退到此類行為）。 SPA 需要客戶端 JavaScript 才能正常工作；如果沒有客戶端 JavaScript，SPA 不是好的選擇。
團隊不熟悉 JavaScript 或 TypeScript 開發技術
如果團隊不熟悉 JavaScript 或 TypeScript，但熟悉服務器端 Web 應用程序開發，那相較於 SPA，他們交付傳統 Web 應用的速度可能更快。 除非以學習 SPA 編程為目的，或需要 SPA 提供用戶體驗，否則對已經熟悉構建傳統 Web 應用的團隊而言，選擇傳統 Web 應用的工作效率更高。
何時選擇 SPA
以下內容詳細介紹何時為 Web 應用選擇單頁應用程序開發樣式。
應用程序必須公開具有許多功能的豐富用戶界面
SPA 可支持豐富客戶端功能，當用戶執行操作或在應用的各區域間導航時無需重新加載頁面。 SPA 很少需要重新加載整個頁面，因此加載速度更快，可在后台提取數據，並且對單個用戶操作的響應更快。 SPA 支持增量更新，可保存尚未完成的窗體或文檔，而無需用戶單擊按鈕提交窗體。 SPA 支持豐富的客戶端行為，例如拖放，比傳統應用程序更容易操作。 可以將 SPA 設計為在斷開連接的模式下運行，對客戶端模型進行更新，並在重新建立連接后將更新最終同步回服務器。 如果應用要求包括豐富的功能，且超出了典型 HTML 窗體提供的功能，則應選擇 SPA 樣式應用程序。
請注意，SPA 通常需要實現內置於傳統 Web 應用中的功能，例如在反映當前操作的地址欄中顯示有意義的 URL（並允許用戶將此 URL 存為書簽或對其進行深層鏈接以便返回此 URL）。 SPA 還應允許用戶使用瀏覽器的后退和前進按鈕尋找用戶意料之中的結果。
團隊熟悉 JavaScript 和/或 TypeScript 開發
編寫 SPA 需要熟悉 JavaScript 和/或 TypeScript 以及客戶端編程技術和庫。 團隊應有能力像使用 Angular 一樣使用 SPA 框架編寫新式 JavaScript。
參考 - SPA 框架
- Angular
https://angular.io- JavaScript 框架的比較
https://jsreport.io/the-ultimate-guide-to-javascript-frameworks/
應用程序已為其他（內部或公共）客戶端公開 API
如果已提供一個 Web API 供其他客戶端使用，則相較於在服務器端窗體中復制邏輯，創建一個利用這些 API 的 SPA 實現更加容易。用戶與應用程序交互時，SPA 廣泛使用 Web API 來查詢和更新數據。
決策表 - 選傳統 Web 或 SPA
下面的決策表總結了在傳統 Web 應用程序和 SPA 之間進行選擇時要考慮的一些基本因素。
| 因素 | 傳統 Web 應用 | 單頁面應用程序 |
|---|---|---|
| 需要團隊熟悉 JavaScript/TypeScript | 最低 | 必需 |
| 支持不帶腳本的瀏覽器 | 支持 | 不支持 |
| 客戶端應用程序行為極少 | 適合 | 不必要 |
| 豐富而復雜的用戶界面要求 | 受限 | 適合 |
總結
今天給大家介紹了在構建現代Web應用時究竟是選擇傳統web應用還是spa的一些參考，希望對大家在進行現代web開發時技術選型時有所幫助。如果你有不同的看法可以在下面留言。