时间戳

首页 > 解决方案 > .NET 在 WebAssembly 中的 CLR

javascript - .NET 在 WebAssembly 中的 CLR

问题描述

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

从Blazor 常见问题解答：

一种称为 WebAssembly 的相对较新的标准化 Web 技术使在浏览器中运行 .NET 成为可能。

这是一个奇怪的说法。

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

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

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

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

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

编辑：对 Henk 的直截了当的回答感到非常高兴。对于感兴趣的人，我现在找到了一个很棒的基本原理页面。

标签： javascript.netblazor

解决方案

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

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

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

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

It enables a C compiler to compile Mono.*.c to Mono.wasm.
And it is fast.

推荐阅读