構建現代Web應用時究竟是選擇傳統web應用還是SPA

在大前端盛行的今天，似乎前後端分離的開發樣式才是大勢所趨，而SPA的概念更是應運而生。現在隨便構建一個web應用程式如果你不是使用SPA的話，就會感覺有點low，但是真的是這樣嗎？今天這篇文章我們就來一起探討下，構建現代web應用時該如何進行選擇。

目前大夥都知道的是可透過兩種通用方法來構建 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開發時技術選型時有所幫助。如果你有不同的看法可以在下麵留言。