在过去一两年里，倘若您一直关注.NET的发展，则很有可能听说过Blazor这个词。Blazor是 ASP.NET团队研究一个新的客户端的UI框架。 它的最大好处是能够使用HTML，CSS和C＃进行编写，而不是直接使用JavaScript编写好的Web UI，这是许多开发人员所梦寐以求的。
自JavaScript诞生以来，JavaScript就已成为前端Web开发的共识，然而我们却从未真正对此感到过满足。 近年来，连续不断的出现了多少超集或转译语言，旨在帮助改进JavaScript，让其更易于维护？ 比如：CoffeeScript，Dart，Elm和Scala 。
在最受欢迎的语言中，著名的Anders Hejlsberg设计的TypeScript语言，是最受关注的。同类型的还有一位，即C＃的设计者，在C#中添加了诸如接口、类以及编译时的类型检查甚至泛型之类的功能。这些功能已存在于C＃中，并已使用多年。C＃是一种功能强大、灵活、丰富的语言，易于学习。
然而Blazor已开始展示原有设计之外的，具有潜力、高效的编程模型，成为了JavaScript单页应用程序（SPA）框架的直接竞争对手。
微软已在Blazor上进行了复杂的实验，在桌面应用程序中试用了Electron和WebWindow（Electron的实验性轻量级替代品）。近，来Blazor编程模型与本地Xamarin表单控件混合在本地移动应用程序开发中。
我们是否可以从一个统一的UI框架开始看起，该框架可以使用.NET构建任何类型的应用程序，无论是Web，桌面还是移动应用程序？ 虽然我不了解你，但我确定能找到一个令人兴奋的前景。
让Blazor如此灵活的是什么呢？
要回答这个问题，我们需要了解Blazor是如何设计的。
实质上，Blazor在如何计算UI更改（应用程序/组件模型）和如何应用这些更改（渲染器）之间是有区别的。 这就使得Blazor与只能创建基于Web技术的UI的其他UI框架（例如Angular或ReactJS / React Native）进行了区分。 通过使用不同的渲染器，Blazor不仅可以创建基于Web的UI，而且还可以创建本机移动UI。
这确实需要对组件进行不同的创作，因此为Web渲染器编写的组件不能与本机移动渲染器一起使用。 但是，编程模型是相同的。 意味着开发人员一旦熟悉它，便可以使用任何渲染器创建UI。
渲染/托管模型
Blazor的应用程序/组件模型的核心是负责计算UI更改，但是您可以使用不同的渲染器来控制UI的实际显示和更新方式。 这些渲染器通常被称为托管模型。 在撰写本文时，Blazor在开发的不同阶段就有了四种托管模式。
Blazor Server
- 平台：Web
- 状态： GA /产品支持
Blazor WebAssembly
- 平台： Web
- 状态：预览（已提交产品）
Blazor Electron
- 平台：PC端（Windows, Mac, and Linux)
- 状态：实验中（未提交）
Mobile Blazor Bindings
- 平台：移动端 (iOS and Android)
- 状态：实验中（未提交）
在撰写本文时，Blazor Server是唯一支持产的品模型。 Blazor WebAssembly将于2020年5月左右发布——我期盼这会是个 Build 上的重要公告。 Blazor Electron和Mobile Blazor Bindings都处于实验中，Microsoft尚未结束交付。
应用/组件模型
这是框架中的引擎。 在这里，我们可以找到让Blazor工作的所有非UI特定元素。 编程模型，路由和导航以及渲染树，这是Blazor用于计算UI更改的机制。
我要重点关注的部分是编程模型。 在上面我提到的四种托管模型中，前三种具有一个共同点，它们都需要了解Web标准。 对于这些托管模型，需要使用HTML和CSS来编写的组件。 但是第四个模型Mobile Blazor Bindings是完全不了解Web标准。 因此托管模型构建的应用程序需要使用本机移动控件编写其组件。
为了提供更直观的示例，让我们看一看为Blazor WebAssembly编写的相同组件，该组件使用符合Web标准的渲染器，而Mobile Blazor Bindings则使用基于非Web标准的渲染器。
// WebAssembly Renderer
<div>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @οnclick="IncrementCount">Click me</button>
</div>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
// MobileBlazorBindings Renderer
<StackLayout>
<Label FontSize="30" Text="@($"Current count: {currentCount}")" />
<Button Text="Click me" OnClick="@IncrementCount" />
</StackLayout>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
可以很容易地看到两个代码示例之间的差异，但是我希望向您着重介绍相似之处。
这两个样本都有一个标记部分和一个代码块。 实际上，样本之间的代码块是相同的。 它们每个都带有一个指定处理程序的“ OnClick”事件，并且都使用表达式来输出当前计数字段的值。
这里要指出的是，编程模型是相同的。 这就是Blazor的强大功能，可以学习编程模型，并在其他地方进行一些调整，您就可以在任何平台上为任何类型的应用程序生成UI，而这些却是 .NET之前无法做到的。
现在，我们对Blazor的组合方式有了更多的了解，我想谈谈Blazor Server和Blazor WebAssembly这两种主要的托管模型。
Blazor Server
Blazor Server托管模型是当前Blazor开发的唯一受产品支持的选项。 在.NET Conf期间，它是2019年9月与.NET Core 3一起发布。
在此模型中，Blazor应用程序运行在满.NET Core的服务器上。 当用户加载应用程序时，将下载一个小的JavaScript文件，该文件将与服务器实时建立双向 SignalR连接。 然后，用户与该应用程序所进行的任何交互都会通过SignalR连接传输回服务器，以供服务器处理。 服务器完成后，所有UI更新都将传输回客户端，并应用于DOM。
现在，我知道您思考什么。 这个是不可能的实现的性能，让这些交互和UI更新不断地来回发送。 但我认为您实际上会感到惊讶。
该团队在Blazor Server上进行了一些负载测试，以确定它可以处理和无法处理的内容，以下是他们发现的内容
测试1 – Azure上的标准D1 v2实例（1vCPU和3.5GB内存）
该应用程序可以处理 5000个并发运行的用户，而性能不会明显下降。
测试2 – Azure上的标准D3 v2实例（4vCPU和14GB内存）
该应用程序可以处理 20,000个并发运行的用户，而性能不会出现任何明显下降。
这些数字令人印象深刻，我想你会同意的。 实验发现，内存和延迟是Blazor Server应用程序的主要瓶颈。 如果延迟时间超过200毫秒，则性能会受到冲击，可用的内存空间受到限制。
好处
- 在满的.NET Core运行时上运行
- 快速的开发周期
- 下载量小
- 代码保存在服务器上，而不下载到客户端
缺点
- 在高延迟环境中不能很好地工作
- 没有离线支持-需要与服务器的稳定连接
- 服务器上有大量资源需求
理想的用例
老实说，我认为Blazor Server可以应用于很多脚本中，也将会用在Intranet应用程序或面向用户的低需求应用程序中。 由于所有内容都在服务器上，因此使用此托管模型的开发速度非常快。 不需要单独的API项目，例如，您可以直接在组件中使用应用程序服务。 起初，我对Blazor Server表示怀疑，但是我不得不说，我对它的功能感到非常惊讶。
Blazor WebAssembly
通常是引起人们最大兴趣的托管模型，这是有充分理由的。该模型为JavaScript SPAs(如Angular、VueJS和React)提供了直接的竞争对手。
通过使用WebAssembly，我们可以使用C＃而不是使用JavaScript编写UI逻辑。 目前处于预览状态，预计于2020年5月左右发布。
编译为WebAssembly的 Mono .NET运行时的版本与应用程序DLL和所有依赖项一起下载到客户端的浏览器中 。 一旦所有内容都放入浏览器中，Mono运行时将被引导，然后依次加载并执行应用程序DLL。
我要解决的第一个问题通常是听到上述解释后得出的，下载大小是多少？ 好吧，当前的预览重约2.4mb，考虑到涉及到.NET运行时，这确实令人印象深刻。 但是，我很欣赏与某些JavaScript框架相比，这并不奇怪。 到五月份发布WebAssembly托管模型时，团队希望大幅缩减该规模。 Blazor的第一个原型使用了非常紧凑的.NET运行时，该运行时仅编译为60k的WebAssembly代码。 我相信重大的尺寸改进只是时间问题。
当前，Blazor WebAssembly使用解释模式加载和运行您的应用程序。 在这种模式下，Mono IL解释器将在浏览器内执行您的应用程序.NET DLL。 编译为WebAssembly的过程的唯一部分是Mono运行时。 将来，该团队希望允许开发人员选择是否将自己的应用程序或应用程序的更可能部分也编译为WebAssembly，这称为AOT或Ahead of Time编译。 此模式的好处是性能，但要权衡较大的下载大小。
好处
- 编译为静态文件，这意味着服务器上不需要.NET运行时
- 工作已从服务器转移到客户端
- 应用可以在离线状态下运行
- 代码共享，C＃对象可以在客户端和服务器之间轻松共享
缺点
- 有效负载。现在，如果您创建一个新的Blazor项目，则其重约2.4mb。团队希望在五月份大幅度降低这一成本。
- 加载时间。由于下载大小，连接不良的设备可能会需要更多的初始加载时间。
- 受运行时间的限制。应用程序必须在浏览器的核中运行，并且受到与任何JavaScript应用程序相同的安全限制。
理想的用例
Blazor WebAssembly旨在与现代JavaScript框架直接竞争。 因此，在您希望使用这些框架之一的任何地方，都可以考虑使用Blazor。 将Blazor WebAssembly应用程序制作为PWA（渐进式Web应用程序）也很简单。 实际上，五月份将有一个开箱即用的模板。
同样重要的是要指出，使用Blazor WebAssembly不需要您在服务器上使用.NET。 这意味着，如果您有用Node，PHP或Rails编写的后端，则可以愉快地将Blazor用作前端，因为Blazor WebAssembly可以编译为静态文件，因此没有任何问题。
Blazor的未来是什么？
现在已经有一种托管模型投入生产，另一种即将投入生产，让我们将注意力转向未来。
我看到Blazor去哪了？ 回到我早先关于Blazor成为任何.NET应用程序的单个UI框架的想法。 我认为这是Blazor的发展方向。 如果当前所有的Blazor托管模型都投入生产，现在我不知道为什么不这样做，那么开发人员将可以选择学习一个编程模型，并可以在任何地方创建UI。 这是一个大问题。
在围绕进入.NET的障碍进行了大量讨论的同时，该平台的新开发人员不得不面对众多选择，Blazor可以在UI，单一编程模型，一次学习并应用的过程中提供清晰的信息。 任何地方。 对我来说，这就是Blazor的炒作。
Tags: blazor, bulletin, c sharp, dot net, stackoverflow, web dev
原文链接：https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/
