乐趣区

关于c#:Blazor是春天还是寒风里的挣扎

jiezi

官网解释 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/4…

那 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/M…

总结

说到底没有完满的技术，在你权衡利弊之后在正确的场景应用它就是最合适的。

是春天还是寒冬也不重要，重要的是当下这一刻，它是否解决了你的痛点。

最初，一个小小的广告

MASA Blazor 行将公布，敬请期待，如果你对咱们的组件库感兴趣，无论是代码奉献、应用、提 Issue，欢送分割咱们

参考

  • https://dotnet.microsoft.com/…
  • https://docs.microsoft.com/zh…
  • https://sec.ch9.ms/ch9/daba/4…
  • https://developer.mozilla.org…
  • https://ssr.vuejs.org/zh/
退出移动版