本文整理 Blazor 在 .NET 11 中的各項改進。
.NET 官方 Youtube 頻道在 2026-01-14 有一個直播，主題是〈Blazor Community Standup - Planning the future of Blazor in .NET 11〉。在這個直播中，Daniel Roth 介紹了 Blazor 在 .NET 11 的各項改進（蠻多的），也即時回答網友的一些提問。
在影片的 23:50，一名觀眾提了一個有點尖銳的問題：
「為什麼不使用 MVC 搭配一套流行的 JavaScript 框架？這看起來一點意義都沒有，好像是回到過去的 WebForms。還是我錯過了甚麼？」
Why not just MVC with one of the popular frameworks when needed, this seems so pointless 😦 like going back to WebForms, or am I missing something?
針對這個問題，主持人 Daniel Roth 與 Javier Calvaro Nelson 的回答並未否定 MVC，只是強調新架構的一致性與開發體驗的整合。底下進一步整理他們對此問題的具體回應：
- MVC + JS 仍然可以繼續使用
Roth 說 MVC 搭配 Vue.js 或其他 JavaScript 框架絕對沒問題，且 MVC 依然是受支援的框架，不會消失。 - 跨越不同範式的「斷層」
MVC + JS 的問題在於開發者必須在兩種不同的程式設計範式（Programming Paradigms）之間來回切換。也就是說，開發者需要同時維護伺服器端的 C# (MVC/Razor Pages) 與客戶端的 JavaScript 框架。這意味著開發者需要在不同的思維模式之間跳轉：一下子處理 CSHTML 與 Tag Helpers，一下又要切換到 JavaScript 的邏輯。Blazor 試圖消弭這種斷層。 - 單一且一致的元件模型
Blazor 的優勢在於它提供了一個單一的元件模型（One Component Model），能一致地適用於所有架構模式。無論是處理純靜態的伺服器渲染（Static SSR），還是處理高度互動的客戶端邏輯（WebAssembly/Server），開發者都只需要用 同一種方式撰寫元件。此外，開發者也不需要為了增加互動性而切換語言或框架，這消除了架構上的割裂感。 - 整合性的優勢
Javier 補充說明，當使用外部 JavaScript 框架時，開發者必須自己解決「整合」的挑戰，例如如何處理身份驗證（Auth strategy）以及如何與後端端點通訊。由於 Blazor 同時擁有伺服器端與客戶端的控制權，它能讓這種前後端的溝通與整合變得更簡單、更乾淨，無需開發者手動拼湊不同技術堆疊。
總結來說，主持人認為 Blazor 並非單純回到 WebForms，而是為了解決現代 Web 開發中「前後端分裂」的痛點，提供一個從頭到尾都能使用 .NET 技術的完整解決方案。
看到這裡，我自己是有點感動：微軟依然持續投入資源在改進 Blazor。不只 Blazor，在最近幾次的 .NET 改版當中，我也有看到 Windows Forms 的持續改進（雖然改進幅度相對少一點）。
以下根據影片中的內容，重點整理了 .NET 11 針對 Blazor 的各項改進。由 AI 協作，工人審較。
一、統一的開發架構：Blazor 成為官方首選
為什麼選擇 Blazor？
.NET 團隊在 .NET 11 的規劃中明確表示：如果你要使用 .NET 構建 Web 應用程式，官方建議使用 Blazor。雖然傳統的 ASP.NET Core MVC 和 Razor Pages 仍然受到完全支援，但團隊的主要投資與創新重點已聚焦於 Blazor。
單一元件模型的優勢
Blazor 的核心優勢在於它解決了傳統開發模式的架構割裂感：
- 告別混合模式
傳統開發常需要結合 MVC/Razor Pages 與 JavaScript 框架（如 Vue.js 或 React）來處理互動需求，導致開發者需要在兩種不同的程式設計範式與語言之間切換。 - 全場景適用
Blazor 允許開發者使用單一的元件模型來涵蓋所有需求。無論是生成純靜態 HTML（Static SSR）、處理伺服器端互動（Interactive Server），還是執行客戶端邏輯（WebAssembly），開發者都能使用相同的元件語法與 C# 邏輯，無需在不同架構間跳轉。
二、強化靜態伺服器渲染：填補與傳統模式的功能差距
.NET 11 致力於將 Blazor 打造成能完全取代傳統 MVC 或 Razor Pages 的全能框架，核心策略是透過強靜態伺服器渲染（Static Server-Side Rendering, Static SSR）的功能，來填補目前 Blazor 與傳統開發模式之間的功能缺口。
1. 補足與 MVC/Razor Pages 的功能對齊（Feature Parity）
目前 Blazor 在靜態渲染模式下，缺少一些在傳統 ASP.NET Core MVC 或 Razor Pages 中常見且便利的功能。.NET 11 計劃補足以下缺口：
- TempData 支援
允許在請求之間暫存數據（例如重新導向後的訊息提示），這是 MVC 中非常常用的功能。 - Session State 存取
提供更直接的方式來存取伺服器端的 Session 狀態。 - 顯示名稱（Display Name）支援
類似於 MVC 的 Tag Helpers，支援屬性的 DisplayName 渲染，讓表單標籤生成更自動化。 - 快取機制（Caching）
計劃引入類似 MVC 中 Cache Tag Helper 的 Cache Component，讓開發者能更輕鬆地對靜態內容進行快取。
2. 在靜態渲染中引入客戶端表單驗證
在目前的 Blazor 版本中，若要進行客戶端表單驗證（Client-side validation），通常需要切換到互動式渲染模式（Interactive WebAssembly 或 Server），這對於簡單的表單頁面來說是一個很大的架構跳躍。
.NET 11 計劃在靜態伺服器渲染中加入基於 JavaScript 的客戶端驗證功能。這讓開發者可以保留靜態渲染的簡單性與效能，同時擁有即時的表單驗證體驗，就像傳統 MVC 搭配 jQuery Validation 或其他 JS 函式庫一樣，減少了必須啟用完整互動模式的「門檻」。
3. 優化 JavaScript 的載入與管理
傳統開發模式中，開發者習慣在特定頁面載入特定的 JavaScript。但在 Blazor 使用增強導航（Enhanced Navigation）時，因為頁面不會完全重新載入（僅修補 DOM），導致 Script 標籤的生命週期管理變得困難。
.NET 11 預計引入單頁 JavaScript 邏輯（Per-page JavaScript logic）的支援，讓開發者能更直觀地在特定頁面載入 JS 模組，並提供生命週期掛勾（Hooks）來處理導航進入或離開時的邏輯。這解決了在靜態渲染與增強導航模式下，傳統 JS 腳本容易失效或重複執行的問題。
4. 擴展元件的靜態渲染能力
為了讓更多內建元件能在傳統的請求–回應（Request-Response）模式下工作，團隊計劃改進 QuickGrid 元件：
目前 QuickGrid 的排序與篩選功能依賴互動模式，.NET 11 將使其支援靜態伺服器渲染。這意味著開發者可以在不建立 WebSocket 連線或下載 WebAssembly runtime 的情況下，構建功能豐富的數據表格，更貼近傳統 Web 應用的行為。
5. 互動式伺服器渲染（Interactive Server）的增強
針對使用 WebSocket 連線的 Blazor Server 模式，也計畫進行以下優化：
- 暫停與恢復（Pause and Resume）的改進
- 支援從伺服器端程式碼觸發電路的暫停與恢復（目前主要靠客戶端 JS 觸發）。
- 引入自動暫停策略，例如偵測到用戶閒置時自動暫停電路以釋放伺服器資源。
- 負載測試工具
提供開箱即用的工具，協助開發者更容易地對 Blazor Server 應用進行負載與壓力測試。 - 渲染模式邊界（Render Mode Boundary）的優化
改善靜態渲染與互動渲染元件之間的數據傳遞，例如讓 CascadingValues 或 RenderFragments 能更順暢地跨越這些邊界，減少開發者手動序列化數據的麻煩。
三、WebAssembly runtime 的重大整合
.NET 11 在 WebAssembly (WASM) runtime 的整合上有顯著的策略轉向與新功能引入，主要聚焦於 runtime 的統一（consolidation）以及多執行緒替代方案的標準化。
1. 核心 runtime 的整合：從 Mono 轉向 CoreCLR
整合背景與目標
目前 .NET 團隊必須分別維護用於伺服器與桌面的 CoreCLR，以及用於 WebAssembly 與行動裝置的 Mono runtime。這意味著每當要引入新功能（例如 runtime 要支援 async）時，必須在兩個不同的 runtime 中分別實作，這大幅增加了工程成本與支援的複雜度。
為了降低這種雙軌維護的成本，並統一技術堆疊，團隊正致力於將 WebAssembly 的執行基底從 Mono 遷移至 CoreCLR。透過整合成單一 runtime，未來的開發過程將變得更加敏捷，並能確保跨平台的功能一致性。
.NET 11 的狀態
這項工作非常浩大，因此在 .NET 11 中，CoreCLR 版的 WebAssembly 預計將以預覽（Preview）形式推出，並不會作為生產環境的預設選項。生產環境在 .NET 11 仍會維持使用 Mono runtime。
對現有開發的影響
由於團隊正全力進行這項遷移，針對現有 Mono runtime 的新功能開發（例如在 Mono 上實作多執行緒）將會暫停，以避免重複投入資源。
2. 引入 Web Worker 的一級支援（First-class Support）
為什麼需要 Web Worker？
由於完整的 WebAssembly 多執行緒功能因 runtime 遷移而推遲，.NET 11 計劃整合 Web Worker 的支援，作為處理並發任務的替代方案。
開發者常需要將高 CPU 負載的任務（例如大型 JSON 的反序列化或處理）移出 UI 執行緒，以免畫面凍結。雖然社群已有解決方案，且微軟內部的 Copilot Studio 也已自行實作此模式，但目前缺乏官方標準支援。
整合內容
.NET 11 將提供一個 .NET Web Worker 專案範本，讓開發者能更容易地在 Blazor WebAssembly 應用程式旁，建立並設定一個執行 .NET 程式碼的背景 Web Worker。
功能限制
這將提供建立 Worker 與執行程式碼的基礎架構，但初期不會提供高階的通訊機制（如強型別的 RPC）。開發者仍需使用較底層的訊息傳遞（Message Passing）來進行溝通。
額外的好處
使用 Web Worker 的另一個好處是解決記憶體管理問題。WebAssembly 的記憶體管理目前存在挑戰，一旦分配記憶體就很難歸還給作業系統。使用 Web Worker 後，當耗費大量記憶體的任務完成時，開發者可以關閉（Terminate）該 Worker，從而釋放相關的記憶體。
3. WebAssembly 3.0 標準的支援
隨著 CoreCLR 整合工作的進行，新的 runtime 預計將支援 WebAssembly 3.0 的功能集。這意味著未來基於 CoreCLR 的 WASM runtime 將能利用更現代的瀏覽器功能，儘管這也會稍微提高對瀏覽器版本的最低要求。
四、Blazor Gateway：簡化部署與託管的新組件
.NET 11 提議引入一個新組件 「Blazor Gateway」，旨在簡化 Blazor 應用程式的部署與託管，特別是為了與 .NET Aspire 整合而設計。
什麼是 Blazor Gateway？
Blazor Gateway 是一個旨在簡化 Blazor 部署的組件或容器映像檔，可以被視為一種「即開即用的雲端基礎設施盒子（Cloud infrastructure in a box）」。
- 技術基礎
它預計將基於 YARP (Yet Another Reverse Proxy) 構建，但會封裝成一套具有「固執己見（opinionated）」預設值的配置，讓開發者無需手動設定繁瑣的路由或反向代理規則。 - 目標
提供一個統一的 Host，既能用於本地開發，也能直接部署到生產環境（如 Kubernetes 或 Azure Container Apps），消除開發環境與生產環境之間的落差。
Blazor Gateway 解決的關鍵問題
1. 獨立 WebAssembly 應用程式的託管與代理
- 缺乏標準伺服器
目前部署獨立的（Standalone）Blazor WebAssembly 應用程式時，開發者往往需要自行研究如何配置 Nginx、GitHub Pages 或其他伺服器來託管靜態檔案。 - 跨域資源共享（CORS）與代理
用戶端直接呼叫後端服務時常會遇到 CORS 問題。Gateway 可以作為代理伺服器（Proxy），將請求轉發給後端服務，從而在開發和生產環境中解決這些通訊障礙。 - 靜態資產優化
Gateway 可以協助正確地提供預壓縮（Pre-compressed）的靜態檔案，確保應用程式以最佳效能載入。
2. 配置與服務發現的傳遞
- 配置流動
在分散式應用中，將伺服器端的配置（如環境變數、API 端點）傳遞給用戶端 WebAssembly 是一個挑戰。Gateway 提供了一個端點或機制，讓這些配置能輕易地從伺服器「流向」用戶端。 - 服務發現
它解決了用戶端如何知道要呼叫哪些後端服務的問題，自動處理服務網址的對應。
3. 伺服器端 Blazor 的負載平衡與連線管理
- 黏性會話（Session Affinity/Sticky Sessions）
對於 Blazor Server 應用，為了維持 WebSocket 連線，必須確保用戶的後續請求都導向同一台伺服器。目前這需要開發者手動配置負載平衡器，而 Gateway 旨在自動處理這種「黏性會話」的需求。 - 滾動更新（Rolling Deployments）
Gateway 未來可能支援與 Blazor 的「暫停與恢復」功能整合，允許在部署新版本時優雅地耗盡（Drain）舊伺服器的連線，實現不中斷服務的更新。
4. 遙測與診斷的整合
目前 Blazor WebAssembly 的運行數據很難直接顯示在 .NET Aspire 的儀表板（Dashboard）中。Gateway 可以協助收集並轉發用戶端的 OpenTelemetry 數據，讓開發者能在儀表板中統一監控前後端的狀態。
5. 統一開發與生產環境
目前開發時使用的是一個簡易的 Dev Server，但它包含許多不適合生產環境的代碼。Gateway 旨在成為一個既能用於本地開發，又能直接部署到生產環境（如 Kubernetes、Azure Container Apps）的標準化 Host。
總結：Blazor 的願景與承諾
.NET 11 對 Blazor 的改進展現了微軟對這個框架的長期承諾與願景。透過以下幾個核心策略，.NET 團隊正在將 Blazor 打造成一個真正能取代傳統開發模式的全能 Web UI 框架：
- 功能對齊
將傳統 MVC 的便利功能（如 TempData、Caching、Session）移植到 Blazor，並解決靜態模式下的互動痛點（如驗證、JS 管理）。 - Runtime 統一
透過將 WebAssembly runtime 從 Mono 遷移至 CoreCLR，實現技術堆疊的統一，降低維護成本，提升未來開發的敏捷性。 - 簡化部署
透過 Blazor Gateway 將靜態檔案託管、反向代理、負載平衡、服務發現以及遙測整合等功能打包在一起，解決 Blazor 應用在現代雲端原生環境中部署的碎片化問題。 - 無需妥協
確保開發者選擇 Blazor 時不需要因為缺少傳統功能而做出妥協，讓 Blazor 成為 .NET Web 開發的首選方案。
這些改進共同構成了一個清晰的訊息：Blazor 不僅僅是眾多選項之一，而是 .NET 團隊全力投資的未來 Web 開發方向。對於正在考慮或已經使用 .NET 進行 Web 開發的開發者來說，.NET 11 的這些改進將讓 Blazor 成為一個更加成熟、完整且強大的選擇。
沒有留言: