在我們團隊的開發歷程中，C# 和 .NET 框架一直是我們的主力語言，伴隨我們走過了無數個項目。當微軟推出 Blazor 這一革命性的框架時，我們對其充滿了期待。Blazor 以其優良的架構和微軟的強大背書，似乎預示著前端開發的新紀元。我們希望借助 Blazor 的優勢，快速構建與后臺服務配套的前端應用。然而，隨著開發的深入，我們發現這條路并不如預期順利，最終不得不放棄 Blazor，轉而使用其他 Web 技術。本文將分享我們的經歷，希望能為其他團隊提供參考。

1. 初識 Blazor 全棧 UI：滿懷期待

Blazor 的出現，讓我們看到了使用 C# 進行前端開發的可能性。對于習慣了 .NET 環境的開發者來說，這無疑是個好消息。我們可以在不切換語言的情況下，編寫前端代碼，提升了開發效率和代碼一致性。

Blazor 全棧 UI 的技術架構優勢明顯：

1. 統一的開發體驗：開發者可以使用相同的 C# 代碼和 Razor 組件在 Blazor Server 和 Blazor WebAssembly 之間進行無縫切換，簡化了多種應用類型的開發流程。

2. 靈活的應用架構：Blazor Web App 可以根據具體需求靈活選擇 Blazor Server 或 Blazor WebAssembly。

• Blazor Server 通過 SignalR 技術提供服務端和客戶端的實時數據傳輸，和較快的初始加載時間。

• 而 Blazor WebAssembly 可以在瀏覽器中高效運行，允許用戶離線使用，減少服務器負擔，提高用戶的交互體驗。

• 支持靈活地選擇 Server 還是 WASM 進行渲染，可以針對整個應用程序、某個頁面或控件設置渲染模式。

• 可以將 Server 搭建為 Backend-for-Frontend，寫后臺接口訪問數據庫。WASM 搭建為 Frontend，編寫布局和頁面。達到前后端分離，前端的頁面元素渲染和交互不再依賴后端，只有調用 API 獲取數據需要后端。

3. 增強的性能：.NET 8 中的 Blazor 具有更好的性能優化，包括更快的組件渲染和數據傳輸，提升了用戶體驗。通過加強導航（Enhanced Navigation）功能，使用戶在交互和導航時感覺在瀏覽 SPA 網站。

4. 利用渲染樹構建組件：提供了 ChildContent、ChildFragment 來靈活地自定義控件元素的樣式和行為，支持通過模板重寫控件內部的元素。

5. 用戶身份和權限認證：利用 Identity 無縫便捷地集成用戶驗證和權限控制，支持對某個頁面、控件、Controller，API 設置訪問權限。WASM 應用緩存了屬于客戶端的數據，無需在服務端維護，例如用戶身份信息、登錄狀態等等。

6. 熟悉的開發工具：Visual Studio 和其他 IDE 對 Blazor Web App 的友好支持，提供更好的調試體驗和開發效率。

2. 遭遇挑戰：理想與現實的差距

然而，理想很豐滿，現實卻很骨感。在項目推進過程中，我們逐漸感受到 Blazor 的局限性。以下是我們遇到的一些主要問題：

1. UI 組件庫有限：相比于 React、Vue 等成熟框架，雖然 Blazor 社區在不斷發展，但現有的 UI 組件庫仍然相對較少。并且，面對某些復雜的前端效果，我們發現 Blazor 難以將不同組件庫中的組件融合在一起使用，庫之間很難做到樣式和操作的統一，這嚴重影響了我們的開發效率。

2. 前端效果難以實現：Blazor 在處理某些前端效果時顯得力不從心。由于其運行機制的特殊性，一些在其他框架中輕松實現的動畫、交互效果，在 Blazor 中卻需要繞過各種限制，利用 JS 互操作來完成。這不僅降低了開發效率，也影響了用戶體驗。

3. 社區支持不足：一個框架的生態環境對于其發展至關重要。我們發現，當遇到問題時，幾乎無法在社區中找到解決方案。一些無法通過官方文檔解決的疑問，StackOverflow 或 GitHub 上的相關帖子寥寥無幾。這使得我們在排查和解決問題時陷入困境。

3. 展望未來：Blazor 的前景并不明朗

1. 缺乏實際應用案例：盡管 Blazor 在技術上有許多優點并受到微軟的支持，但目前為止，使用 Blazor 搭建網站的知名企業、公司或組織仍然相對稀少。這使得潛在用戶對其穩定性和長期可維護性產生疑慮。

2. 微軟的轉向：更讓人擔憂的是，微軟似乎不再為 Blazor 投入足夠的資源。近年來，微軟的重心逐漸轉移到人工智能（AI）領域，對 Blazor 的更新和支持力度明顯下降。這讓 Blazor 的未來充滿了不確定性。

4. 做出抉擇：從 Blazor 回到 Vue

經過一段時間的開發，我們團隊意識到，Blazor 可能并不適合我們未來的產品路線。盡管我們喜歡用 C# 開發，但在 Web 開發領域，其他技術棧在組件豐富性、社區支持和生態系統上顯然更具優勢。

綜合以上因素，我們不得不做出艱難的決定：

• 停止在新產品中使用 Blazor：為了項目的長期發展，我們決定在下一個產品中放棄使用 Blazor。

• 重構現有產品的前端部分：對于已經使用 Blazor 的產品，我們計劃在第二個版本中重構前端，改用更成熟的 Web 技術，如 Vue。

這一決策雖然艱難，但也是我們經過深思熟慮后的選擇。

5. 反思與建議：Blazor 的適用場景

通過這次經歷，我們發現選用 Blazor 可以從以下幾點因素去考量：

1. 團隊規模：Blazor 更適合單兵作戰的開發者，或 2 至 4 人的小團隊。這些開發者通常具有較強的 C# 和 .NET 背景，能夠快速上手，學習 Blazor 的負擔相對其他非 .NET 背景的開發者要小很多，可以利用現有的 .NET 技能快速構建和部署小型項目。

2. 應用類型：Blazor 非常適合用于構建功能相對簡單的標準管理系統，比如內部管理工具，進行數據錄入、生成報告、利用儀表盤和報表進行數據展示。這些應用通常不需要復雜的前端交互，且需求相對穩定，可以利用 Blazor 的組件化特性快速搭建。

3. 產品演化：Blazor 更適合那些在開發初期對功能和用戶界面需求有明確設定的產品。這種情況下，可以在產品發布后無需過多的擔心產品后期的接手和維護問題。減少產品變更和迭代所帶來的維護成本。

6. 結語

在這個快速發展的技術世界里，選擇一個合適的開發框架至關重要。Blazor 的理念值得肯定，但在當前階段，可能還不適合用于大型商業項目。我們的經驗教訓也提醒著其他團隊，在技術選擇上要更加謹慎和前瞻。

未來，我們仍會關注 Blazor 的發展，但在那之前，我們將選擇更適合當前需求的技術方案。盡管我們與 Blazor 的旅程暫告一段落，但這段經歷將成為我們繼續探索和學習的寶貴財富。

Disclaimer 聲明：本文由 AI 輔助完成撰寫

 TXRock
出處：cnblogs.com/txrock/p/18517222