“Atwood 的法律：任何可以用 JavaScript 编写的应用程序最终都将用 JavaScript 编写。
- 杰夫·阿特伍德
目前有两种常规方法来生成 Web 应用程序：传统的 Web 应用程序在服务器上执行大部分应用程序逻辑，以及单页应用程序（SPA），这些应用程序在 Web 浏览器中执行大多数用户界面逻辑，主要使用 Web API 与 Web 服务器通信。 还可以使用混合方法，其中最简单的方法是在一个较大的传统 Web 应用程序中托管一个或多个类似 SPA 的丰富子应用。
在以下情况下使用传统 Web 应用程序：
应用程序的客户端要求简单，甚至要求只读。
应用程序需要在没有 JavaScript 支持的浏览器中运行。
应用程序面向公众，并且受益于搜索引擎发现和引荐。
在以下情况下使用 SPA：
应用程序必须公开具有许多功能的丰富用户界面。
你的团队熟悉 JavaScript、TypeScript 或 BlazorWebAssembly 开发。
应用程序必须已公开其他（内部或公共）客户端的 API。
此外，SPA 框架需要更高的体系结构和安全专业知识。 相较于传统 Web 应用程序，SPA 框架需要进行频繁的更新和使用新的客户端框架，因此改动更大。 配置自动化生成和部署过程以及使用容器等部署选项可能比传统 Web 应用更难使用 SPA 应用程序。
SPA 方法带来的用户体验改进必须权衡与这些因素之间的关系。
Blazor
ASP.NET Core 包含一个模型，用于生成称为 Blazor丰富、交互式和可组合的用户界面。 Blazor 服务器端允许开发人员使用 C# 和 Razor 在服务器上生成 UI，并使用持久 SignalR 连接以交互方式连接到浏览器。 Blazor WebAssembly 为 Blazor 应用引入了另一种方案，允许它们使用 WebAssembly 在浏览器中运行。 由于它是运行 WebAssembly的实际 .NET 代码，因此可以从应用程序的服务器端部分重复使用代码和库。
Blazor 提供了一个全新的第三个选项，可用于评估是生成纯服务器呈现的 Web 应用程序还是 SPA。 可以使用Blazor实现丰富的类似于SPA的客户端行为，而无需进行大量的JavaScript开发。 Blazor 应用程序可以调用 API 来请求数据或执行服务器端作。 他们可以在必要时与 JavaScript 互作，以利用 JavaScript 库和框架。
请考虑使用Blazor 构建您的 Web 应用程序，在以下情况下：
应用程序必须公开丰富的用户界面
与 JavaScript 或 TypeScript 开发相比，你的团队更熟悉 .NET 开发
如果正在考虑将现有的 Web Forms 应用程序迁移到 .NET Core 或最新的 .NET，不妨参阅免费的电子书《面向 Web Forms 开发人员的 Blazor》，以了解是否有必要将其迁移到 Blazor。
有关 Blazor 的更多信息，请参阅 关于 Blazor 的使用入门指南。
何时选择传统 Web 应用
以下部分更详细地说明了选择传统 Web 应用程序的原因。
您的应用程序具有简单、可能是只读的客户端需求
许多 Web 应用程序主要以只读方式供绝大多数用户使用。 只读（或以读取为主）应用程序往往比那些维护和操作大量状态的应用程序简单得多。 例如，搜索引擎可能包含包含文本框的单个入口点，以及用于显示搜索结果的第二页。 匿名用户可以轻松发出请求，并且不需要客户端逻辑。 同样，博客或内容管理系统的面向公众的应用程序通常主要由客户端行为很少的内容组成。 此类应用程序很容易构建为传统的基于服务器的 Web 应用程序，这些应用程序在 Web 服务器上执行逻辑并呈现要在浏览器中显示的 HTML。 网站的每个独特页面都有自己的 URL，可以被搜索引擎索引和方便地添加到书签中（默认情况下无需将此功能作为应用程序的单独功能添加），在这种情况下也是一个显著的优势。
应用程序需要在没有 JavaScript 支持的浏览器中正常运行
需要在对 JavaScript 支持有限或完全没有的浏览器中运行的 Web 应用程序，应使用传统 Web 应用工作流编写（或至少能够回退到这种行为）。 SPA 需要客户端 JavaScript 才能正常工作;如果它不可用，则 SPA 不是一个不错的选择。
你的团队不熟悉 JavaScript 或 TypeScript 开发技术
如果你的团队不熟悉 JavaScript 或 TypeScript，但熟悉服务器端 Web 应用程序开发，那么他们可能无法比 SPA 更快地交付传统 Web 应用。 除非学习编程 SPA 是一个目标，或者需要 SPA 提供的用户体验，否则传统 Web 应用是一个更高效的选择，适合已经熟悉构建它们的团队。
何时选择 SPA
以下部分更详细说明了何时为 Web 应用选择单页应用程序开发样式。
应用程序必须公开具有许多功能的丰富用户界面
当用户执行作或在应用区域之间导航时，SPA 可以支持不需要重新加载页面的丰富客户端功能。 SPA 很少需要重新加载整个页面，因此加载速度更快，可在后台提取数据，并且对单个用户操作的响应更快。 SPA 可以支持增量更新、保存部分完成的表单或文档，而无需用户单击按钮来提交表单。 SPA 能够比传统应用程序更容易支持丰富的客户端行为，例如拖放。 SPA 可以设计为在断开连接模式下运行，对客户端模型进行更新，该模型在重新建立连接后最终同步回服务器。 如果你的应用要求包括丰富的功能，则选择 SPA 样式的应用程序，这些功能超出了典型的 HTML 表单提供的功能。
通常，SPA 需要实现传统 Web 应用中内置的功能，例如，在反映当前作的地址栏中显示有意义的 URL（并允许用户添加书签或指向此 URL 的深层链接以返回到该 URL）。 SPA 还应该允许用户使用浏览器的后退和转发按钮，结果不会令他们大吃一惊。
你的团队熟悉 JavaScript 和/或 TypeScript 开发
编写 SPA 需要熟悉 JavaScript 和/或 TypeScript 以及客户端编程技术和库。 你的团队应该能够使用 Angular 等 SPA 框架编写现代 JavaScript。
参考 - SPA 框架
- Angular： https://angular.io
- React： https://reactjs.org/
- Vue.js： https://vuejs.org/
应用程序必须已公开其他（内部或公共）客户端的 API
如果已支持 Web API 供其他客户端使用，则创建利用这些 API 的 SPA 实现，而不是在服务器端表单中重现逻辑可能需要更少的精力。 在用户与应用程序交互时，SPA 广泛使用 Web API 来查询和更新数据。
何时选择 Blazor
以下部分更详细说明了何时为 Web 应用选择 Blazor 。
应用程序必须公开丰富的用户界面
与基于 JavaScript 的 SPA 一样， Blazor 应用程序可以在不重新加载页面的情况下支持丰富的客户端行为。 这些应用程序对用户更响应，仅提取响应给定用户交互所需的数据（或 HTML）。 正确设计后，可以将服务器端 Blazor 应用配置为在支持此功能后以客户端 Blazor 应用的形式运行，且更改最少。
与 JavaScript 或 TypeScript 开发相比，你的团队更熟悉 .NET 开发
与使用 JavaScript 或 TypeScript 等客户端语言相比，许多开发人员使用 .NET 和 Razor 更高效。 由于应用程序的服务器端已在使用 .NET 进行开发，因此使用 Blazor 可确保团队中的每个 .NET 开发人员都能理解并可能构建应用程序的前端行为。
决策表
以下决策表总结了在传统 Web 应用程序、SPA 或应用之间进行选择时要考虑的一 Blazor 些基本因素。
| 因素 | 传统 Web 应用 | 单页应用程序 | Blazor 应用程序 |
|---|---|---|---|
| 需要团队具备对 JavaScript/TypeScript 的熟悉度 | 最少 | 必需 | 最少 |
| 支持不编写脚本的浏览器 | 支持 | 不支持 | 支持 |
| 客户端应用程序行为极少 | 适合 | 过度 | 可行的 |
| 丰富的复杂用户界面要求 | 受限 | 适合 | 适合 |
其他注意事项
传统 Web 应用往往更简单，并且具有比 SPA 应用更好的搜索引擎优化（SEO）条件。 搜索引擎机器人可以轻松使用传统应用中的内容，而对索引 SPA 的支持可能缺乏或有限。 如果你的应用受益于搜索引擎的公共发现，这通常是一个重要的考虑因素。
此外，除非你为 SPA 的内容构建了管理工具，否则它可能需要开发人员进行更改。 传统 Web 应用通常更容易让非开发人员更改，因为大部分内容只是 HTML，可能不需要生成过程来预览甚至部署。 如果组织中的非开发人员可能需要维护应用的内容，则传统 Web 应用可能是更好的选择。
当应用具有复杂的交互式表单或其他用户交互功能时，SPA 会大放异彩。 对于需要身份验证才能使用的复杂应用，因此公共搜索引擎蜘蛛无法访问，在许多情况下，SPA 是一个很好的选择。
