.NET Blazor

原文 ↗ Hacker News 讨论 ↗

Blazor 是 Microsoft 基于 .NET 的 Web UI 框架，可在浏览器中或服务器端运行 C#；它在开发者群体中既有热情支持，也有明显怀疑。支持者称赞其出色的开发体验、与现有 .NET 后端的代码复用，以及 .NET 8 的静态渲染和“auto”模式等新特性，这些特性将服务器端与 WebAssembly 结合得更好，尤其适合内部业务应用。批评者则指出 WASM 载荷大、依赖持续的服务器状态、与更广泛的 JavaScript 生态整合较弱，以及 Microsoft 过去曾放弃多种 UI 框架的历史，认为更传统的 JS/TS 前端配合解耦 API 才是更安全的长期选择。

全栈 vs 专精

  • 争论焦点在于后端和前端开发者是否应当趋同为“全栈”角色。
  • 一些人认为，出于风险管理、可靠性和 UX 的考虑，专精是必要的；另一些人则指出，小团队和独立创始人经常需要同时覆盖后端、前端、运维等多个领域。
  • 一个反复出现的主题是：即使人们可以做完所有事情，更大的组织通常仍然更偏好清晰的职责归属和领域专家。

Blazor 被认为的最佳落点

  • 许多人认为 Blazor（尤其是 Server）非常适合内部业务系统、管理后台和内网应用，因为这些场景对 UX 打磨、SEO 和超小体积 bundle 的要求没那么高。
  • 对 .NET 团队和偏后端的开发者尤其有吸引力：可以复用 C# 技能，与后端共享模型/校验逻辑，并避免单独维护前端技术栈。
  • 有些人表示已成功将 Blazor 应用投入生产环境（通常是小到中等规模），并称赞其开发效率。

性能、架构与渲染模式

  • 关于 Blazor WASM 的担忧包括：初始下载体积达到数 MB、CPU 占用以及 JS interop 开销；也有人指出许多网站体积更大，而且在企业桌面环境中缓存可以缓解这一问题。
  • Blazor Server 则因每个客户端都需要服务器端状态、WebSocket 易脆弱、重连问题以及扩展性而受到批评；支持者认为它在典型内网使用场景下表现良好。
  • .NET 8 的“static/SSR + enhanced navigation + auto mode”被描述为一次重大改进，将服务器渲染与可选 WASM 结合起来，并减少了早期的 UX 取舍。
  • 仍有人认为，与无状态 HTTP 相比，任何持久化服务器状态本身都是架构上的“定时炸弹”。

开发体验 vs JS 生态

  • 多位评论者认为，Blazor 比现代 JS/TS SPA 技术栈简单得多：依赖更少、构建工具更少、IDE 更好用，并且与企业代理/杀毒软件的交互更顺畅。
  • 也有人强烈偏好 TypeScript + 传统 SPA，认为在良好治理下，JS 工具链是可管理的，而且在不同后端之间更具可移植性。
  • 对 JS 生态频繁变化和脆弱工具链的抱怨，与对 .NET 自身“开箱即用”能力往往只是 50–90% 完成、之后又被新方案取代的抱怨形成了对照。

信任与长期存续

  • 许多人的深度怀疑源于过去 Microsoft 的 UI/RIA 技术：Silverlight、WebForms、UWP、Xamarin 等。很多人担心又会迎来一次弃用潮和艰难迁移。
  • 反方观点是：Blazor 是开源的，建立在 WebAssembly 和标准之上，而且 .NET/WinForms 说明 Microsoft 往往会支持平台很多年。
  • 也有人建议无论如何都应通过 API 将前后端解耦，这样不管 Blazor（或 React、Vue 等）是否失宠，任一侧都可以替换。

更广泛的 Web 技术栈反思

  • 有几位指出所有生态都会不断更迭：JS 框架、Java EE 技术栈、桌面 GUI 工具包都一样。没有任何选择能保证长期稳定。
  • 提到的替代方案包括：带有 OpenAPI 生成 TS 类型的 Vue/React SPA、类似 Hotwire/LiveView 的 SSR + 零散增强交互、htmx，以及 Java 世界中的 GWT 或 Vaadin。