[译] 关于 WebAssembly 你应该知道的 7 件事

Posted 2021-04-25 微wx笑

粗略翻译, 推荐看原文
https://auth0.com/blog/2015/10/14/7-things-you-should-know-about-web-assembly/

---

了解 WebAssembly, 了解 Web 的将来

这里不支持链接，代码展现也不好，建议看原文。

介绍

如果你不熟悉 WebAssembly 后面的概念, 可以读一下:
ArsTechnica 的 Peter Bright 写的优秀的论文,
或者是 Brendan Eich 在他的个人博客上写的公告文章

考虑到本文的目标, 这里加上个简短的术语表:

• 源码(Source code): 开发者写的.

• 编译器(Compiler): 一个应用程序, 用于把源码转换为汇编,字节码或者机器码
  (任何其他的应用程序或者硬件可以运行的)

• 汇编(Assembly): 低级的类似源码的语言, 针对特定机器或特定应用程序

• 字节码(Bytecode): 低级的二进制的代码形式, 可以被其他应用程序执行

• 机器码(Machine code): 代码的二进制形式, 可以由硬件直接执行

WebAssembly 的目标是 Web 的字节码. 未来的开发者会这样使用 WebAssembly:

1. 开发一个应用(源码用任何可以编译到 WebAssembly 的语言)

2. 用编译器把源码转换到 WebAssembly 字节码(可能只要的话转化成汇编)

3. 在浏览器加载字节码并执行

   
   

真相 1: WebAssembly 不是 javascript 的末日

已经说过的再说一次: JavaScript 依然会继续

得益于 Web 平台的增长, JavaScript 已经成为开发者和工具链的通用语言
WebAssembly 不会改变这一点
WebAssembly 想要替代的是目前 JavaScript 被强行用来占据的地方:
可以用作编译目标的底层的代码表示形式
As more and more languages and platforms begin to target the web,
随着越来越多语言和平台以 Web 为目标, JavaScript 有着更多的压力
浏览器提供商为此尽可能加入缺失的功能
其中一些功能在已经很复杂的 JavaScript 语义当中不能运作地很好
WebAssembly 就是为这个问题提供答案:

• 它从一开始就被设计为编译目标

• 它将得到所有主流浏览器提供商的支持

• 它可以根据需要任意地偏离 JavaScript 原有的语义

WebAssembly 对于 Web 来说是对 JavaScript 很有必要的补充

真相 2: WebAssembly 由 ASM.js 和 (P)NaCl 背后的团队开发

如果你过去几年跟进了 Web 的发展你就知道 WebAssembly 目标很有难度:
为不能轻易映射到 JavaScript 的语言提供一套统一的编译目标.
不仅仅从技术方面来说目标很艰难, 而且从标准方面来说也是困难的
Web 并不是由单一的提供商控制, 每一个改变都一定是联合的努力
幸运的是, WebAssembly 背后的团队知道这一点.
在 Mozilla, 一群专家开发者尝试通过 ASM.js 的形式提供答案:
用一个套 JavaScript 的子集作为编译目标
另一方面, Google 致力于 Native Client(NaCl) 和 Portable Native Client(PNaCl):
一套基于 LLVM 的 Web 的二进制格式
尽管每个方案某种程度上取得了效果, 但他们没有能的方所有问题提供满意答案
基于这个经验 WebAssembly 才浮现出来: 联合努力来提供跨浏览器的编译目标
WebAssembly 的未来看起来一篇光明

Fact 3: WebAssembly 会向后兼容

Web 的一个基础特性就是向后兼容性, WebAssembly 也不例外:
对于就浏览器将会有一套 polyfill. 而且, 它的原型已经有了
你可以在这里和这里看到它们已经在使用

Fact 4: WebAssembly 看起来不像 CPU 汇编

当听到"汇编"这个词你也许马上在脑子里听到"可读性差"这句话
幸运的是, WebAssembly 不是这样. 相对于其他底层代码表示形式,
或者大多数的二进制码, WebAssembly 描述的是抽象语法树(AST)
是的, WebAssembly 提供了高级的结构, 比如循环和分支
意味着可以直接写 WebAssembly, 或者反编译二进制文件
从而得到可读性比较好的 opcodes 或者指令
你可能会想"变量名怎么办?" WebAssembly 将支持编译后文件增加调试信息

这里举了例子 WebAssembly 的文本形式看起来怎么样
例子使用了 S 表达式(一种轻量级的 AST 表示):

 

  ;; Iterative factorial named

  (func $fac-iter (param $n i64) (result i64)

    (local $i i64)

    (local $res i64)

    (set_local $i (get_local $n))

    (set_local $res (i64.const 1))

    (label $done

      (loop

        (if

          (i64.eq (get_local $i) (i64.const 0))

          (break $done)

          (block

            (set_local $res (i64.mul (get_local $i) (get_local $res)))

            (set_local $i (i64.sub (get_local $i) (i64.const 1)))

          )

        )

      )

    )

    (return (get_local $res))

  )

这里看完整的例子

那么, S 表达式是最终的格式吗? 不是的, 目前没有 WebAssembly 的官方版本
还有另一个例子, 完全不用的语法, 你可能会更熟悉

export func main() i32 {  storeI32(temp, 0);  var i i32 = 0;  done: while (i < 10) {    i = i + 1;    if (i >= 7) {      break done;    }  }  return (i + ifelse(0, 1, 2) * 2) * loadI32(temp) + loadI32(scale); }

可以在这里看到

真相 5: WebAssembly 会扩展出 JavaScript 所没有的功能

WebAssembly 初步的实现目标是等同 ASM.js 的功能.
也就是说, 能用 ASM.js 做的, 等 WebAssembly 推出之后你也能做(做得更好)
第一个版本的可以期待的一个改进是更好的加载时间
WebAssembly 的二进制版本比起 ASM.js 的文本格式可以更快地解析
所以即便是最初的版本, WebAssembly 也能显示出改进
当前版本的 WebAssembly 叫做最小可行产品][mvp
将来的版本可以期待有这样一些改进:

• 完整的线程支持

• SIMD 类型和 intrinsics

• 零消耗的异常(栈审查和展开)

• 协成

• 动态链接

• DOM 集成

• 集成垃圾回收

• 尾递归优化

• 多进程支持

其中一些功能用 JavaScript 甚至纯粹的 ASM.js 都非常难实现
WebAssembly 基于这样一些需求开发的, 作为优秀的语言平台
将支持上边这些(以及更多的)功能

真相 6: Source Maps 帮助你在浏览器中轻松调试编译后的代码

编译目标语言的一个不足是调试常常变得更难
如果你使用过现在编译到 JavaScript 的任何语言,
你大概体会到过调试有多困难, 要靠记忆力把编译结果映射到源码
WebAssembly 的目标是成为其他语言优秀平台, 所以针对方案已经在做了
跟现今的本地编译器很像, WebAssembly 将允许二进制中存在调试信息,
以及 Source Maps, 用来高所浏览器和调试工具怎么样映射生成代码到源码
易于调试是作为 WebAssembly 规范的一部分的

Fact 7: 你不需要等到 WebAssembly 整个准备完成

尽管 WebAssembly 还在初期, 你已经能开始得到它将来能提供的好处了
在"真相 2"里我们提到. WebAssembly 来自于实现 ASM.js 和 NaCl 的多年经验
两套实现提供的所有的好处都将存在于 WebAssembly
如果你现在想要其中一些, 那么 ASM.js 就是优秀的一个方案
比如, Emscripten 现在能把你的代码编译到 ASM.js
如果你认为托付给 ASM.js 现在还不合适, 那么记着, WebAssembly 还只是初期
尽管这样, WebAssembly 首先还是将具备 ASM.js 的功能作为第一个目标
所以不要害怕把将来赌在 ASM.js 上
WebAssembly 开发被作为当前的解决方案的一套升级路线,
所以, 虽然可以开始想想未来了, 但并不意味着 ASM.js 不会得到支持
Hack away!

题外话: WebAssembly 和已有的类库

...

结论

过去几年出现了大量的框架, 编译器和其他类型的方案,
要把已有代码编译到 Web, 结果导致了社区当中的不少的失望
一方面, 不符合 JavaScript 语义和意识形态的功能在实施者的论坛里出现,
在 JavaScript 开发中当中激发了严重的问题
另一方面, 想使用已有代码的开发者, 想使用最喜欢的语言和框架的开发者,
发现他们被拦在 Web 外面, 或者面临着严重的调试门槛(以及其他问题)
即便现有方案如 ASM.js 和 PNaCl 做了大量工作减小这些操心,
然而到现在依然没有合适的跨平台的解决方案. WebAssembly 想解决这个问题
恰当的, 跨平台的, 跨语言的编译目标, 支持优秀的平台必要的所有功能
风险很高, 然而回报也非常丰厚. 背后的团队也很清楚这一点
WebAssembly 是开发者们长久以来期待的想法的演进, 它也是将来