.NET 在 WebAssembly 中的 CLR答案

【问题标题】：.NET's CLR in WebAssembly.NET 在 WebAssembly 中的 CLR
【发布时间】：2019-11-07 11:01:51
【问题描述】：

我试图从 .NET 角度理解 WebAssembly 的意义。

在浏览器中运行 .NET 是通过一个相对较新的称为 WebAssembly 的标准化网络技术。

这是一个奇怪的说法。

显然，您可以在没有 WebAssembly 的情况下在浏览器中运行 .NET 代码，方法是将其交叉编译为 JavaScript（例如，使用 JSIL）。这很糟糕，因为

CLR 的对象模型比 JavaScript 的更复杂（例如，您可以创建一个紧凑的整数数组，Uint8Array，但不能在 JavaScript 中使用更复杂的值类型）使得某些类型的代码的翻译效率非常低。
.NET 的原生基础库实现也需要用 JavaScript 实现，工作量很大。
浏览器生态系统基于 JavaScript，因此如果使用此类交叉编译会产生摩擦。

所以FAQ的意思是它现在实用，对吧？

我很难看到 WebAssembly 如何帮助解决这些问题。粗略的一瞥表明它的虚拟机仍然不能有效地正确表示 CLR（仍然没有复杂的值类型，对吧？）。其他两点无论如何都会成立。

那么发生了什么变化？ WebAssembly 究竟带来了哪些仅靠 JavaScript 无法实现的东西？真的只是 Webassembly 是基于堆栈的，而 JS 本身不是吗？为什么会有这么大的问题？

编辑：对 Henk 的中肯回答感到非常高兴。有兴趣的，我现在找到a great rationale page。

【问题讨论】：

通过已编译为 WASM 的 CLR 运行“本机”.net 程序集，允许您调试在 Visual Studio 的浏览器中运行的 .Net 代码。对我来说，这似乎是一个双赢的局面。无需交叉编译 .Net 程序集，我可以用 C# 编写完整的堆栈
@phuzi 不明白为什么需要浏览器功能。这是一个工具问题。
它带来的不是附加功能，而是速度和the ability to write code in your preferred language。

【解决方案1】：

表明它的虚拟机仍然不能有效地正确表示 CLR

正确。这就是 Blazor 首先部署 Mono 的编译到 WASM 版本的原因。
Blazor 为聚会带来了自己的 CLR。

您的应用程序代码不会被编译为 Wasm，它将被部署为由 Mono 执行的（常规）IL。使用开发工具，您可以看到一堆 .DLL 文件正在下载到您的浏览器。原则上，您可以使用适合浏览器安全沙箱的任何 .net 标准包。

WebAssembly 究竟带来了哪些仅靠 JavaScript 无法实现的功能？

它使 C 编译器能够将 Mono.*.c 编译为 Mono.wasm。
而且速度很快。

【讨论】：