.NET Blazor 被誉为革命性的框架，它允许 .NET 开发人员使用 C# 而不是 JavaScript 构建交互式 Web 应用程序。它主要针对希望利用 .NET 生态系统以及通过 NuGet 提供的大量现有库和工具来构建类似 SPA 的应用程序的 ASP.NET Core 开发人员。这是微软试图吸引前端开发人员的最新版本。
随着最近发布的 .NET 8，微软宣布对 Blazor 进行更多改进，最引人注目的是引入了一种称为“静态服务器端渲染 (SSR)”的新渲染模式。
文章讨论了 .NET Blazor 的不同渲染模式，包括 Blazor WebAssembly (WASM)、Blazor 服务器、Blazor 静态服务器端渲染 (SSR) 和新的自动模式。
- Blazor WASM 存在初始加载时间和性能问题，但允许丰富的交互性。
- Blazor Server 解决了加载时间问题，但由于其依赖于 SignalR 连接，因此存在延迟和可扩展性问题。
- Blazor 静态 SSR 通过在服务器上预渲染来缩短加载时间，但在没有 WASM 或服务器组件的情况下缺乏交互性。
Blazor WebAssembly
通常缩写为 Blazor WASM，在所有 Blazor 选项中提供最像 SPA 的体验。当用户首次访问 Blazor WASM 应用程序时，浏览器会将 .NET 运行时以及应用程序的程序集（大量 .dll）和任何其他所需内容下载到用户的浏览器上。下载的运行时是基于 WebAssembly 的 .NET 运行时（本质上是 .NET 解释器），它在浏览器的 WebAssembly 引擎内执行。该运行时负责完全在浏览器中执行编译后的 C# 代码。
尽管 Blazor WASM 应用程序主要是用 C# 编写的，但它们仍然可以与 JavaScript 代码进行互操作。这允许使用现有的 JavaScript 库并访问不直接暴露给 WebAssembly 的浏览器 API。
虽然 Blazor WASM 最初获得了大量好评，并且随着时间的推移不断得到改进，但它也遭到了主要批评，这些批评通常围绕以下领域：
- 初始加载时间：首次访问时下载 .NET 运行时和应用程序程序集的要求可能会导致初始加载时间较长。这在具有大量依赖性的复杂应用程序中尤其是在慢速网络上尤其明显。
- 性能：Blazor WASM 在性能方面落后于传统 JavaScript 框架。WebAssembly 运行时通常仍然比计算密集型工作负载的优化 JavaScript 代码慢。
- 兼容性：虽然 WebAssembly 在现代浏览器中得到广泛支持，但旧版浏览器或某些移动设备仍可能存在问题，从而限制 Blazor WASM 应用程序的范围。
- SEO 挑战：除了所有 SPA 框架都会带来的常见 SEO 挑战之外，Blazor WASM 的额外加载时间较长和性能较慢会对 SEO 排名产生负面影响。
- 与 JavaScript 互操作的复杂性：虽然 Blazor WASM 允许 JavaScript 互操作，但与复杂的 JavaScript 库一起使用或当 C# 和 JavaScript 函数之间需要进行广泛的交互时可能会很麻烦。这种复杂性可能会导致额外的开发开销和潜在的性能瓶颈。不幸的是，由于存在一些限制，对 JavaScript 互操作的需求非常普遍，因此从一开始就破坏了使用 Blazor 的整个前提。
Blazor服务器
为了反击其中一些批评，Blazor Server 在 Blazor WebAssembly 一年后推出，使服务器端 C# 代码能够通过SignalR连接处理 UI 更新。与 Blazor WASM 不同，客户端 UI 由 .NET Core 应用程序中的服务器维护。初始请求后，使用 ASP.NET Core 和 SignalR 在客户端和服务器之间建立 WebSocket 连接。
当用户与 UI 交互时，事件将通过 SignalR 连接发送到服务器。服务器处理该事件，并且任何 UI 更新都会在服务器上呈现。然后，服务器计算当前 UI 和新 UI 之间的差异，并通过持久 SignalR 连接将其发送回客户端。此过程使客户端和服务器 UI 保持同步。由于 UI 逻辑在服务器上运行，因此实际的渲染逻辑以及 .NET 运行时不需要下载到客户端，从而导致下载占用空间小得多，直接解决了 Blazor WASM 的主要批评之一。
然而，虽然 Blazor Server 的方法具有创新性，但它也有一些需要考虑的缺点：
- 延迟：由于每个 UI 交互都在服务器上处理，并且需要通过网络进行往返，因此任何延迟都会显着影响 Blazor Server 应用程序的响应能力。对于网络连接较差或距离服务器较远的用户来说，这可能尤其成问题。
- 可扩展性问题：与 Blazor 服务器应用程序的每个客户端连接都维护与服务器的活动 SignalR 连接（主要通过 WebSockets）。这可能会导致可扩展性问题，因为服务器必须同时管理和维护潜在的数千个连接的状态。
- 服务器资源使用情况：Blazor 服务器应用程序的资源密集程度更高，因为服务器维护 UI 的状态。这可能会导致更高的内存和 CPU 使用率，尤其是当连接的客户端数量增加时。
- 对 SignalR 的依赖：Blazor Server 应用程序的整个操作取决于 SignalR 连接的可靠性。如果连接中断，应用程序将无法运行。这种依赖需要强大的基础设施，并可能增加部署的复杂性，特别是在具有严格安全要求的企业环境中，这可能会限制 WebSocket 的使用。
- 没有离线支持：与 Blazor WebAssembly 应用程序不同，Blazor Server 需要与服务器保持持续连接。如果客户端的连接断开，应用程序将停止工作，并且当前状态可能会丢失。这使得 Blazor Server 不适合需要离线功能的环境。
- ASP.NET Core 服务器要求：对 SignalR 的依赖还意味着 Blazor 服务器应用程序无法像其他 JavaScript SPA 框架一样通过内容交付网络 (CDN) 提供服务。无服务器部署是不可能的，Blazor Server 需要部署成熟的 ASP.NET Core 服务器。
Blazor 静态 SSR
WASM 和服务器渲染模式都存在严重缺陷，这使得 Blazor 相对于传统 SPA 框架来说是一个困难的选择，相比之下，传统 SPA 框架不存在 Blazor 的任何问题，而且架构也更简单。
意识到这些挑战，Microsoft 通过推出Blazor Static SSR解决了 Blazor WASM 和服务器的一些主要问题：
Blazor 静态 SSR是第三种渲染选项，其运行完全独立于 WASM 或 SignalR，而是利用开放的 HTTP 连接将 UI 更新流式传输到客户端。这种方法称为静态站点渲染，涉及在服务器端生成网页并将完整组成的 HTML 传输到客户端，然后将其连接回 DOM 以充当动态应用程序。
在初始页面加载期间，Blazor Static SSR 的行为与传统服务器端应用程序类似，将完整的 HTML 页面传递到用户的浏览器。此外，它还获取一个blazor.server.js脚本，该脚本与 ASP.NET Core 服务器建立长期 HTTP 连接。此连接用于将 UI 更新流式传输到客户端。这种架构更加简单，很像经典的服务器渲染网站，但它通过有选择地更新 DOM 的部分来提供动态的、类似 SPA 的体验，从而消除了整个页面重新加载的需要。
相对于 Blazor WASM 和 Blazor Server 的优势有两个：
- 减少加载时间：用户在访问网站时无需下载完整的 .NET 运行时和应用程序文件，并且当他们浏览网站时，可以避免完整的页面重新加载。
- 可扩展性：不需要 SignalR 连接，这大大减少了服务器上的负载并消除了 WebSocket 连接的许多复杂性。
尽管如此，Blazor Static SSR 并不是传统意义上的实际 SPA 框架。除了 Web 表单和简单的导航之外，它不允许提供丰富的交互性。它还不允许实时更新，因为加载初始页面后客户端上没有运行任何代码
为了解决这个问题，Blazor 从 .NET 8 开始支持不同模式的混合，并引入了第四种渲染选项，称为“自动模式”。
为了向 Blazor 静态 SSR 网站添加交互性，必须返回创建 Blazor WASM 或 Blazor Server 组件。自动渲染选项旨在通过在不同时间使用两种渲染模式来解决 Blazor WASM 加载时间慢和 Blazor Server 对 SignalR 连接要求的主要问题.
在自动模式下运行的 Blazor 组件首先建立 SignalR 连接，以实现即时交互并绕过延长的加载时间。同时，它会谨慎地获取 .NET 运行时和所有必要的依赖项，以充当 Blazor WASM 应用程序。对于以后的访问，Blazor 从服务器过渡到 WASM 版本，保持 SPA 响应能力，而无需进一步依赖 SignalR 连接。
这是一种令人着迷的方法，无疑并不缺乏创造力或雄心。即便如此，与交互式组件相结合的 Blazor Static SSR 也带来了一些新旧挑战：
- 没有 WASM 或 SignalR 就没有交互性：Blazor Static SSR 的最大缺点是它仍然依赖 Blazor WASM 或 SignalR 成为交互框架，这意味着它不仅继承了其中一个，而且还继承了在 Auto 中运行时的所有许多未解决的缺点。模式。
- 复杂性增加：结合三种不同的渲染模式会增加服务器的复杂性，并为必须有效理解和管理这些复杂性的开发人员提供陡峭的学习曲线。
- 没有无服务器部署：由于依赖 ASP.NET Core，仍然无法从 CDN 进行部署。
- 没有离线支持：Blazor 静态 SSR 最大限度地减少了整页重新加载，但仍然需要活动连接才能将更新流式传输到 UI。
- 缓存挑战：虽然静态内容很容易缓存，但频繁更改的动态内容可能难以有效缓存，可能会错过宝贵的性能优化。
话虽如此，当 Blazor 静态 SSR 不与 WASM 或服务器混合在一起时，它还具有一些好处：
- SEO 友好性：由于 SSR 应用程序预先加载服务器上的所有内容并将其作为 HTML 发送到客户端，因此它们本质上是 SEO 友好的。这使得搜索引擎能够更有效地对内容进行爬网和索引。
- 快速初始加载：与 SPA 相比，Blazor 静态 SSR 可以提供更快的初始页面加载。这是因为浏览器一收到 HTML 就准备好呈现它，而无需等待客户端 JavaScript 呈现内容。
- 跨浏览器的稳定性：SSR 应用程序通常在不同浏览器之间具有更一致的行为，因为它们不依赖于客户端渲染，而客户端渲染有时由于特定于浏览器的 JavaScript 怪癖而无法预测。
Blazor 与传统 JavaScript SPA
Blazor Server 或 Blazor Static SSR 都不会预先加载所有必要的 HTML、JavaScript 和 CSS。它们对 ASP.NET Core 后端有严格的依赖性，无法进行无服务器托管，并且需要与服务器保持持续连接。前端与后端没有分离，也没有使用 API 获取数据。
典型的 SPA 在客户端维护状态。用户与应用程序的交互可以更改状态，并且 UI 会相应更新，而无需服务器往返。
由于 SPA 不需要重新加载页面来更新内容，因此它们可以提供与桌面应用程序类似的更流畅、更快的用户体验。使用传统 SPA，通常可以在 Web 和移动应用程序之间共享相同的代码，这是相对 Blazor Server 或静态 SSR 的另一个优势。前端和后端之间的清晰分离使整体思维模型更简单，并允许在不同团队之间有效地划分学科。
网友观点：
- 在 Blazor 中构建交互式应用程序的开发人员体验非常好。一位用户表示“在理想的世界中，Blazor 感觉就像 Web 开发应该是什么样子。如果您从未使用过它，那么您将不明白我的意思。”
- 对 Blazor WebAssembly 应用程序在计算密集型工作负载上的性能表示担忧。计算密集型工作负载（通常/理论上）在 wasm 中更快，但仍然需要可怕的 js 编组，这会扼杀大部分/所有好处。