title: Blazor是春天還是寒風里的掙扎
date: '2021-10-25 14:00:00'
toc: true
categories:
- Blazor
tags: - Blazor
- MASA Blazor#
官方解釋Blazor
Blazor允許您使用c#而不是JavaScript構建互動式web UI， Blazor應用由可重用的web UI組件組成，這些組件使用c#、HTML和CSS實作，客戶端和服務器代碼都是用c#撰寫的，允許您共享代碼和庫，
Blazor 是一個使用 .NET 生成互動式客戶端 Web UI 的框架：
- 使用 C# 代替 JavaScript 來創建資訊豐富的互動式 UI，
- 共享使用 .NET 撰寫的服務器端和客戶端應用邏輯，
- 將 UI 呈現為 HTML 和 CSS，以支持眾多瀏覽器，其中包括移動瀏覽器，
- 與新式托管平臺（如 Docker）集成，
使用 .NET 進行客戶端 Web 開發可提供以下優勢：
- 使用 C# 代替 JavaScript 來撰寫代碼，
- 利用現有的 .NET 庫生態系統，
- 在服務器和客戶端之間共享應用邏輯，
- 受益于 .NET 的性能、可靠性和安全性，
- 在 Windows、Linux 和 macOS 上使用 Visual Studio 保持高效作業，
- 以一組穩定、功能豐富且易用的通用語言、框架和工具為基礎來進行生成，
看到這里有些小伙伴手中的瓜已經要丟出來了，的確有部分是夸大了的，起碼VS在三個平臺高效作業這事兒，嗯，，，其他的繼續吃瓜吧
Blazor Vs MVC
什么是MVC
官方解釋：ASP.NET Core MVC 是使用“模型-視圖-控制器”設計模式構建 Web 應用和 API 的豐富框架，
圈重點，Blazor是互動式Web UI，而MVC是Web應用和API
什么是互動式Web UI
谷歌、百度轉了一圈，沒有這個解釋，連Wiki也是一臉懵逼，
嘗試理解一下吧，互動式Web UI重點在于互動，而Blazor的官方解釋是用C#代替JavaScript，那我們看看JavaScript有什么功能，我百度找一段過來：
-
嵌入動態文本于HTML頁面
-
對瀏覽器事件做出回應
-
讀寫HTML元素
-
在資料被提交到服務器之前驗證資料
-
檢測訪客的瀏覽器資訊，控制cookies，包括創建和修改等
有這些基礎功能，用戶不需要在靜態頁面里跳來跳去了，的確體驗會好很多
Blazor有什么優勢
提供了一些互動能力，不再是純粹的靜態頁，雖然mvc可以使用JavaScript達到同樣的效果，但你需要掌握JavaScript，甚至還要再學習jQuery、Angular、Vue等，而Blazor提供的互動能力則是使用C#，
吹是吹完了，但你真的可以100% C#嗎？這很難，你會遇到各種問題，比如兼容性、性能等，好了，那我可以不用了嗎？等等，下面還有瓜
Blazor Vs 現代前端(Angular、Vue等)
我們從幾個方面來對比一下吧
除錯
-
Blazor：Vistual Stuidio + F5，VS Code/命令列工具 +
dotnet watch比WebPack要快很多，跟Vite差不多
在非復雜場景下Hot Reload是可以的，但奇奇怪怪的問題太多了，前景很好，目前來看還是用Ctrl + F5啟動或者用命令列吧
VS 2022的Ctrl + F5已經支持Hot Reload了
-
現代前端：Webpack/Vite
全家桶
以Vue為例，Vue全家桶包括Vue Cli、Vue Router、Vuex
Blazor：
- Cli：dotnet cli
- Router：Microsoft.AspNetCore.Components.Routing.Router
- Vuex：Blazor狀態管理，區別在于WASM狀態保存在瀏覽器記憶體中，而Server保存在服務器記憶體中，而且Blazor狀態管理更強大的是借助.Net的能力，原生支持持久化存盤、跨線路保存（Server下共享服務器記憶體）、ASP.NET Core 受保護的瀏覽器存盤（Server獨享功能）
組件庫
主流的Bootstrap, Ant Design, Material Design等雙方都有，但由于現代前端多年的積累，質量上的確有一定差距，
除了豐富程度上，Blazor允許被JavaScript呼叫加載，并生成Angualr、React等組件，
雖然這看起來跟用C#解決代替JavaScript有點沖突，但融入大環境也是不錯的
下圖演示的是Blazor提供的inventory-grid Component被React參考的例子(當然也可以給Angular)：
更神奇的是，在React復用的Blazor Component居然也支持Hot Reload，先不說Hot Reload到底如何，單是這個方向其實還是值得期待一下Hot Reload的未來吧，
不止可以給React提供復用的組件，還可以給WPF
第三方庫
舉幾個前端常用庫來比較，
網路：現代前端有axios，Blazor有HttpClient
資料操作：現代前端有Lodash，Blazor有Linq
時間：現代前端有moment.js、Day.js，Blazor有DateTime全家桶
回應式編程：現代前端有rx.js，Blazor有Rx.Net（沒有用過，理論上.Net基本都能用，歡迎糾錯）
Mock：現代前端有Mock.Js，Blazor有Moq，當然除了mock以外還有端到端的，雙方也都有，
對比下來其實.Net反而還有點優勢，那就完美嗎？當然不是，再說點劣勢的部分吧，
Charts：現代前端有ECharts等，Blazor不想說話
雖然目前Blazor的確沒有成熟、免費的Charts組件庫，但因為Blazor可以與JS互動的能力，呼叫ECharts也很簡單，稍微考驗一點點小伙伴的動手能力
富文本編輯器、拖拽，，，
Blazor罵罵咧咧的退出了群聊，，，
包管理
Blazor：NuGet
現代前端：NPM、Yarn
性能
資料不直觀，先從.Net Conf 2021上的演示截圖看一下：
有量化資料嗎？有：
視頻地址：https://sec.ch9.ms/ch9/daba/468d5211-982b-4c86-8b51-e1c8824edaba/dotNETConfNewBlazorWebAssembly_high.mp4
那AOT可以解千愁嗎？也不是，起碼應用大小上來說的確也大了不少，但這并不妨礙AOT可以解決特定場景的問題，技術總要選擇在適合的場景使用它，而不是盲目的，
完了嗎
當然沒有，其實這樣比較對于Blazor是不公平的，因為Blazor站在.Net的肩膀上有更多的亮點，比如原生支持的泛型、DI、面向物件設計（雖然TS也是）、數不過來的.Net類別庫、跨平臺應用（MAUI）等，
其實沒有必要只看到Blazor的劣勢，也可以看看站在.Net上的前端能走多遠，這不也是我們期待的嗎？
看到這里，有些.Net古董級大佬要出來發話了，Silverlight！是的，但這次WASM沒有再要求下載插件了，
Web Assembly Vs Server（服務器端渲染）
Web Assembly：WebAssembly是一種新的編碼方式，可以在現代的網路瀏覽器中運行 － 它是一種低級的類匯編語言，具有緊湊的二進制格式，可以接近原生的性能運行，并為諸如C / C ++等語言提供一個編譯目標，以便它們可以在Web上運行，它也被設計為可以與JavaScript共存，允許兩者一起作業，
Server（Server Side Render - SSR）：將組件渲染為服務器端的 HTML 字串，將它們直接發送到瀏覽器，最后將這些靜態標記"激活"為客戶端上完全可互動的應用程式，
為什么用SSR
服務器端渲染 (SSR) 的優勢主要在于：
- 更好的 SEO，由于搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面，
- 更快的內容到達時間 (time-to-content)
什么時候用SSR
使用服務器端渲染 (SSR) 時還需要有一些權衡之處：
- 開發條件所限，瀏覽器特定的代碼，只能在某些生命周期鉤子函式 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在服務器渲染應用程式中運行，
- 涉及構建設定和部署的更多要求，與可以部署在任何靜態檔案服務器上的完全靜態單頁面應用程式 (SPA) 不同，服務器渲染應用程式，需要處于服務端運行環境，
- 更多的服務器端負載，
服務器端渲染 vs 預渲染 (SSR vs Prerendering)
如果你調研服務器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那么你可能需要預渲染，無需使用 web 服務器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 檔案，優點是設定預渲染更簡單，并可以將你的前端作為一個完全靜態的站點，
Blazor Server支持Prerendering
Blazor該選Web Assembly還是Server
看一下.Net Conf 2021大會上的一張圖：
總結一下：
- Server要持久化長連接，有更高的UI延遲
- Web Assembly則是更大的下載大小，和更慢的運行時性能
我們在做什么
又是一個老生常談的問題，.Net的覆寫面太廣了也導致很難解決所有問題，我們在權衡利弊之后是不是可以為.Net生態共建出自己小小的一份力呢？
開源的組件庫
再回到組件庫上，目前市面上的組件庫其實不少了，何必要繼續在這個泥潭里插一腳呢？
開發過組件庫的同學，或者貢獻過原始碼的同學應該都體會到了，寫一個組件是多么的復雜，而大家對于一個設計的審美角度也是不同的，當你喜歡的設計沒有提供實作怎么辦？從頭寫嗎，那太累了，所以我們嘗試了一件事情，
先看一下大概思路：
簡單的剖析一下：
-
在Blazor的基礎上，構建一個新的組件庫叫 Blazor Component
那他有哪些特性呢？
- 只提供互動，不提供樣式
- 標準化Dom結構
- 開放幾乎所有可以自定義的Slots（插槽，概念引自Vue），允許你替換Slots的Dom
-
插槽與互動的統一單元測驗（目前正在38%，短期目標是80%，長期目標是90%+）
-
基于Material Design（樣式引自Vuetify）的示例專案，可以達到生產可用（我們自己的公司在用，也是世界五百強企業在用）
-
快速實作新的組件庫，只需要基于某個Design + 樣式控制屬性 + 特殊互動即可
未來是值得憧憬的，我們希望未來是這樣的：
慚愧，蹭了一波位元組的熱度
MASA Blazor
基于Blazor Component和Material Design的Blazor組件庫
- 截止目前共68個基礎組件，后續會繼續增加
- 預置組件，提供與.Net功能深度集成且常用組合類組件，如Url、面包屑、選單三聯動，高級搜索，i18n等
- MASA Blazor Pro提供多種常見場景的預設布局
- 全職團隊維護，Issue快速回應
- 知名企業在用，未來MASA Stack產品線也將一直使用，持續增加新功能
- 免費、開源
我們還計劃未來支持一鍵切換主題（代碼切換已經提供）、預置布局、資料展示類組件、WorkFlow類組件等，
MASA Blazor Pro
基于MASA Blazor提供的Admin模板，先放幾張設計稿吧，原始碼會跟MASA Blazor一起放出，
MASA EShop
基于MASA Framework搭建的 EShopOnDapr，將會使用MASA Blazor Pro提供完整的前后端示例
開源地址：https://github.com/masalabs/MASA.EShop
總結
說到底沒有完美的技術，在你權衡利弊之后在正確的場景使用它就是最合適的，
是春天還是寒冬也不重要，重要的是當下這一刻，它是否解決了你的痛點，
最后，一個小小的廣告
MASA Blazor 即將發布，敬請期待，如果你對我們的組件庫感興趣，無論是代碼貢獻、使用、提Issue，歡迎聯系我們
參考
- https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
- https://docs.microsoft.com/zh-cn/aspnet/core/blazor/state-management?view=aspnetcore-6.0&pivots=server#persist-state-across-circuits
- https://sec.ch9.ms/ch9/daba/468d5211-982b-4c86-8b51-e1c8824edaba/dotNETConfNewBlazorWebAssembly_high.mp4
- https://developer.mozilla.org/zh-CN/docs/WebAssembly
- https://ssr.vuejs.org/zh/
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/418023.html
標籤：C#
上一篇：話說C#程式員人手一個ORM