WebAssembly

WebAssembly的目标并非取代Web上的JavaScript, 而是与JavaScript互相补充.
WebAssembly导出的函数在JavaScript被视作使用native code的函数.
  • 由于需要从JavaScript侧暴露外部函数给WASM调用, 加上数据类型的转换/序列化/复制成本,
    在WASM侧调用Web API的效率 比JavaScript慢得多, 调用的次数越多越慢, 非数值类型数据传递得越多越慢.
    这也导致了WASM的最佳使用方法是用WASM补充JavaScript的计算性能, 而不是完全由WASM编写程序.
    在未来, 通过externref/anyref和更好的WASM接口设计, 有望显著改善WASM调用Web API的速度.
  • 内存模型非常简单, 以至于它甚至无法销毁掉申请的内存, 内存只能增长而不能缩小:
    https://github.com/WebAssembly/design/issues/1397
  • 尽管wasm很快, 但相比真正的本机代码, 它还是有很多的性能损失(本机代码的速度是wasm的1.75倍以上).
    https://nickb.dev/blog/wasm-and-native-node-module-performance-comparison/
    在少数情况下, wasm可能会比优化过的JavaScript代码还慢.
    根据Zaplib的测试, 在实际使用中wasm往往只比预热过的JavaScript代码快一倍, 因为实际项目并不总是大量使用CPU密集型操作.
  • 虽然WebAssembly支持将i64类型转换为BigInt(JavaScript不支持i64), 但WebAssembly本身并不支持BigInt.
    因此, JavaScript无法传BigInt作为参数, 如果要处理大整数, 则被迫传字符串, 然后由WebAssembly这一侧将字符串转换为自己的BigInt实现,
    这无疑会造成很多开销.
  • 当前导入WASM模块的方式不是跨平台的, Web和Node.js使用不同的导入API.
    有望在WASM支持作为ECMAScript模块使用时得到改进.
  • 只支持32位, 可利用的最大内存为4G.
    64位可能会在未来支持.
  • 文件体积很大, 一个用Rust编译出来的WASM文件至少也有10KB.
  • 无法零复制共享内存, 这使得很多高性能任务无法高效率完成, 例如发送ArrayBuffer或共享SharedArrayBuffer.
    https://github.com/WebAssembly/design/issues/1162
    https://github.com/WebAssembly/design/issues/1231
  • WASM的多线程目前处于提案状态.
    https://github.com/WebAssembly/threads
WASM采用了一种相当奇怪的交互方式, JavaScript与WASM之间的调用只支持传递数值类型(整数和浮点数), 不支持字符串等常见的高级类型.
这导致两者之间需要传递高级类型的数据时, 实际上需要共享一个缓冲区, 然后传递对应的指针(即缓冲区内的偏移量), 再由需要的一方将其视作对应的高级类型来处理.
举例来说, 字符串传递时传递的不是字符串, 而是传递共享缓冲区的指针和长度, 再由需要字符串的一方将其识别为字符串.
WebAssembly的内存指的是一块分配给WebAssembly的线性内存空间, 其本质是一块可增长的连续无符号字节缓冲区.
"线性内存"又称作"平面内存模型(Flat Memory Model)", 这被认为是接口最简单, 性能最好, 复杂度最小的内存模型.
JavaScript可以共享给WebAssembly可调整大小的ArrayBuffer.
像wasm-bindgen这样的工具会自动抽象线性内存来平滑JavaScript与WebAssembly的访问.
在WebAssembly里, 像函数指针这样的引用出于安全性/可移植性/稳定性等原因, 不能存储在线性内存空间中.
作为替代, 这类不可存储在线性内存中的数据被存储在"表(table)"里, 目前只有函数引用被存储在表里, 未来可能增加新的元素, 比如线程.
全局变量是在JavaScript侧创建的, 由WebAssembly使用的变量, 在多个WebAssembly模块之间可以共用.
https://github.com/WebAssembly/WASI
一个建立在WASM上的, 用于系统编程的接口.
本质上, 它是为了创建一个对任何可以编译到WebAssembly的语言都可以使用的系统库.
如果WASI能够流行, WebAssembly会发展为一种公共的中间语言, 编程语言不再以平台为编译目标开发程序, 而是只以WebAssembly为编译目标来开发程序.
毫无疑问, 这将彻底颠覆整个程序设计领域的生态环境.
这是WASM自己的垃圾回收提案, 用于在不移植虚拟机的情况下将依赖于GC的编程语言移植到WASM上.
这降低了让编程语言支持WASM的难度, 更好地支持WASM的平台无关性.
一种以S表达式表示的WebAssembly格式.
可以从wat文件生成wasm文件.
一般将其视作WebAseembly的"汇编代码".
一种以二进制表示的WebAssembly格式.
理所当然的, 体积相比wat格式较小, 因此是主要被使用的格式.
最受欢迎的WASM运行时.
第二受欢迎的WASM运行时.
最受欢迎的WebAssembly语言, 大部分WASM程序都是通过Rust编写的.
Rust生态环境中主要的WebAssembly CLI.
wasm-pack build 的默认输出结果是整个npm包, v0.11.2以后可以通过 --no-pack 选项阻止此行为.
JavaScript代码生成器, 当需要使用 js-sys, web-sys 等JavaScript环境的绑定时, 需要使用此项目.
https://github.com/rustwasm/wee_alloc
一个可选的WASM内存分配器, 注重于删除不必要的Rust基础设施来减小WASM模块体积, 但会影响运行速度.
对于只在初始化时进行动态内存大小分配, 之后就没有再进行分配的程序有用.
一个不自以为是的WebAssembly CLI.
用Rust的WASM前端Web应用框架.
有很多stars, 但性能不理想, 即使相比React都还有相当大的距离:
https://github.com/yewstack/yew/issues/5
Rust侧, JavaScript环境的绑定.
Rust侧, Web环境的绑定.
对 js-sys / web-sys 的重新封装, 提供更好的人体工学.
受欢迎程度仅次于Rust的原生WebAssembly语言, 但市场份额被Rust挤占得相当厉害, 份额从2022年开始大幅下降.
与TypeScript的区别:
  • AssemblyScript只有 null, 没有 any 和 undefined.
  • 不支持union, 只支持泛型.
  • 不支持对象字面量和数组字面量.
  • AssemblyScript使用自己的标准库.
  • 访问宿主环境需要宿主配合, 无法直接访问.
  • 非null数组的成员需要手动初始化后才能访问.
  • AssemblyScript支持运算符重载, 顶级装饰器.
  • 数组排序基于数值而不是字符串.
  • 缺乏反射, 包括 Object.keys 这样的方法无法在AssemblyScript里支持.
特点:
  • API与JavaScript高度相似.
  • 允许手动申请和回收堆内存.
  • 支持动态数组和静态数组.
  • 自动内存管理.
  • 缺少像Rust的wasm-bindgen这样的东西, WASM与JavaScript代码的沟通依赖于手动编写声明和设置导出, 用户体验极差.
  • 不支持传递任意JavaScript对象至AssemblyScript.
    https://github.com/AssemblyScript/assemblyscript/issues/1620
    在某种程度上, WASM anyref/externref特性的支持能解决此问题, 但该特性在AssemblyScript里仍处于实验阶段.
  • 相比Rust这样成熟的语言, 性能较差.
    在一些基准测试里, 差别可以扩大到2倍.
  • AssemblyScript还未实现闭包.
    https://github.com/AssemblyScript/assemblyscript/issues/798