在我們團隊的開發歷程中，C# 和 .NET 框架一直是我們的主力語言，伴隨我們走過了無數個專案。當微軟推出 Blazor 這一革命性的框架時，我們對其充滿了期待。Blazor 以其優良的架構和微軟的強大背書，似乎預示著前端開發的新紀元。我們希望藉助 Blazor 的優勢，快速構建與後臺服務配套的前端應用。然而，隨著開發的深入，我們發現這條路並不如預期順利，最終不得不放棄 Blazor，轉而使用其他 Web 技術。本文將分享我們的經歷，希望能為其他團隊提供參考。
1. 初識 Blazor 全棧 UI：滿懷期待
Blazor 的出現，讓我們看到了使用 C# 進行前端開發的可能性。對於習慣了 .NET 環境的開發者來說，這無疑是個好訊息。我們可以在不切換語言的情況下，編寫前端程式碼，提升了開發效率和程式碼一致性。
Blazor 全棧 UI 的技術架構優勢明顯：
- 統一的開發體驗：開發者可以使用相同的 C# 程式碼和 Razor 元件在 Blazor Server 和 Blazor WebAssembly 之間進行無縫切換，簡化了多種應用型別的開發流程。
- 靈活的應用架構：Blazor Web App 可以根據具體需求靈活選擇 Blazor Server 或 Blazor WebAssembly。
- Blazor Server 透過 SignalR 技術提供服務端和客戶端的實時資料傳輸，和較快的初始載入時間。
- 而 Blazor WebAssembly 可以在瀏覽器中高效執行，允許使用者離線使用，減少伺服器負擔，提高使用者的互動體驗。
- 支援靈活地選擇 Server 還是 WASM 進行渲染，可以針對整個應用程式、某個頁面或控制元件設定渲染模式。
- 可以將 Server 搭建為 Backend-for-Frontend，寫後臺介面訪問資料庫。WASM 搭建為 Frontend，編寫佈局和頁面。達到前後端分離，前端的頁面元素渲染和互動不再依賴後端，只有呼叫 API 獲取資料需要後端。
- 增強的效能：.NET 8 中的 Blazor 具有更好的效能最佳化，包括更快的元件渲染和資料傳輸，提升了使用者體驗。透過加強導航（Enhanced Navigation）功能，使使用者在互動和導航時感覺在瀏覽 SPA 網站。
- 利用渲染樹構建元件：提供了 ChildContent、ChildFragment 來靈活地自定義控制元件元素的樣式和行為，支援透過模板重寫控制元件內部的元素。
- 使用者身份和許可權認證：利用 Identity 無縫便捷地整合使用者驗證和許可權控制，支援對某個頁面、控制元件、Controller，API 設定訪問許可權。WASM 應用快取了屬於客戶端的資料，無需在服務端維護，例如使用者身份資訊、登入狀態等等。
- 熟悉的開發工具：Visual Studio 和其他 IDE 對 Blazor Web App 的友好支援，提供更好的除錯體驗和開發效率。
2. 遭遇挑戰：理想與現實的差距
然而，理想很豐滿，現實卻很骨感。在專案推進過程中，我們逐漸感受到 Blazor 的侷限性。以下是我們遇到的一些主要問題：
- UI 元件庫有限：相比於 React、Vue 等成熟框架，雖然 Blazor 社群在不斷髮展，但現有的 UI 元件庫仍然相對較少。並且，面對某些複雜的前端效果，我們發現 Blazor 難以將不同元件庫中的元件融合在一起使用，庫之間很難做到樣式和操作的統一，這嚴重影響了我們的開發效率。
- 前端效果難以實現：Blazor 在處理某些前端效果時顯得力不從心。由於其執行機制的特殊性，一些在其他框架中輕鬆實現的動畫、互動效果，在 Blazor 中卻需要繞過各種限制，利用 JS 互操作來完成。這不僅降低了開發效率，也影響了使用者體驗。
- 社群支援不足：一個框架的生態環境對於其發展至關重要。我們發現，當遇到問題時，幾乎無法在社群中找到解決方案。一些無法透過官方文件解決的疑問，StackOverflow 或 GitHub 上的相關帖子寥寥無幾。這使得我們在排查和解決問題時陷入困境。
3. 展望未來：Blazor 的前景並不明朗
- 缺乏實際應用案例：儘管 Blazor 在技術上有許多優點並受到微軟的支援，但目前為止，使用 Blazor 搭建網站的知名企業、公司或組織仍然相對稀少。這使得潛在使用者對其穩定性和長期可維護性產生疑慮。
- 微軟的轉向：更讓人擔憂的是，微軟似乎不再為 Blazor 投入足夠的資源。近年來，微軟的重心逐漸轉移到人工智慧（AI）領域，對 Blazor 的更新和支援力度明顯下降。這讓 Blazor 的未來充滿了不確定性。
4. 做出抉擇：從 Blazor 回到 Vue
經過一段時間的開發，我們團隊意識到，Blazor 可能並不適合我們未來的產品路線。儘管我們喜歡用 C# 開發，但在 Web 開發領域，其他技術棧在元件豐富性、社群支援和生態系統上顯然更具優勢。
綜合以上因素，我們不得不做出艱難的決定：
- 停止在新產品中使用 Blazor：為了專案的長期發展，我們決定在下一個產品中放棄使用 Blazor。
- 重構現有產品的前端部分：對於已經使用 Blazor 的產品，我們計劃在第二個版本中重構前端，改用更成熟的 Web 技術，如 Vue。
這一決策雖然艱難，但也是我們經過深思熟慮後的選擇。
5. 反思與建議：Blazor 的適用場景
透過這次經歷，我們發現選用 Blazor 可以從以下幾點因素去考量：
- 團隊規模：Blazor 更適合單兵作戰的開發者，或 2 至 4 人的小團隊。這些開發者通常具有較強的 C# 和 .NET 背景，能夠快速上手，學習 Blazor 的負擔相對其他非 .NET 背景的開發者要小很多，可以利用現有的 .NET 技能快速構建和部署小型專案。
- 應用型別：Blazor 非常適合用於構建功能相對簡單的標準管理系統，比如內部管理工具，進行資料錄入、生成報告、利用儀表盤和報表進行資料展示。這些應用通常不需要複雜的前端互動，且需求相對穩定，可以利用 Blazor 的元件化特性快速搭建。
- 產品演化：Blazor 更適合那些在開發初期對功能和使用者介面需求有明確設定的產品。這種情況下，可以在產品釋出後無需過多的擔心產品後期的接手和維護問題。減少產品變更和迭代所帶來的維護成本。
6. 結語
在這個快速發展的技術世界裡，選擇一個合適的開發框架至關重要。Blazor 的理念值得肯定，但在當前階段，可能還不適合用於大型商業專案。我們的經驗教訓也提醒著其他團隊，在技術選擇上要更加謹慎和前瞻。
未來，我們仍會關注 Blazor 的發展，但在那之前，我們將選擇更適合當前需求的技術方案。儘管我們與 Blazor 的旅程暫告一段落，但這段經歷將成為我們繼續探索和學習的寶貴財富。
Disclaimer 宣告：本文由 AI 輔助完成撰寫