構建現代Web應用時到底是選擇傳統web應用仍是SPA

在大前端盛行的今天，彷佛先後端分離的開發模式纔是大勢所趨，而SPA的概念更是應運而生。如今隨便構建一個web應用程序若是你不是使用SPA的話，就會感受有點low，可是真的是這樣嗎？今天這篇文章咱們就來一塊兒探討下，構建現代web應用時該如何進行選擇。

做者：依樂祝
博客園連接：http://www.javashuo.com/article/p-sfiscyup-bg.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開發時技術選型時有所幫助。若是你有不一樣的見解能夠在下面留言。