Blazor是春天還是寒風里的掙扎

本文轉載自查看原文 2021-12-16 08:45 7621 MASA Blazor/ 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生態共建出自己小小的一份力呢？

開源的組件庫

再回到組件庫上，目前市面上的組件庫其實不少了，何必要繼續在這個泥潭里插一腳呢？

開發過組件庫的同學，或者貢獻過源碼的同學應該都體會到了，寫一個組件是多么的復雜。而大家對於一個設計的審美角度也是不同的。當你喜歡的設計沒有提供實現怎么辦？從頭寫嗎，那太累了，所以我們嘗試了一件事情。

先看一下大概思路：

架構圖.jpg

簡單的剖析一下：

在Blazor的基礎上，構建一個新的組件庫叫 Blazor Component

那他有哪些特性呢？
- 只提供交互，不提供樣式
- 標准化Dom結構
- 開放幾乎所有可以自定義的Slots（插槽，概念引自Vue），允許你替換Slots的Dom
插槽與交互的統一單元測試（目前正在38%，短期目標是80%，長期目標是90%+）
基於Material Design（樣式引自Vuetify）的示例項目，可以達到生產可用（我們自己的公司在用，也是世界五百強企業在用）
快速實現新的組件庫，只需要基於某個Design + 樣式控制屬性 + 特殊交互即可