从入门到放弃，我们为何从 Blazor 回到 Vue

在我们团队的开发历程中，C# 和 .NET 框架一直是我们的主力语言，伴随我们走过了无数个项目。当微软推出 Blazor 这一革命性的框架时，我们对其充满了期待。Blazor 以其优良的架构和微软的强大背书，似乎预示着前端开发的新纪元。我们希望借助 Blazor 的优势，快速构建与后台服务配套的前端应用。然而，随着开发的深入，我们发现这条路并不如预期顺利，最终不得不放弃 Blazor，转而使用其他 Web 技术。本文将分享我们的经历，希望能为其他团队提供参考。

1. 初识 Blazor 全栈 UI：满怀期待

Blazor 的出现，让我们看到了使用 C# 进行前端开发的可能性。对于习惯了 .NET 环境的开发者来说，这无疑是个好消息。我们可以在不切换语言的情况下，编写前端代码，提升了开发效率和代码一致性。

Blazor 全栈 UI 的技术架构优势明显：

统一的开发体验：开发者可以使用相同的 C# 代码和 Razor 组件在 Blazor Server 和 Blazor WebAssembly 之间进行无缝切换，简化了多种应用类型的开发流程。
灵活的应用架构：Blazor Web App 可以根据具体需求灵活选择 Blazor Server 或 Blazor WebAssembly。
- Blazor Server 通过 SignalR 技术提供服务端和客户端的实时数据传输，和较快的初始加载时间。
- 而 Blazor WebAssembly 可以在浏览器中高效运行，允许用户离线使用，减少服务器负担，提高用户的交互体验。
- 支持灵活地选择 Server 还是 WASM 进行渲染，可以针对整个应用程序、某个页面或控件设置渲染模式。
- 可以将 Server 搭建为 Backend-for-Frontend，写后台接口访问数据库。WASM 搭建为 Frontend，编写布局和页面。达到前后端分离，前端的页面元素渲染和交互不再依赖后端，只有调用 API 获取数据需要后端。
增强的性能：.NET 8 中的 Blazor 具有更好的性能优化，包括更快的组件渲染和数据传输，提升了用户体验。通过加强导航（Enhanced Navigation）功能，使用户在交互和导航时感觉在浏览 SPA 网站。
利用渲染树构建组件：提供了 ChildContent、ChildFragment 来灵活地自定义控件元素的样式和行为，支持通过模板重写控件内部的元素。
用户身份和权限认证：利用 Identity 无缝便捷地集成用户验证和权限控制，支持对某个页面、控件、Controller，API 设置访问权限。WASM 应用缓存了属于客户端的数据，无需在服务端维护，例如用户身份信息、登录状态等等。
熟悉的开发工具：Visual Studio 和其他 IDE 对 Blazor Web App 的友好支持，提供更好的调试体验和开发效率。

2. 遭遇挑战：理想与现实的差距

然而，理想很丰满，现实却很骨感。在项目推进过程中，我们逐渐感受到 Blazor 的局限性。以下是我们遇到的一些主要问题：

UI 组件库有限：相比于 React、Vue 等成熟框架，虽然 Blazor 社区在不断发展，但现有的 UI 组件库仍然相对较少。并且，面对某些复杂的前端效果，我们发现 Blazor 难以将不同组件库中的组件融合在一起使用，库之间很难做到样式和操作的统一，这严重影响了我们的开发效率。
前端效果难以实现：Blazor 在处理某些前端效果时显得力不从心。由于其运行机制的特殊性，一些在其他框架中轻松实现的动画、交互效果，在 Blazor 中却需要绕过各种限制，利用 JS 互操作来完成。这不仅降低了开发效率，也影响了用户体验。
社区支持不足：一个框架的生态环境对于其发展至关重要。我们发现，当遇到问题时，几乎无法在社区中找到解决方案。一些无法通过官方文档解决的疑问，StackOverflow 或 GitHub 上的相关帖子寥寥无几。这使得我们在排查和解决问题时陷入困境。

3. 展望未来：Blazor 的前景并不明朗

缺乏实际应用案例：尽管 Blazor 在技术上有许多优点并受到微软的支持，但目前为止，使用 Blazor 搭建网站的知名企业、公司或组织仍然相对稀少。这使得潜在用户对其稳定性和长期可维护性产生疑虑。
微软的转向：更让人担忧的是，微软似乎不再为 Blazor 投入足够的资源。近年来，微软的重心逐渐转移到人工智能（AI）领域，对 Blazor 的更新和支持力度明显下降。这让 Blazor 的未来充满了不确定性。

4. 做出抉择：从 Blazor 回到 Vue

经过一段时间的开发，我们团队意识到，Blazor 可能并不适合我们未来的产品路线。尽管我们喜欢用 C# 开发，但在 Web 开发领域，其他技术栈在组件丰富性、社区支持和生态系统上显然更具优势。

综合以上因素，我们不得不做出艰难的决定：

停止在新产品中使用 Blazor：为了项目的长期发展，我们决定在下一个产品中放弃使用 Blazor。
重构现有产品的前端部分：对于已经使用 Blazor 的产品，我们计划在第二个版本中重构前端，改用更成熟的 Web 技术，如 Vue。

这一决策虽然艰难，但也是我们经过深思熟虑后的选择。

5. 反思与建议：Blazor 的适用场景

通过这次经历，我们发现选用 Blazor 可以从以下几点因素去考量：

团队规模：Blazor 更适合单兵作战的开发者，或 2 至 4 人的小团队。这些开发者通常具有较强的 C# 和 .NET 背景，能够快速上手，学习 Blazor 的负担相对其他非 .NET 背景的开发者要小很多，可以利用现有的 .NET 技能快速构建和部署小型项目。
应用类型：Blazor 非常适合用于构建功能相对简单的标准管理系统，比如内部管理工具，进行数据录入、生成报告、利用仪表盘和报表进行数据展示。这些应用通常不需要复杂的前端交互，且需求相对稳定，可以利用 Blazor 的组件化特性快速搭建。
产品演化：Blazor 更适合那些在开发初期对功能和用户界面需求有明确设定的产品。这种情况下，可以在产品发布后无需过多的担心产品后期的接手和维护问题。减少产品变更和迭代所带来的维护成本。

6. 结语

在这个快速发展的技术世界里，选择一个合适的开发框架至关重要。Blazor 的理念值得肯定，但在当前阶段，可能还不适合用于大型商业项目。我们的经验教训也提醒着其他团队，在技术选择上要更加谨慎和前瞻。

未来，我们仍会关注 Blazor 的发展，但在那之前，我们将选择更适合当前需求的技术方案。尽管我们与 Blazor 的旅程暂告一段落，但这段经历将成为我们继续探索和学习的宝贵财富。

Disclaimer 声明：本文由 AI 辅助完成撰写