搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > IVWEB社区 > 你跟WebAssembly的距离可能只差一次面基

你跟WebAssembly的距离可能只差一次面基

IVWEB社区 2020-07-30

Wasm一直在火的路上,从未停歇,W3C 成立了专门的 WWG 工作组来负责 Wasm 技术的标准迭代与实现,四大主流浏览器(Google Chrome、FireFox、Edge和Safari)已经全部实现 WebAssembly 技术在其 MVP 标准中制定的所有特性,C/C++、Go 和 Rust 等高级语言已经逐渐开始支持编译到 Wasm 格式。这一系列的发展和变化都说明了人们对该项技术所寄予的厚望,而今天有幸邀请到了国内第一本wasm书籍《深入浅出WebAssembly》的作者于航老师做客TLC2020采访室。

Q.WebAssembly 近几年非常火爆,对于前端同学有什么重大意义?

Wasm 起源于 Web,最初是 Google 为了能够取代 PNaCL 和 AMS.js,提出并创造的一种更加高效、更易于移植,且更加安全的字节码格式。因此,鉴于它拥有的这些特性,我们可以方便地在浏览器中借助它来创建性能更加卓越的 Web 应用。但目前,受限于 MVP 标准,作为前端同学,我们暂时可能还无法通过 Wasm 来构建可以直接与浏览器 DOM 进行交互的传统 Web 前端应用。但是 Post-MVP 标准中的一些提案已经处在了标准化的过程中,而一旦有了这些提案的帮助,Wasm 与 Web 前端将会走的更近。

相信接触过 Wasm 的前端同学应该都或多或少有这样的疑问:“我们是否可以用 Wasm 来改进诸如 React 和 Vue 等前端框架的性能呢?”就目前而言,我们可以使用 Wasm 来改写框架中的诸如“计算 V-DOM 差异”等涉及到密集计算过程的逻辑,但其实际带来的性能提升却可能并不会令人十分满意。因此就目前而言,改写的成本、ROI、稳定性以及兼容性也都是需要考虑的因素。但我相信,在不久的将来,待 Wasm Post-MVP 中的诸如 Reference Type 和 GC 等提案能够在浏览器中最终实现落地,那时的 Wasm 将会带给前端领域新的生机。毕竟,在 2019 年年底的 12 月份,W3C 已经正式宣布,Wasm 将成为除 HTML、CSS 以及 JavaScript 外的第四种 W3C 官方推荐使用在 Web 上的“语言”。

Q.很多同学都有通过您的新书《深入浅出 WebAssembly》来学习相关内容,但是它的更新迭代如此之快,如何快速跟上变化呢?何时才能达到相对稳定?

确实,一项新的技术在其初期发展时的变化速度甚至可以按“周”为单位来进行计算。但对于 Wasm 来说,我们其实要区分出它的“变”与“不变”的地方。首先,经常发生改变的主要还是 Post-MVP 中提案的设计和实现细节;偶尔会发生变化的是 Wasm 相关配套基础设施的一些对外接口和使用方式。其中,使用人数最多并且接口还不算那么太稳定的要属 Emscripten 了。Emscripten 的对外接口不稳定其实也是有一些历史原因的,因为早期的 Emscripten 主要还是用于生成 ASM.js 代码。虽然从某种程度上来说,Wasm 与 ASM.js 有很多相似的地方,比如运行时模型,但 Emscripten 在两者的实现细节方面却有很多不同。比如早期生成 Wasm 的方式是通过名为 Fastcomp 的编译器后端,而后期由于 Wasm 发展过于迅速,Emscripten 便改用了 LLVM 后端。再比如笔者两年前曾遇到过的,Emscripten Binding 对 C++ scoped-enum 的支持也并不算友好。等等这些其实都跟 Wasm 的迅速发展以及 Emscripten 本身的实现复杂性有着紧密的联系。

除了上面提的这些易变部分,那不变的部分是什么呢?首先就是 Wasm 已经发布的 MVP 标准。在这个标准中规定了 Wasm 的字节码格式、编码方式,甚至运行时模型等细节。而这部分内容我们可以基本认为其不会再被改变。因此,所谓“跟上变化速度”,我认为最好的方式是直接关注在官网列出的“提案进展列表”。在这个列表中,官方会及时维护所有与 Wasm 相关提案的当前所在阶段,以及它们在各浏览器中的落地实现情况。而作为开发者,便可以在第一时间去相应的浏览器体验这些新的功能。

总体来看,Wasm Post-MVP 标准中还有几个比较重要的提案暂时没有较大的进展,其中一个便是 GC。而这些提案将直接影响 Wasm 整个体系所具有的能力。在可预见的未来,Wasm 标准的真正稳定可能还需要 2-3 年的时间。但值得庆幸的是,这整个过程不是一蹴而就的,为了能够让 Wasm 以“渐进式”的方式得到发展,GC 这个大提案的实现实则是被拆分成了多个小提案,而每一个小提案的落地都将让 Wasm 标准变得更加完善和稳固。

Q.您编写 Wasm 虚拟机的初衷是什么?TWVM 相对于其他 Wasm 虚拟机有哪些优势?

当初在打算自己编写 VM 时的计划是想要构建一个“轻量级的、具有高可移植性且同时兼具足够高性能的 Wasm 虚拟机”。因为彼时大部分知名的 VM 都基本借助 LLVM 来构建 JIT 引擎,从某种程度上看,这会导致牺牲一定的可移植性,并且最终编译生成的目标二进制代码体积也会相应增大很多。而这也会导致某种程度上,不太易于将 Wasm 推广到更多特殊的应用场景中,比如嵌入式。

从另一方面讲,就目前 VM 这个领域的发展而言,其实已经很难单凭技术革新就将整个 VM 的性能提升到另一个更高的层次。大部分的 VM 也只能够以 fine-tuning 的方式来对性能进行调优,因此除了性能以外的其他“配套设施”就显得更加重要。比如,VM 集成的复杂度、文档的完善程度、社区的活跃度等等。而 TWVM 的设计目的其实也并不在于性能上的比拼,甚至可以说会通过牺牲一定性能来满足其他方面的要求,比如可移植性和目标代码体积。

除此以外,开发 TWVM 的另一个目的也是希望能够在未来方便地将 Wasm 应用到更多本地化的场景中。我们都知道,国内的市场其实与国外大不相同。从用户量到使用习惯都有着很大的差异。伴随而来的便是很多“独特”的技术解决方案,比如我们天天都在使用的“小程序”。因此,自己开发 VM 的一个好处在于,这使得在将 Wasm 与这些技术领域进行结合时可以更好地把控实现细节,甚至在某种程度上 VM 可以为这些场景进行特殊的适配和优化。

Q.如何看待未来 WebAssembly 与 Javascript 的关系?

其实关于这个话题,一个问的最多的问题就是“Wasm 最终会不会取代 JavaScript?”。这里我们还要再明确一下这个问题:“Wasm 会不会超过 JavaScript 成为浏览器上使用最多的一种低级代码格式?”。答案其实也比较简单:“至少目前在可预见的时间范围内,这个是不需要担心的问题”。首先,从技术角度来看,Wasm 与 JavaScript 两者其实是没有任何关系的。一个是静态类型高级语言的编译目标,另一个是动态类型的高级编程语言。其次,从 JavaScript 发展 20 余年的“垄断地位”来看,短时间内它也不是可以被完全取代的存在。再考虑到社区的体量、使用成本等因素,短时间内,Wasm 与 JavaScript 还只能够是互相补充的存在。

但是,毕竟 Wasm 在初期的设计定位时,并没有被考虑要求作为 JavaScript 的辅助角色。因此 Wasm 最终能够成为什么?这是另一个可以让人脑洞大开的话题。

活动推荐

在即将到来的 腾讯2020TLC 上,于航将在大会分享《WebAssembly and TWVM》。目前还有少量早鸟票,欲购从速。2020年9月5日,科兴科学园国际会展中心,不见不散!



版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《你跟WebAssembly的距离可能只差一次面基》的版权归原作者「IVWEB社区」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注IVWEB社区微信公众号

IVWEB社区微信公众号:ivweb_tencent

IVWEB社区

手机扫描上方二维码即可关注IVWEB社区微信公众号

IVWEB社区最新文章

精品公众号随机推荐