在我们团队的开辟历程中，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 辅助完成撰写
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
