服务器
你们的关注点怎么都这么奇特？！我唯一感兴趣的领域就在 Blazor 上！过去，Blazor 总是被批评不伦不类：Wasm 包体积庞大、需要下载，而且老浏览器根本不支持。而 Blazor Server 则被指责消耗
服务器资源，渲染速度还慢。那么，
微软在最近几个版本中做了哪些改进？他们一直在优化 SignalR（Blazor Server 依赖它与后端通信），同时对 Wasm 的裁剪和 AOT 编译进行了大量优化。最令人振奋的是，在 .NET 8 中，Wasm 和 Server 融合成了一个整体——最初被称为 Blazor United，但很快
微软又将其改名为单纯的 Blazor（没有 Server 或 Wasm 后缀）。这种融合后的 Blazor 是如何工作的？以下内容并非我的实际操作经验，而是基于观看
微软官方演示总结的：当用户首次访问基于 Blazor 构建的网站时，页面会以 Server 渲染模式启动，确保最快的初始加载速度。与此同时，后台会自动下载 Wasm 包。一旦 Wasm 包下载完成，页面将无缝切换到 Wasm 渲染模式。如果用户的浏览器过于老旧，不支持 Wasm，则会自动回退到纯 Server 渲染模式。对于需要与后端交互的操作（如表单提交），仍然通过 Server 进行通信。如果你担心 Blazor 的自动渲染逻辑可能会失控，也可以明确指定某些页面或组件使用特定的渲染方式，灵活性极高。别忘了，Blazor 还支持调用
JavaScript，实现功能扩展。现在，你完全可以用 C 高效地完成前后端开发工作。如果你好奇有哪些商业项目正在使用 Blazor，可以参考以下链接（此网站并非
微软官方制作，但在
微软的宣传视频中经常出现）。试想一下，虽然 WebAssembly 可能会被多种语言支持，但像 Blazor 这样用单一语言完成前后端开发，并且性能优异的框架，其他语言目前还没有真正能与之匹敌的对手。Blazor Server 深度依赖
微软的 SignalR 库，而 WebSocket 通信的概念似乎并未引起其他语言社区的足够重视。再加上与 EF Core 等强大工具的配合，Blazor 的开发体验简直无与伦比！当然，Blazor 也有不足之处，比如它不支持国内花样繁多的小程序生态，而这恰恰是传统前端开发者的护城河。我计划等到 .NET 8 正式版发布后，用 Blazor 重构我们现有的网站，后续的新项目也将直接采用 Blazor，不再依赖 ASP.NET Core。以后如果听到别人嘲讽 .NET 开发者，我可以这样回应：看看你们这些用 .NET 的人！写跨平台程序全靠 C，数据库操作也用 C，前后端开发还是 C！你们全家一辈子只会用 C 这一门语言！真是垃圾！
