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

官方解釋 Blazor

看到這裏有些小夥伴手中的瓜已經要丟出來了，的確有部分是誇大了的，起碼 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 有什麼功能，我百度找一段過來：

  1. 嵌入動態文本於 HTML 頁面

  2. 對瀏覽器事件做出響應

  3. 讀寫 HTML 元素

  4. 在數據被提交到服務器之前驗證數據

  5. 檢測訪客的瀏覽器信息。控制 cookies，包括創建和修改等

有這些基礎功能，用戶不需要在靜態頁面裏跳來跳去了，的確體驗會好很多

Blazor 有什麼優勢

提供了一些交互能力，不再是純粹的靜態頁，雖然 mvc 可以使用 JavaScript 達到同樣的效果，但你需要掌握 JavaScript，甚至還要再學習 jQuery、Angular、Vue 等。而 Blazor 提供的交互能力則是使用 C#。

吹是吹完了，但你真的可以 100% C# 嗎？這很難，你會遇到各種問題，比如兼容性、性能等。好了，那我可以不用了嗎？等等，下面還有瓜

Blazor Vs 現代前端 (Angular、Vue 等)

我們從幾個方面來對比一下吧

調試

全家桶

以 Vue 爲例，Vue 全家桶包括 Vue Cli、Vue Router、Vuex

Blazor：

組件庫

主流的 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) 的優勢主要在於：

什麼時候用 SSR

使用服務器端渲染 (SSR) 時還需要有一些權衡之處：

服務器端渲染 vs 預渲染 (SSR vs Prerendering)

如果你調研服務器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 服務器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作爲一個完全靜態的站點。

Blazor Server 支持 Prerendering

Blazor 該選 Web Assembly 還是 Server

看一下. Net Conf 2021 大會上的一張圖：

總結一下：

我們在做什麼

又是一個老生常談的問題，.Net 的覆蓋面太廣了也導致很難解決所有問題。我們在權衡利弊之後是不是可以爲. Net 生態共建出自己小小的一份力呢？

開源的組件庫

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

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

先看一下大概思路：

簡單的剖析一下：

未來是值得憧憬的，我們希望未來是這樣的：

慚愧，蹭了一波字節的熱度

MASA Blazor

基於 Blazor Component 和 Material Design 的 Blazor 組件庫

我們還計劃未來支持一鍵切換主題（代碼切換已經提供）、預置佈局、數據展示類組件、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，歡迎聯繫我們

參考

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/dmsesJiqJLuhH6qfn1ivXQ

猜你喜歡