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 有什么功能，我百度找一段过来：

1. 嵌入动态文本于 HTML 页面

2. 对浏览器事件做出响应

3. 读写 HTML 元素

4. 在数据被提交到服务器之前验证数据

5. 检测访客的浏览器信息。控制 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/

MASA 技术团队: (鬼谷子)