微软的wasm 和 rust的wasm 方案对比

Posted crazylights

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微软的wasm 和 rust的wasm 方案对比相关的知识,希望对你有一定的参考价值。

微软家的:blazor

技术图片

看图即可见原理。mono.wasm用来构造了一个dotnet解释器。

在blazor被微软收购之前是用的dotnetanywhere,现在换成了mono

然后,直接加载那些dll,执行正经的IL代码。


这个方案,稳健,除了加载容量吓死人

技术图片

这个helloworld,肉眼可见的压缩后容量超过100K的文件就4个。

开发工具 visual studio 2019

开发语言 IL家族

火狐家的rustwasm

技术图片

非常干净,代码直接被编译为wasm执行,没有依赖环境

这个helloworld,wasm 压缩后47k,胶水代码4k

开发工具,命令行工具链rust家族,IDE漂泊不定,vscode可以用

开发语言 rust

来互相伤害一下

先拉个表格

方案对比

微软

Blazor

火狐

RustWasm

blabla
原理把Mono解释器编译为wasm,然后解释执行dotnet dll直接将rust编译为wasm思路完全不同
容量

业务代码14K

解释器 压缩后600k

dotnet基础库 压缩后约800k

业务代码与依赖代码均编译在一起,47K火狐碾压胜
开发语言

dotnet 家族

理论上C# F# VB.net 等,实际上c#为主

rust定位完全不同
开发工具

visual studio 2019

编译、编辑、代码管理一体化

编译工具 rust 工具链和 wasm-pack 工具链

IDE 官方没有,vscode可以用。

微软碾压胜


我对比了四个维度

工作原理

blazor是直接把mono解释器变成了wasm,用户不需要再接触wasm。这个方案有很高的一致性,兼容性极好。用户不需要了解太多wasm,dotnet开发者即可上手。相当于用wasm写了一个脚本语言,然后用户写脚本。

而rust是直接把用户代码编译为wasm。

这是两个截然不同的方案,微软方案存在二次解析和GC,性能会有一定折扣。

容量

blazor的容量惊人,仅解释器和dotnet基础库压缩后就达到了1.5M,不压缩4M多。

仅此一条,将极大的限制blazor的使用场景。

rust在这个项目上碾压胜出

开发语言

c# 作为一门已经有很广泛用户基础的语言,其资料丰富程度是无法抵挡的,外加庞大的c#开发者。

而rust 则是一门致力于为难程序员的语言。

rust是c++的挑战者,他更加底层,尤其是在内存相关的设计上极为复杂。

c#有gc,代码编写比较容易。

对程序员友好度来说,自然是c#更优,但项目?何时轮到程序员的感受了。

rust没有gc,代码就小,也没有gc代价,转换成项目语言就是,rust代码比c#代码快,尤其在wasm环境,微软选了解释器,那就会更快(按照lua的效率预测,lua解释器性能大约是c语言同等逻辑的1/22,这个仅作参考)

开发工具

微软visual studio 2019,目前坊间称为宇宙最强IDE,绝非浪得虚名。

而rust 和 wasm-pack 只有命令行工具

rust IDE,目前体验比较好的,依然是微软家的visual studio code

n

100分 对 60分的差距


调试

微软碾压胜,可以在c#直接下断点,调试wasm环境的代码。


火狐的rust这边,还要靠打log,下断点的方法暂时还没有,希望rust生态的蓬勃发能尽快弥补这个短板。

wasm是支持sourcemap的,目前 wasm-pack工具包居然没有直接生成sourcemap,所以没办法在浏览器环境直接看到rust代码,短板啊。

小结

微软太异端,巨大的依赖容量无法实用化。

rust 还是目前wasm开发的首要选择

以上是关于微软的wasm 和 rust的wasm 方案对比的主要内容,如果未能解决你的问题,请参考以下文章

Rust 和 Wasm 初始设置

rust语言编写wasm简单例子

rust语言编写wasm简单例子

rust语言编写wasm简单例子

如何通过 wasm-pack 将 Rust Wasm 应用程序与 libpq 链接?

如何使用 Wasm 和 Rust 服务多个 HTML 页面?