在傳統 Web 應用程式和單頁應用程式 (SPA) 之間作選擇
「Atwood 定律：任何可以用 JavaScript 撰寫的應用程式，最後都將以 JavaScript 撰寫。」
- Jeff Atwood
現在有兩種建置 Web 應用程式的通用方法：在伺服器上執行大多數應用程式邏輯的傳統 Web 應用程式，以及在網頁瀏覽器中執行大多數使用者介面邏輯的單頁應用程式 (SPA)，後者主要使用 Web API 與網頁伺服器通訊。 也可以使用混合式方法，最簡單方式為在較大的傳統 Web 應用程式中，裝載一或多個豐富且類似 SPA 的子應用程式。
使用傳統 Web 應用程式的時機：
應用程式用戶端的需求簡單或甚至是唯讀。
應用程式需要在不支援 JavaScript 的瀏覽器中運作。
您的應用程式對外公開，且受益於搜尋引擎的探索和轉介。
使用 SPA 的時機：
應用程式必須公開具有許多功能的豐富使用者介面。
您的小組熟悉 JavaScript、TypeScript 或 BlazorWebAssembly 開發。
您的應用程式必須已針對其他 (內部或公開) 用戶端公開 API。
此外，SPA 架構需要更多的架構和安全性專業知識。 由於頻繁的更新及新的用戶端架構，SPA 架構會經歷比傳統 Web 應用程式更大的變動。 設定自動化的建置和部署程序，以及使用容器等部署選項，可能比傳統 Web 應用程式更難用於 SPA 應用程式。
基於這些考量，必須權衡 SPA 方法對使用者體驗的改善。
Blazor
ASP.NET Core 包含用來建置豐富、互動式且可組合之使用者介面的模型，稱為 Blazor。 Blazor 伺服器端可讓開發人員使用 C# 和 Razor 在伺服器上建置 UI，並使用持續性 SignalR 連線將 UI 以互動方式即時連線到瀏覽器。 BlazorWebAssembly 為 Blazor 應用程式引進了另一個選項，讓這些應用程式能夠使用 WebAssembly 在瀏覽器中執行。 由於這是在 WebAssembly 上執行的實際 .NET 程式碼，因此您可以重複使用來自應用程式之伺服器端部分的程式碼和程式庫。
Blazor 提供全新的第三個選項，用來評估是要建置純伺服器轉譯 Web 應用程式還是 SPA。 您可以使用 Blazor 建置豐富、類似 SPA 的用戶端行為，而不需要進行大量的 JavaScript 開發。 Blazor 應用程式可以呼叫 API 來要求資料或執行伺服器端作業。 這些應用程式可以在必要時與 JavaScript 交互操作，以利用 JavaScript 程式庫和架構。
請考慮使用 Blazor 建置 Web 應用程式的時機：
您的應用程式必須公開豐富的使用者介面
比起 JavaScript 或 TypeScript 開發，您的小組更熟悉 .NET 開發
如果您正在考慮將現有的 Web Forms 應用程式移轉至 .NET Core 或最新的 .NET，那麼建議您檢閱免費的電子書《適用於 Web Forms 開發人員的 Blazor》，了解是否有必要將其移轉至 Blazor。
如需 Blazor 的詳細資訊，請參閱開始使用 Blazor。
選擇傳統 Web 應用程式的時機
下節將詳細說明前述挑選傳統 Web 應用程式的理由。
您的應用程式具有簡單且可能是唯讀的用戶端需求
許多 Web 應用程式主要以唯讀方式供絕大多數使用者使用。 唯讀 (或主要為讀取) 的應用程式往往比維護和操作大量狀態的應用程式簡單許多。 例如，搜尋引擎可能包含文字方塊的單一進入點，和用於顯示搜尋結果的第二個頁面。 匿名使用者可以輕鬆發出要求，且幾乎不需要用戶端邏輯。 同樣地，部落格或內容管理系統的公開應用程式，通常主要由幾乎沒有用戶端行為的內容所組成。 這類應用程式很容易建置為傳統的伺服器型 Web 應用程式；在 Web 伺服器上執行邏輯並轉譯 HTML 使其顯示於瀏覽器中。 網站的每個獨特頁面都有自己的 URL，可透過搜尋引擎加上書籤並編製索引 (根據預設，不需另外將此功能新增為應用程式的個別功能)，在此情況下也是明顯的優勢。
應用程式需要在不支援 JavaScript 的瀏覽器中運作
需要在有限或不支援 JavaScript 之瀏覽器中運作的 Web 應用程式，應該使用傳統 Web 應用程式工作流程來撰寫 (或至少能夠改為使用這種行為)。 SPA 需要用戶端 JavaScript 才能運作；如果不可用，則 SPA 就不是好選擇。
您的小組不熟悉 JavaScript 或 TypeScript 開發技術
如果您的小組不熟悉 JavaScript 或 TypeScript 但熟悉伺服器端 Web 應用程式開發，那麼比起 SPA 應用程式，他們可能可以更快交付傳統 Web 應用程式。 除非目標是學習編程 SPA 或是需要 SPA 提供的使用者體驗，否則對於已經熟悉建置傳統 Web 應用程式的小組而言，傳統 Web 應用程式是更具生產力的選擇。
選擇 SPA 的時機
下節將詳細說明應何時為您的 Web 應用程式選擇單頁應用程式開發樣式。
應用程式必須公開具有許多功能的豐富使用者介面
SPAs 可以支援豐富的用戶端功能，且當使用者採取動作或在應用程式各區域間巡覽時，也不需重新載入頁面。 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
- React：https://reactjs.org/
- Vue.js：https://vuejs.org/
您的應用程式必須已針對其他 (內部或公開) 用戶端公開 API
如果您已經支援其他用戶端使用的 Web API，則建立利用這些 API 的 SPA 實作會較容易，不用重現伺服器端格式中的邏輯。 當使用者與應用程式互動時，SPA 大量使用 Web API 來查詢及更新資料。
選擇 Blazor 的時機
下節將詳細說明應何時為您的 Web 應用程式選擇 Blazor。
您的應用程式必須公開豐富的使用者介面
如同以 JavaScript 為基礎的 SPA，Blazor 應用程式可以支援豐富的用戶端行為，而不需要重新載入頁面。 這些應用程式對使用者的回應更快，只擷取回應指定使用者互動所需的資料 (或 HTML)。 如果設計得當，則伺服器端 Blazor 應用程式可設定為以用戶端 Blazor 應用程式的形式執行，支援此功能後只需進行最少的變更即可。
比起 JavaScript 或 TypeScript 開發，您的小組更熟悉 .NET 開發
相較於使用 JavaScript 或 TypeScript 等用戶端語言，許多使用 .NET 和 Razor 的開發人員更具生產力。 由於應用程式的伺服器端已使用 .NET 進行開發，因此使用 Blazor 可確保小組中的每位 .NET 開發人員都能了解並可能會建置應用程式前端的行為。
決策資料表
下列決策表摘要列出在傳統 Web 應用程式、SPA 或 Blazor 應用程式之間作選擇時需要考慮的一些基本因素。
| 因素 | 傳統 Web 應用程式 | 單一頁面應用程式 | Blazor 應用程式 |
|---|---|---|---|
| 小組必須熟悉 JavaScript/TypeScript | 最少 | 必要 | 最少 |
| 支援無指令碼的瀏覽器 | 支援 | 不支援 | 支援 |
| 最少的用戶端應用程式行為 | 適用 | 大材小用 | 可行 |
| 內容豐富且複雜的使用者介面需求 | 有限 | 適用 | 適用 |
其他考量
傳統 Web 應用程式往往比 SPA 應用程式更簡單，且有更好的搜尋引擎最佳化 (SEO) 準則。 搜尋引擎 Bot 可以輕鬆地取用傳統應用程式中的內容，而對索引 SPA 的支援可能缺乏或有限。 如果您的應用程式受益於搜尋引擎的公開探索，這通常是重要的考慮因素。
此外，除非您已為 SPA 的內容建置管理工具，否則可能需要開發人員進行變更。 傳統 Web 應用程式通常更容易讓非開發人員進行變更，因為大部分的內容只是 HTML，且可能不需要建置處理序來預覽或甚至部署。 如果貴組織中的非開發人員可能需要維護應用程式的內容，則傳統 Web 應用程式可能是較好的選擇。
當應用程式具有複雜的互動式表單或其他使用者互動功能時，SPA 就會大放異彩。 對於需要驗證才能使用，且因此公用搜尋引擎編目程式無法存取的複雜應用程式，SPA 在許多情況下是絕佳的選項。
