我想开始使用 Blazor，尽管它仍处于 alpha 级别。
据我了解，Blazor 使用 WebAssembly 在客户端编译 C#。
我有这些问题：
这种方法是否比用 JavaScript 编译的 React / Vue.js 运行得更快？
每次页面加载时浏览器都需要下载 WebAssembly 库是真的吗？
在 Internet 上没有任何流行的 JavaScript 框架的性能比较。所以想知道微软新框架的理论性能。
【问题讨论】：
标签： asp.net performance blazor webassembly
浏览器是否需要下载 WebAssembly 每次页面加载时的库？
不，浏览器可以缓存文件。用于 Blazor 应用程序的通用 CDNs 可以解决问题。
这个系统是否比编译的 React / Vue.js 更快？ 在 JavaScript 中？
Blazor 使用 WebAssembly，理论上 WebAssembly 应该比任何 JavaScript 库都快。然而，并不是所有的浏览器都有成熟的 WebAssembly 解析器。所以你可能会发现目前浏览器不会以最佳速度运行 WebAssembly。
您可以创建一个小型 Blazor 应用程序并在 Firefox、Chrome 或 Edge 中运行它。在大多数情况下，Firefox 运行 Blazor 应用程序的速度比 Chrome 或 Edge 快得多，这意味着浏览器制造商仍然需要改进，甚至 Firefox 也可以改进。
如果您的应用程序需要频繁访问DOM，那么与任何 JavaScript 库相比，WebAssembly / Blazor 肯定会更慢，因为 WebAssembly 无法在不使用 Invokes 的情况下直接访问 DOM（目前速度很慢。请参考下面是我的 Blazor 基准测试）。
在 Firefox 上，10,000 次 RegisteredFunction.InvokeUnmarshalle 调用空方法需要 250 毫秒，而 Chrome 和 Edge 在我的 PC 中需要超过 2400 毫秒。在纯 JavaScript 中，相同场景所需的时间不到 10 毫秒。
此外，Blazor 的当前实现在浏览器的 WebAssembly 引擎之上有自己的 MSIL 引擎，这意味着有两个解释器在工作来运行 Blazor 项目，就像两个翻译器解释对话而不是一个。目前微软正在开发一个AOT 编译器，该编译器尚未发布。一旦发布，Blazor 将比当前的实现快得多。
Mono and WebAssembly - Updates on Static Compilation
我们可以放心地假设 Web 程序集是 Web 开发的未来，但目前我们还不能说 Blazor 的未来。从理论上讲，Blazor 可以比现有的任何框架都快，但是我们需要 WebAssembly 维护人员、浏览器开发人员、微软和社区的承诺，以使理论变得实用。
WebAssembly 存储库中有新提案。
允许 WebAssembly 直接处理 DOM。 Interface types #8
带有 GC 的 WebAssembly 的引用类型。 Reference Types for WebAssembly
以上两个提议将为未来 DOM 和 WebAssembly 之间更快的交互铺平道路。换句话说，Blazor 未来会更快。
Firefox 团队能够像调用 JavaScript 到 JavaScript 方法调用一样快地调用 JavaScript 到 WebAssembly。到目前为止，Firefox 在 WebAssembly 支持方面遥遥领先于任何其他浏览器。
【讨论】：
2021 年 4 月，我们针对旧版 Angular.js Web 应用以及 Flutter Web（HTML 和 CanvasKit 渲染器）进行了 Blazor WASM 试验。我们重新创建了旧版应用程序的主页（本质上是一个带有过滤器、分页、排序等的大数据网格）。以下是一些要点：
Lighthouse perf. Scores
Grid Displ. Data transf. Data uncomp. Reqs. FCP SI LCP TTI TBT CLS
Blazor* 2.2s 4.7MB 13.7MB 99 0.5s 1.6s 0.5s 2.1s 1.3s 0.01
Flutter HTML 1.7s 2.1MB 3.7MB 15 1.9s 2.5s 2.2s 2.3 0.2s 0
Flutter CanvasKit^ 2.8s 4.7MB 10.5MB 17 1.0s 2.2s -/- 2.2s 1s 0
AngularJS` 1.9s 2.0MB 5.7MB 294 2.1s 2.2s 2.6s 2.6s 0.1s 0
*Lighthouse 给出的 LCP 值不正确（它将 Blazor 的空白“正在加载...”页面计为 LCP）
^Flutter 的 CanvasKit 渲染器不允许 Lighthouse 获取 LCP 测量值
`旧版应用程序比创建的 PoC 大得多，有更多的屏幕和资产会影响应用程序启动时的请求数量
【讨论】：
据我了解，Blazor 使用 WebAssembly 在客户端编译 C#。
对了一半。您可以将代码写入 WebAssembly (WASM) 客户端（是的，客户端是 C#），但您也可以执行逻辑服务器端。两者都有好处。如果你走 WASM 路线，你的所有代码都是可见的。但它可以比逻辑全部基于服务器的情况更快地重新呈现——但如果它是基于服务器的，则您的代码是不可见的。
这种方法是否比用 JavaScript 编译的 React / Vue.js 运行得更快？
没有。我已经完成了大量的 Vue.js 并且 Vue.js 运行得更快。 但是我可以使用 Blazor 更快地编写代码 很多。 Blazor 提供了一种虚拟滚动解决方案，可以让它看起来更快。在我的情况下，可用的绘图组件太慢了。我使用 C# 和 JavaScript 编写了一个运行良好的 Blazor 组件。大多数时候我不担心 WASM 代码运行太慢...但是绘图需要更快... Blazor 让我有我的蛋糕...我只需要做一些低级别的工作JavaScript。在过去六个月中，Blazor 的执行速度越来越快，该团队表示，当.NET 6 出现时，还有更多的事情要做。但是对于我需要做的 99% 的事情来说，它已经足够快了。
每次页面加载时浏览器都需要下载 WebAssembly 库是真的吗？
如果它们被缓存，则不会。即使他们第一次加载，如果你有一个体面的连接，它也不会很慢。它大约为 10 MB。
一个没有被问到的大问题——它值得使用吗？我已经使用它大约六个月了。
对我来说，这很棒。 C# 是一门非常好的语言。有时我会错过动态添加属性，并且通常您必须手动启动重绘，但使用可空对象检查等功能会警告您没有检查您的代码是否会导致空引用检查——它比 JavaScript 好得多。我经常觉得使用 JavaScript“工具链”很痛苦。能够选择退出 JavaScript 库，真是太好了。
【讨论】：
.NET 6 的 ASP.NET Core 路线图可以在 github here 上找到。你会发现 Blazor 的任务是迄今为止最多的。
请注意，该列表表示 ASP.NET 团队将重点关注的项目意味着他们将重点放在改进 Blazor 上。
本期列出了我们的团队在 .NET 6 时间范围内将重点关注的主要投资清单。 此列表中的项目仅是主要投资领域，不包括我们将在此期间解决的所有功能和错误修复。
以下是他们一直从事的一些任务：
已完成的任务：
AOT 编译。 将所有内容编译到 WebAssembly
改进 Blazor 中的 SVG 支持。 Blazor 中 SVG 支持的顶级问题
在 JS Interop 中支持字节数组传输。
正在进行的任务
Blazor 的热重载。 构建性能优化
暂停和恢复 Blazor 应用程序。
定位并部署到桌面平台。
消除 SignalR 消息大小施加的大小限制。
拖放。 提供用户可以在拖动期间订阅的事件 并放下
【讨论】：