浏览器在每次加载页面时都需要下载WebAssembly库，这是真的吗？
不，浏览器可以缓存文件。Blazor应用程序的常见CDNs就可以了。
这个系统是否比用JavaScript编译的React/Vue.js运行得更快？

• • Blazor**使用WebAssembly，理论上WebAssembly应该比任何JavaScript库都快。然而，并不是所有的浏览器都有成熟的WebAssembly解析器。所以你可能会发现浏览器到目前为止还不能以最佳速度运行WebAssembly。

你可以创建一个小的Blazor应用程序，在Firefox、Chrome或者Edge中运行，大多数情况下，Firefox运行Blazor应用程序的速度要比Chrome或者Edge快很多，这意味着浏览器厂商仍需改进，即便是Firefox也可以改进。
如果您的应用程序需要频繁访问DOM，那么WebAssembly/Blazor肯定会比任何JavaScript库都要慢，因为WebAssembly不使用Invoke就无法直接访问DOM（目前很慢，请参考下面的Blazor基准测试）。
在Firefox上，10，000个RegisteredFunction.InvokeUnmarshalle调用空方法需要250毫秒，而在我的PC上，Chrome和Edge需要超过2400毫秒，在纯JavaScript中，同样的场景需要不到10毫秒。
此外，Blazor目前的实现在浏览器的WebAssembly引擎上有自己的MSIL引擎，这意味着有两个解释器在运行Blazor项目，就像两个解释器解释一个对话，而不是一个。目前微软正在开发AOT编译器，尚未发布。一旦发布，Blazor将比当前的实现快得多。

• 一个五个 *

我们可以放心地假设Web组件是Web开发的未来，但目前我们还不能对Blazor的未来说什么。理论上，Blazor可以比任何框架都快，但我们需要WebAssembly维护者、浏览器开发者、微软和社区的承诺，使理论成为现实。

更新日期：2018年7月10日

WebAssembly存储库中有新的建议。
1.允许WebAssembly直接处理DOM。* Interface types #8 *
1.使用GC的WebAssembly的引用类型。* Reference Types for WebAssembly *
以上两个建议将为DOM和WebAssembly之间更快的交互铺平道路，换句话说，Blazor在未来会更快。
2018年10月17日更新
Firefox团队能够像JavaScript到JavaScript方法调用一样快速地实现JavaScript到WebAssembly的调用，到目前为止，Firefox在WebAssembly支持方面远远领先于其他浏览器。

• 一个

2021年4月，我们在一款传统Angular.js网页应用和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

• Grid Displ. -完全显示网格所需的时间（根据时间线和Lighthouse收集的截图判断）
• 数据传输-加载应用程序时传输的数据（DevTools中的网络选项卡，清除缓存）
• Data uncomp. -传输的数据的未压缩大小（Network选项卡）
• Reqs. -加载应用程序时发出的请求数（“网络”选项卡，清除缓存）
• Lighthouse性能得分明细
• 已在Windows 10、谷歌浏览器版本89.0.4389.128（官方版本，64位）、英特尔酷睿i5 4460、16 GB RAM、有线局域网连接上进行测试
• 发布用于构建应用程序的配置，Blazor WASM/.NET 5，Flutter（通道测试版，2.1.0-12.2.pre），AngularJS 1.7.7
• Lighthouse给出的LCP值不正确（它将Blazor的空白“Loading...”页面计为LCP）

^Flutter的CanvasKit渲染器不允许Lighthouse获取LCP测量
'遗留应用程序比创建的POC大得多，有更多的屏幕和资产，这会影响应用程序启动时的请求数量

据我所知，Blazor使用WebAssembly在客户端编译C#。
一半正确。您可以将代码写入WebAssembly（WASM）客户端（是的，客户端是C#），但您也可以在服务器端执行逻辑。两者都有好处。如果您选择WASM路线，则所有代码都是可见的。但它可以比基于服务器的逻辑更快地重新呈现--但如果基于服务器的逻辑，则代码是不可见的。
这种方法是否比用JavaScript编译的React/Vue.js运行得更快？
不。我已经做了大量的Vue.js和Vue.js运行速度更快。* 但 * 我可以写代码快 * 很多 * 使用Blazor。Blazor提供了一个虚拟滚动解决方案，可以使它看起来更快。在我的情况下，可用的绘图组件太慢。我写了一个Blazor组件使用C#和JavaScript，工作得很好。大多数时候，我不担心WASM代码运行太慢...但是绘图需要更快...... Blazor让我有了自己的蛋糕......我只是不得不在JavaScript中做一些低级的工作。Blazor的执行速度在过去六个月里变得更快了，团队说.NET 6出来后会有更多的东西。但是对于我所需要做的99%来说，它已经足够快了。
浏览器在每次加载页面时都需要下载WebAssembly库，这是真的吗？
如果缓存的话就不会，即使是第一次加载，如果你有一个不错的连接，也不会慢，大约是10MB。
最大的未被问到的问题--它值得使用吗？我已经用了大约六个月了。
对我来说这很棒。C#是一种非常好的语言。有时我会错过动态添加属性的机会，而且经常需要手动启动重绘，但是像nullable object checks这样的特性会警告您没有检查代码是否会导致空引用检查--它比JavaScript好得多。我经常觉得使用JavaScript "工具链"很痛苦。能够选择退出JavaScript的库抖动真是太好了。

NET 6的ASP.NET核心路线图可以在github here上找到，你会发现Blazor的任务最多。
请注意，该列表指出了ASP.NET团队将重点关注的项目，这意味着他们非常重视对Blazor的改进。
这个问题代表了我们团队在.NET 6时间框架内将重点关注的主要投资列表。列表中的项目只是主要投资领域，并不包括我们将在此期间处理的所有功能和错误修复。
以下是他们一直在从事的部分任务：

已完成的任务：

1. AOT编译。* 将所有内容编译到WebAssembly*
   1.改进Blazor中的SVG支持。* Blazor中SVG支持的顶级问题 *
2. JS Interop支持字节数组传输。

正在执行的任务

1. Blazor的热重新加载。* 构建性能优化 *
   1.暂停和恢复Blazor应用程序。
   1.定位并部署到桌面平台。
   1.删除SignalR消息大小强加的大小限制。
   1.拖放。* 提供用户可以在拖放过程中订阅的事件 *