自研开源 Blazor 组件库路上，我们解决了这些重要挑战

采访嘉宾 | 谷首道、曹尤先

编辑 | 闫园园

随着 Web 开发的日趋复杂，框架和组件库的应用可谓是越来越多。然而，当开发者打开搜索引擎搜索相关概念时，会发现如今的框架和组件库已是“满天飞”，它们各有优势，但也各有不足。因此，到底应该再造轮子还是选择已有工具，选择已有工具时又该如何根据自己的项目需求进行抉择，这其中种种问题对很多团队来说渐渐成为主要挑战。

MASA 技术团队，成立于 2021 年，其自主研发的 MASA Blazor 是一个基于 Blazor Component 和 Material Design 的 UI 组件库，目前已经打标发版 0.4.0。对于 MASA 技术团队来说，为什么会选择自己研发 UI 组件库，其中趟过了什么坑，获得了怎样的经验？MASA Blazor 又适用于怎样的项目或者场景下？带着这些问题，InfoQ 特别采访了温州数闪科技 CTO、微软 MVP 谷首道以及温州数闪科技后端开发、MASA Blazor 核心开发者曹尤先。

如何选择 Web UI 框架？

InfoQ：首先，请您聊聊对于团队来说如何决定是选择适合自己的 Web UI 框架还是选择造轮子呢？

MASA 技术团队：我觉得这个问题，团队或者公司需要反问自己项目对于 UI 的要求是否很高。如果现有的一些设计语言可以满足需求，从中选择一个适合项目属性的就可以了。

就我们自己的实际情况来说，因为我们在做的 MASA Stack 本身存在许多复杂的用户交互体验，而且采用了一个比较新的技术栈，在这个技术栈下并没有符合我们自身要求的一个组件库，在这种情况下，为了更好地把控前端的能力和保证 UI 设计的统一性，我们最终选择了造轮子。当然，造轮子本身不是盲目的，它满足了我们对于技术和审美的双重要求。 

InfoQ：目前 Web UI 框架众多，您认为对于开发者来说，做框架选型时应该遵循哪些原则或者需要考虑哪些方面呢？

MASA 技术团队：我认为团队做框架选型需要考虑三个方面：

首先，要看这个框架本身是否与时俱进。毕竟，一个好的框架不仅自己可以做的很好，还可以潜移默化地引导开发者向更好的方向前进。当然，这也将是我们团队努力的目标；

其次，观察各个组件的成熟度。不得不说，目前有的框架只是完成了最基础的功能，但面对相对复杂的业务场景时，既没有良好的扩展性，又需要很多额外的劳动；

最后，要看服务响应时效。这主要需要考虑，当你发现问题时，官方是否能积极、快速、正面的响应你的问题。

认识 Blazor

InfoQ：Blazor 与我们熟知的三大框架以及组件库比如 Bootstrap 等有何联系又有何区别？

MASA 技术团队：Blazor 与三大框架一样都是基于现有的 Web 技术之上的一种构建用户界面的技术，只不过 Blazor 使用 Razor 和 C# 代替了 HTML 和 JavaScript，而且用户仍然可以使用自定义 JavaScript 模块和第三方 JavaScript 库。

MASA Blazor 基于 Material Design 有着严格的设计规范。Bootstrap 是 UI 框架，但相对来说 Material Design 对设计更友好，Bootstrap 对技术友好。而我们的样式表是从 Vuetify 移植过来的，它解决了很多从设计到实现的细节，让我们可以更轻松的完成 Material Deisgn 迁移到 Blazor 的工作。

InfoQ：Blazor 给了 .Neter 完全以 C# 作为主要语言实现全栈开发的机会，但也有开发者认为这与前后端分离相矛盾，对此您怎么看？

MASA 技术团队：首先我们需要意识到前后端分离并不是 Web 应用开发的“银弹”。 自从前后分离的开发模式推出以来，关于是否要前后端分离的争论就没有停止过，但在我看来其实也各有优势。

我们看到 Blazor 有 Server 和 Wasm 两种托管模型。其中 Wasm 是纯前后分离的，虽然技术栈依然是 .Net，但 Server 可以选择是前后分离或不分离。用户可以直接将 BFF 放在 Server 上，或者可以独立出来，这个根据项目特性自行选择即可。

除此之外 Blazor 还提供了 BlazorWebView 以运行在 MAUI 等项目中，它提供了更多的想象而不是让大家从中选一。

InfoQ：您认为目前在实践中应用 Blazor 对比其他技术栈有哪些问题或者局限性？

MASA 技术团队：目前来说 Blazor 还是一个比较新的技术，它可以使用 .Net 绝大多数功能，但最终还是要和浏览器交互，相比 Javascript，Blazor 的生态圈还有很长的路要走。因此，对于现阶段的我们来说，也是通过移植一些 Javascript 的成熟类库或转译为 .Net 后集成到 MASA Blazor 中。

另外在 Server 模式下，每个有状态的操作都需要通知到服务器，操作的响应会因为网络延迟而延迟，所以我们需要额外注意如何合并多次请求降低网络延迟带来的性能影响。在 Client（WebAssembly）模式下，应用打包的体积非常大，会导致首次加载的耗时很长，也需要通过 PWA 和其他手段去优化这个过程。

InfoQ：目前看来，您认为 Blazor 的前景如何？

MASA 技术团队：在我看来，Blazor 提供了让 .NET 团队在使用一个技术栈的情况下构建前端和后端的能力，提高了团队的研发效率和资源利用率。

Blazor 的推出让 C# 和 .Net 技术栈焕发新的生机，通过 Wasm 可以让 .Net 应用运行在任何浏览器上，并且通过 .NET MAUI Blazor 可以开发共享代码，在 Android、iOS、macOS 和 Windows 上运行的应用，由此我们也相信 Blazor 的应用场景将越来越多。

MASA Blazor 实践之路

InfoQ：能否跟大家介绍一下 MASA Blazor 诞生的原因、发展过程以及现状。

MASA 技术团队：2021 年初我们做 MASA Stack 的预研阶段找了一些当时全球范围比较流行的后台管理端主题，内部投票后大家都倾向于 Material Design，于是很快就锁定了 Vuetify。但当时没有一个很好的 Blazor 组件库可以达到我们的要求，并且团队对于 Blazor 的熟悉程度也不是很高，所以我们做了个大胆的决定，自己开发组件库。

经过一年多的全职开发，我们对 Vuetify 的绝大多数组件进行了 1：1 还原，但由于我们 1.0 定的标准比较高，所以目前为止也还是保守的发版了 0.4，预计年底可以发布 1.0。未来我们会尽量保证按月发版，Hotfix 快速响应，社区支持也尽量在一个工作日内有响应。

从 0.3 发版到现在，我们一直积极响应社区反馈，也根据大家的建议在 B 站上传了 MASA Blazor 学习手册的系列视频。在大家一起的共同努力下，MASA Blazor 会稳扎稳打的走好未来的每一步。

InfoQ：团队在 MASA Blazor 发展过程中有没有遇见技术难题，是怎样解决的？

MASA 技术团队：主要有两个方面：

第一，性能问题。早期团队为了追求极致的还原 Vuetify 相关功能，无论是 Server 或 Wasm，都忽略了 Blazor 在频繁交互上的性能问题，导致动效还原上出现了很大的性能问题，这也是 0.4 版本的重大改进，我们推翻了之前动效部分的代码，通过合并 API 和转移部分动效逻辑到 Javascript 等方式将性能问题抹平，不得不说，这个改造的代价是巨大的。

第二，延迟带来的蝴蝶效应。在 Server 下，其实我们开启了 CDN 后延迟只有不到 16ms，这是肉眼几乎感知不到的。但对于某些特定的快速操作场景会导致前端事件不保序，我们通过把一些传统写法转化为现代的 Web API 和引入状态机等方式重构了容易引发事件乱序的地方，这也是 0.4 版本里重点解决的部分。

InfoQ：请您聊聊 MASA Blazor 适用于怎样的项目或者场景下？

MASA 技术团队：目前来看，MASA Blazor 可以用于以下场景：

第一，后台管理项目。我们提供了 MASA Blazor Pro 项目模板，可以快速的搭建纯前端的后台管理项目。

第二，移动端。除了 MASA Blazor 文档站点适配了移动端外，我们还对 MAUI Blazor 进行了测试并在 MASA Blazor 学习手册系列视频中进行了简单的使用教学。

第三，门户网站。目前 MASA Template 提供了文档站点的模板，未来我们的官网也将使用 MASA Blazor，届时也会提供门户网站的模板。

InfoQ：MASA Blazor 为什么选择开源？目前开源社区是怎样治理的？

MASA 技术团队：首先，我们认为在开源社区下可以获得更多的反馈，并且赠人玫瑰手留余香的事情我们也是不吝啬去做的。

其次，对于开源社区的治理我们也处在学习阶段，而且目前主要由团队带动，虽然社区例会已经启动，但后续仍然有很多方面需要继续完善。我们希望可以纯粹的做好开源这件事，也欢迎感兴趣的小伙伴可以参与进来，慢慢的从团队主导转变为社区驱动。

InfoQ：据了解，MASA Blazor 是 MASA Framework 中的常用工具，能否跟大家介绍下 MASA Framework 的概念。其中，MASA Blazor 扮演了怎样的角色？

MASA 技术团队：MASA Framework 致力于给 .Net 全栈在企业级云原生项目提供基础的技术支撑。它分为四个部分：

第一，Building Blocks：提供接口标准，并为了达到某个基础能力的串接不同组件（也通过接口），松耦合但不脱钩。

第二，Contrib（组件）：基于接口标准的实现，比如服务间通讯提供 HttpClient 和 Dapr Service Invocation 等不同组件的实现。

第三，Utils：提供更抽象的底层能力，供业务和组件完成自身功能，如缓存/配置/数据操作/安全等。

第四，组件库（MASA Blazor）：Blazor 组件库，让 .Net 开发者在熟悉的 .Net 环境下进行交互式 Web 开发。

InfoQ：从近期或者长期来看，团队有何规划？

MASA 技术团队：未来 MASA Blazor 1.0 会着重于稳定性和组件基础能力覆盖率，根据 MASA Stack 的发展补充更多实用的组件，如果精力允许的话我们会尝试为 MASA Blazor 提供现代前端框架的一些中大型解决方案。

同时 MASA Framework 将会持续补充云原生相关领域的能力，并且会提供与 MASA Stack 深度集成的基于约定优于配置的最佳实践，它将不仅局限于只是一个简单的类库集合。

而 MASA Stack，旨在提供开源的 .Net 全栈企业级云原生数字中台，未来也将是我们的主战场，MASA Blazor 是为了完成 .Net 全栈的第一步。MASA Stack 包含开发框架（MASA Framework），IT 和微服务基础能力，运维能力和数据工厂。整合技术中台和数据中台，未来与 MASA Cloud 的业务中台一起形成新的版图。最终这一切都会回归到我们公司的口号：让变化更简单。

嘉宾介绍：

谷首道

温州数闪科技 CTO。

微软 MVP，参与并主导了 MASA Stack 项目。

曹尤先

温州数闪科技后端开发。

MASA Blazor 核心开发者之一。