在这篇文章中，咱们将解决一些常见的Blazor问题。具体来说就是"什么是Blazor"，但更重要的是"为什么要用Blazor"。既然咱们曾经有了Angular、React、Vue或其余一些JavaScript框架，为什么还要关注Blazor 以及为什么要抉择Blazor? WebAssembly又是对于什么的?咱们将介绍微软的web利用程序开发框架的历史，以及咱们对其光明前景的瞻望。

什么是 Blazor

Blazor有几个常见的定义，第一个非常简单:

Blazor是一个用.NET构建交互式客户端web UI的框架。
-微软文档:Blazor

正如官网文档所述，它首先是一个"框架"——它被用来构建客户端web UI。但它与其余用于构建web UI的客户端框架有何不同?是什么让它如此特地? 我心愿你会问本人：".NET 有什么不同吗？"

这是另一个定义:

Blazor是一个收费和开源的web框架，开发者能够应用c#和HTML创立web应用程序。"
——维基百科:Blazor

哦，它是收费的——这很好。 但偏心地说，还有很多其余收费框架可用于构建客户端 Web UI。 我为什么要关怀 Blazor？

为什么是Blazor？

从历史上看，微软之前所有的web UI框架都是基于齐全不同的架构，并在服务器端出现。Blazor着手将c#开发引入web客户端，这只有在WebAssembly呈现时才可能实现。

WebAssembly(缩写为Wasm)是一种用于基于堆栈的虚拟机的二进制指令格局。Wasm被设计为编程语言的可移植编译指标，使客户端和服务器应用程序可能在web上部署。"
——webassembly.org

哇，听起来很拗口!让咱们来剖析一下:

在这种状况下，"二进制指令格局"意味着它是字节代码，从非javascript编程语言中提取形象语法树(AST)并将其转换为二进制。

Wasm位于"基于堆栈的虚拟机"之上——这标识了基于"推送"⬇ 和"弹出"⬆ 的外围性能。指令被推送，评估被弹出。尽管这是一种适度简化，但概念依然存在，实现细节并不那么重要。单线程、利用内存束缚等都有一些限度，然而Blazor治理与Wasm的互操作时没有强调这些限度。

请留神Wasm是一个"可移植编译指标"，这一点十分重要。这意味着能够应用C、C++、Rust、C#和其余非传统的Web编程语言，并以Wasm为指标进行编译。这就产生了Wasm二进制文件，它基于凋谢规范，但来自JavaScript以外的编程语言。

简言之，Blazor可与JavaScript互操作，甚至有不同的托管模型——服务器端和Wasm的客户端。稍后会具体介绍……

什么是 JavaScript?

Wasm是JavaScript的终结吗，这意味着什么?答案是否定的。JavaScript不会隐没——Wasm应该被认为是JavaScript的补充。

预计JavaScript和WebAssembly将在许多配置中一起应用。
——webassembly.org:常见问题解答

类比

感激 Wasm，网络浏览器的一些局限性失去改善，这也是为什么我置信：

"有了 WebAssembly，网络浏览器更像是应用程序商店——最终用户体验更靠近原生性能。"

——大卫·松

仿佛有有数特定于Wasm的新案例无奈独自应用JavaScript实现。很容易设想应用程序通过web交付到您的浏览器，由Wasm提供更简单和资源密集型的案例。这就是为什么我认为这是web利用平台可能实现的范式转变。

采纳

Wasm在所有支流浏览器中都失去了反对，并且笼罩了简直93%的所有用户——我能够应用"WebAssembly"吗?这与Silverlight所依赖的基于插件的办法不同。这是web的将来，您将持续看到开发人员应用这种技术构建应用程序。

安全可靠

Wasm和JavaScript一样平安。

WebAssembly形容了一个内存平安的、沙箱执行环境，它甚至能够在现有的JavaScript虚拟机中实现。当嵌入到web中时，WebAssembly将强制浏览器的同源和权限安全策略。"
——webassembly.org

换句话说，Wasm被限度在与JavaScript雷同的平安沙箱中。

Web利用平台

通过古代 Web 利用程序开发，您心愿您的应用程序在桌面和挪动浏览器上都能响应。古代 Web 应用程序比它们的前辈更加简单和丰盛，具备一些预期性能，包含实时 Web 性能、渐进式 Web 应用程序 (PWA) 性能和精心编排的用户交互。 .NET 开发人员第一次能够应用他们现有的 C# 技能在 Web 上构建各种应用程序。在我看来，这有助于含糊后端和前端开发人员之间的界线——但更宽泛地通过web扩大利用程序开发。我置信在客户端和服务器上应用雷同的编程语言的理念会促成用户更快的采纳，特地是 Node.js。

相熟

你兴许可能很容易接受能够应用现有的C#技能进行开发，但也容易疏忽这个事实：HTML、CSS和JavaScript依然存在并可用。通过这些，您能够持续应用您的HTML和CSS技能、您最喜爱的CSS库，并且能够轻松地应用现有的JavaScript包。毕竟，您依然在构建web应用程序!

简史

早在 1996 年，Active Server Pages (ASP)就为 Microsoft 的动静网页提供了第一个服务器端脚本语言和引擎。随着 .NET Framework 的倒退，ASP.NET 诞生了，随之而来的是 Web Forms。 Web Forms 已经（当初依然）被许多喜爱 .NET 性能的人应用，它容许在服务器端出现 HTML。

一段时间后，ASP.NET 模型视图控制器 (MVC) 被引入，它使 Web 窗体看起来很机灵。 MVC 使 ASP.NET 开发人员开始不得不理解网络的三大支柱： HTML、CSS 和 JavaScript。在MVC 中，有一个简略的靠近Web 规范的一致性。 MVC 还增加了一个不同的编程模型，它基于控制器和视图。这有助于解决来自开发人员社区的一些阻力，开发人员留神到他们与 Web Forms 的开发交互不是无状态的——来自与HTTP 的性质相矛盾的框架的错觉。

ASP.NET Web API 越来越受欢迎，开发人员承受了 .NET 的弱小性能。 Web API 开始被承受为构建基于 .NET 的 HTTP 服务的规范。

最终，利用 MVC 的 Razor 视图引擎——Razor Pages 登上了舞台。 ASP.NET Core 的翻新使这所有成为可能。

ASP.NET Core 是一个跨平台、高性能、开源的框架，用于构建反对云的古代互联网连贯应用程序。
— Microsoft 文档：ASP.NET Core 简介

ASP.NET Core 为您在古代开发中冀望的所有根底提供"一流公民身份"，例如（但不限于）依赖注入、强类型配置、日志记录、全球化和本地化、身份验证和托管。

Razor Pages 将控制器和视图交融在一起，使其在逻辑上更具凝聚力，更偏向于真正的组件，并构建在 Web API 基础架构上。

在 Razor Pages 之后是 Blazor。"Blazor"这个名字是文字游戏，联合了 B rowser和 R azor，因为开发人员善于命名事物 – 没错吧？ 这就是咱们明天所处的地位，在一个领有 Blazor 及其所有性能的世界中。 针对.NET 的独创，这是一个单页应用程序框架。

单页应用程序(SPA)

Blazor 是 Microsoft 惟一基于 .NET 的 SPA 框架。有许多风行的 SPA 框架，包含：

  • Angular
  • React
  • Vue
  • Svelte

次要区别在于这些都是基于 JavaScript，而不是 Wasm。

有时，应用 Blazor 构建应用程序的开发人员会混同两种托管模型的差别。有人误会 Blazor 服务器（服务器端）不是 SPA。服务器端的实质感觉更像是以前的非 SPA .NET Web 应用程序框架。但让咱们看看 SPA 的定义：

“单页应用程序 (SPA) 是一种 Web 应用程序或网站，它通过应用来自 Web 服务器的新数据动静重写以后网页来与用户交互，而不是 Web 浏览器加载整个新页面的默认办法”
— 维基百科：单页应用程序

无论托管模型如何，Blazor 都满足此定义。应用 Blazor 服务器，服务器公开具备特定 Blazor 协定的 SignalR集线器，该协定负责实时传播客户端应用程序中文档对象模型 (DOM) 的更新。当 DOM 中存在差别（或增量）时，更改会立刻反映进去。

在 Blazor WebAssembly 中，当客户端申请应用程序时，它会作为一些 HTML、CSS 和 JavaScript 提供——就像所有其余 Web 应用程序一样。 blazor.webassembly.js 文件疏导应用程序并开始加载 .NET 二进制文件，能够在浏览器的"网络"选项卡中通过网络查看这些文件。

开源

它是开源的，作为 ASP.NET Core GitHub 存储库的一部分。

Github dotnet / aspnetcore：

ASP.NET Core 是一个跨平台的 .NET 框架，用于在 Windows、Mac 或 Linux 上构建基于云的古代 Web 应用程序。

我是开源软件开发的鼎力支持者。对我来说，可能公开地看到一个性能是如何构建、设计和实现的，这扭转了游戏规则。公布问题、提出个性、与开发团队和其他人合作以及创立拉取申请的能力使软件社区为核心。毫无疑问，这最终会产生更好的产品！

代码重用

SPA 开发人员多年来始终在打一场失败的战斗，在这种状况下，Web API 端点定义了特定形态的无效负载——开发人员必须理解每个端点的形态，最好映射到客户端上的模型。这是一个十分乏味的过程，并且容易出错。 Blazor 能够通过与 Blazor 客户端应用程序共享来自 .NET Web API 的模型来缓解这种担心。

整个 .NET 库都能够在服务器端和客户端场景中共享和应用。利用现有的逻辑、性能和能力让开发人员能够专一于更多的翻新，因为他们不须要从新定义根底工具。

工具

开发团队的生产力始终是所有类型的利用程序开发的次要关注点。现有的开发人员工具是胜利的要害，如果您的团队摸索或努力完成常见的编程工作——整个我的项目可能会失败。应用Blazor开发，您能够应用通过验证好的开发人员工具，如:

  • Visual Studio
  • Visual Studio for Mac
  • Visual Studio代码

此外， .NET CLI曾经成为一个生产力弱小的工具，具备新的(模板)、构建、复原、公布、运行、测试、打包和迁徙命令(仅举几个例子)——应用它会大大晋升您我的项目胜利的可能性。

所有这些都是用当今世界上最弱小、最古代的编程语言构建的——我的观点那就是C#。

.NET APIs

作为一个领有十多年实在web利用程序开发教训的开发人员，我能够有把握地说，我已经屡次牢靠地应用.NET进行企业生产应用程序的开发。.NET自身的API surface area就很大， 并且作为一个由NuGet提供的第三方包组成的生态系统，难道不值得喜爱吗?

为什么这很重要?

我最近见证了一个.NET API的开发过程，从它的开始到它的成绩——我察看到这个过程十分的成熟和稳固。

请记住，为了让公众看到，这是齐全公开的。最开始在晚期的探讨期间，一个想法诞生了，而后以一个官网提案的模式在GitHub上提出。这个问题蕴含了您对提案的所有冀望，问题陈说、用例、示例语法、倡议的API surface area、示例用法，甚至还有来自原始探讨和想法的评论的链接。

这个提案会通过长时间的探讨，倡议、推理和会谈。最终由加入公开API设计评审会议的人最终确定一个草案。官网的.NET API设计评审会议遵循每周会议安顿。审核过程中，将捕捉正文，利用GitHub标签，最终取得批准——这样，有问题的.NET API就被编码为一个代码片段。

从这里开始，该问题就成为了旨在满足提议的pull申请的参考点。开发人员解决问题，实现API，编写单元测试，并创立pull request (PR)。PR要通过审查，当它被合并时，API必须被记录、沟通、捕捉/报告、推广、共享、剖析等等。

所有这些，像这样一个.NET API，有成千上万的.NET API存在。在所有.NET贡献者的反对下，您将失去很好的帮忙。无关更多信息，请参阅官网API审查流程。

我向一个对.NET API非常重视的敌人询问了一些对于这个主题的失当词语:

“.NET平台以领有一组十分有用的api而骄傲，无论你在构建哪种应用程序，这些api都能让你的应用十分高效。有了Wasm，当您应用Blazor WebAssembly构建基于浏览器的应用程序时，也能够应用这种性能。”
——Immo Landwerth

反对

对于所有.NET产品，都有各种各样的反对策略。对于开发团队来说，了解公布的生命周期及其相应的反对策略通常是一个重要的思考因素。在大多数状况下，倡议构建面向.NET长期反对(Long Term Support, LTS)版本的生产就绪应用程序。然而，一些公司和开发团队抉择跟踪以后(甚至预览)版本——他们偏向于更踊跃地迁徙。要理解更多信息，请参阅官网的.NET站点，理解反对细节:

  • .NET反对政策
  • 什么是笼罩

开发者社区

我向一些Blazor开发者社区的敌人询问了他们的想法，并在被问及"为什么是Blazor?"的时候，他们答复：

Blazor的组件模型使构建应用程序成为一种乐趣。它很简略，然而当你须要它的时候，它又能提供很多定制服务。
— 克里斯·桑蒂@chrisainty

我批准克里斯的认识。开发简略且可定制的应用程序有很多乐趣。

.NET的生产力高效。我能够应用我现有的技能、工作流程、工具和以前编写的库。这里没有npm或webpack，然而，我有.NET堆栈和它的生态系统，这让我超级高效。
——Ed charbenau @ edcharbenau

我完全同意埃德的观点。生产力是一个要害的驱动因素——而且不须要编写大量的JavaScript当然能够加重web开发的苦楚。

Blazor开发者社区正在蓬勃发展:

令人敬畏的Blazor: Blazor资源的汇合

Awesome Blazor浏览器:搜寻Awesome Blazor资源

Blazor纪念日:2021

发展前景

除了令人惊叹的Blazor开发者社区、开发者工具、开源生态系统和受人尊敬的行业首领的强烈意见外，还有来自次要组件供应商的整个UI组件倒退，他们正在踊跃构建Blazor组件(按字母顺序排列):

  • DevExpress
  • GrapeCity
  • Infragistics
  • Radzen
  • Smart HTML Elements
  • Syncfusion
  • Telerik

客户故事

每当微软的客户兴奋地分享他们的故事时，他们也在为本人谈话——这里有两个Blazor的胜利故事:

  • 通用航空
  • 邮资

代码

要疾速创立一个Blazor WebAssembly我的项目，请应用dotnet new blazorwasm .NET CLI命令。

在后面的命令中，咱们指定了我的项目的名称(-n)，并且咱们不心愿进行复原。如果你要关上Pages/Counter。在razor文件中，你会看到一些相似于上面的razor代码:

@page "/counter"<h1>Counter</h1><p>Current count: @_currentCount</p><button class="btn btn-primary"        @onclick="IncrementCount">     Click me</button>@code {    private int _currentCount = 0;    private void IncrementCount() =>        ++ _currentCount;}

这是一个简略的计数器页面。它被认为是一个页面而不是一个组件，因为它的@page指令指定了"/counter"的页面门路。因为它是基于Razor视图引擎的，所以它就像一个模板——在这里你能够援用HTML中的c#代码变量。这也演示了@code{…}指令，它容许你将c#性能间接嵌入到模板文件中。\_currentCount变量是公有的，作用域是页面，并从IncrementCount办法递增。该办法在单击按钮时调用，并通过@onclick事件绑定。随着\_currentCount值的减少，更改会立刻反映到绑定的地位。在本例中，它们作为"Current count"显示在元素中。

计数器页面只是一个小例子展现了可能性，作为一个网页开发人员，在这里有更多的惊喜期待着您。 我心愿.NET会是您下一个web利用程序开发我的项目中会思考的工具。

总结

作为开发人员，有许多工具可供您抉择。对于所有开发人员的抉择，当决定是否应用某一种框架时，应该是由整个团队所决定。Blazor是另一个抉择，但并不适用于所有用例——晓得何时应用它与晓得如何应用它一样重要。在这篇文章中，咱们探讨了"什么"和"为什么"。"如何"这个词曾经有很多报道了。

请思考其余资源:

  • 在Microsoft Learn上用Blazor构建一个web应用程序
  • 介绍了ASP.NET Core Blazor
  • Blazor托管模型
  • Blazor JavaScript交互操作
  • Blazor WebAssembly性能

有任何技术问题，请在 Microsoft Q&A上发问。