Blazor 是春天還是寒風裏的掙扎
官方解釋 Blazor
-
使用 C# 代替 JavaScript 來創建信息豐富的交互式 UI。
-
共享使用 .NET 編寫的服務器端和客戶端應用邏輯。
-
將 UI 呈現爲 HTML 和 CSS,以支持衆多瀏覽器,其中包括移動瀏覽器。
-
與新式託管平臺(如 Docker)集成。
-
使用 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/
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/dmsesJiqJLuhH6qfn1ivXQ