我想开始使用 Blazor，尽管它仍处于 alpha 级别。
据我了解，Blazor 使用 WebAssembly 在客户端编译 C#。
我有以下问题:
这种方法的运行速度是否比用 JavaScript 编译的 React/Vue.js 等更快？
浏览器每次加载页面时都需要下载 WebAssembly 库吗？
互联网上没有任何流行 JavaScript 框架的性能比较。所以我想了解一下微软新框架的理论性能。
最佳答案
Is it true that the browser will need to download the WebAssembly library every time the page loads?
不，浏览器可以缓存文件。常见CDNs对于 Blazor 应用程序来说就可以了。
Is this system faster to work than, for example, React / Vue.js, compiled in 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 毫秒，而在我的 PC 中，Chrome 和 Edge 需要超过 2400 毫秒。在纯 JavaScript 中，相同场景所需时间低于 10 毫秒。
此外，Blazor 当前的实现有自己的 MSIL引擎位于浏览器的 WebAssembly 引擎之上，这意味着有两个解释器正在运行 Blazor 项目，就像两个翻译器解释对话而不是一个翻译器一样。目前 Microsoft 正在开发 AOT编译器，尚未发布。一旦发布，Blazor 将比当前的实现快得多。
Mono and WebAssembly - Updates on Static Compilation
我们可以有把握地假设 Web 程序集是 Web 开发的 future ，但目前我们无法对 Blazor 的 future 说任何话。从理论上讲，Blazor 比任何框架都快，但是我们需要 WebAssembly 维护者、浏览器开发人员、Microsoft 和社区的 promise 才能使理论变得实用。
2018 年 7 月 10 日更新
WebAssembly 存储库中有新提案。
允许 WebAssembly 直接处理 DOM。 Interface types #8
带有 GC 的 WebAssembly 的引用类型。 Reference Types for WebAssembly
上述两项提案将为将来 DOM 和 WebAssembly 之间更快的交互铺平道路。换句话说，Blazor future 会更快。
2018 年 10 月 17 日更新
Firefox 团队能够像 JavaScript 到 JavaScript 方法调用一样快速地实现 JavaScript 到 WebAssembly 调用。到目前为止，Firefox 在 WebAssembly 支持方面远远领先于任何其他浏览器。
关于asp.net - Blazor 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50422396/