• 中文
    • English
  • 注册
  • 查看作者
  • 社区分裂、应用争议,5年都没火起来的WebAssembly “炒错”方向了?

    WebAssembly(Wasm)已经诞生了五年。在云原生领域,这段时间并不算短,毕竟堪称业界标准的Kubernetes也才出现八年。作为一种供基于堆栈的虚拟机使用的二进制指令格式,Wasm想让开发者实现“一次构建、随处运行”,因此被广泛认为具有改变游戏规则的潜力。

     

    但 HTTP Archive 发布的 2022 年 Web 技术报告显示:“WebAssembly 的应用还不够广泛,我们并没有发现使用量的增加,反而看到了小幅收缩。”

     

    社区分裂、应用争议,5年都没火起来的WebAssembly “炒错”方向了?

    WebAssembly 语言使用情况,图源:

     

    这份报告基于对 800 多万个网站的调查,这些网站是谷歌 (用户体验报告)所分析的网站。据 Netcraft 的 显示,有超过 11 亿个网站,但其中许多网站并不活跃,因此这份报告仅针对那些最活跃的网站。

     

    需要注意的是,通常情况下,网络爬虫并不会登录 Web 应用,它们只能浏览网站上的公开内容,因此这项调查并不包括那些使用中的 Web 技术应用。当涉及更加以应用为核心的技术时,则可能会导致结果失真,包括 WebAssembly。

     

    尽管如此,在报告中撰写 WebAssembly 分析的技术博主 Colin Eberhardt 并没有放弃, ,网页中的 Wasm(编译的 WebAssembly 代码)数量很少:

     

     

    对该 Wasm 的分析表明,到目前为止,最大的份额是亚马逊 IVS(互动视频服务),这是 AWS Chime 服务用于优化视频通信的库模块。这并不代表开发者有意为之,仅仅是使用这种特定的AWS 服务的结果。也许更重要的是,微软的 Blazor 框架出现在最普遍 Wasm 使用的第三位,因为这将是开发者为特定网站而编写的代码。

     

    社区分裂、应用争议,5年都没火起来的WebAssembly “炒错”方向了?

    流行的 WebAssembly 库,图源:

     

    Eberhardt 认为,目现在还没有充分的理由去使用 WebAssembly,原因是 Wasm 代码不能替代 JavaScript,它只能作为 JavaScript 的补充。他认为,WebAssembly 的未来可能不是“作为一个小众的 Web 技术,而是作为一种在其他平台上完全主流的运行时”。

     

    为什么Wasm就一直火不起来?虽然有各种各样的原因,但Wasm自身生态系统的震荡不定却是难辞其咎。

    AssemblyScript的分裂

    最近几周,Wasm 生态的问题再度暴露无遗。

     

    AssemblyScript 是一种专为 Wasm 在浏览器中使用所设计的语言。最近,其宣布不再支持WASI——一种易于在浏览器之外使用的Wasm系统接口。目前还不清楚 AssemblyScript 到底为什么要放弃 WASI,但理由大概率还是在技术和观点层面有分歧。

     

    WASI 项目提案侧重于Wasm与Rust、C++等语言的互操作性,相对牺牲了JavaScript,而这最终会损害AssemblyScript(具有TypeScript特性)的利益,并迫使其在项目层面做出重大更改。

     

    AssemblyScript 的作者们通过线上文档 提出,W3C 的 WASI 子团队“扩大了职能范围”,其“设计的自有提案……会与既定或当前设计的Web标准相竞争。”

     

    除此之外,作者们还表示,“我们的代表受到了系统性歧视,没人在乎他们表达的担忧和反对。”

     

    再者,AssemblyScript 还将矛头指向 Bytecode 联盟。该联盟拥有多家重量级技术成员,包括亚马逊、谷歌和微软三大云服务巨头,专司为Wasm和WASI提供支持。

     

    AssemblyScript的作者们警告称,“我们想提醒公众,应密切关注潜在的反竞争行为。有必要的时候,甚至应该要求反垄断立法的介入。”

     

    这里再介绍一点相关背景:有数据表明,人们对于AssemblyScript的关注正在下降。在Scott Logic今年6月发布的《2022年WebAssembly现状调查》中,只有17%的受访者表示有意在未来大量使用AssemblyScript,比例远低于2021年调查时的26%。

     

    虽然这一结果可能跟Wasm项目范围扩大而导致AssemblyScript用量稀释有关,但必须承认,当前对开发者吸引力最大的仍然是 Go 和 JavaScript 那几种热门语言。AssemblyScript在其中的确缺乏竞争力。

     

    至于反竞争指控,虽然 Bytecode 联盟的成员名单确实有利益集团绑定的嫌疑,但这更多是种对强势技术趋势的主动参与,未必代表各方打算强行通过有利于自己的议程。

     

    Bytecode 联盟成员、边缘云平台厂商 Fastly公司首席技术官Tyler McMullen表达了他对这波冲突的失望之情。

     

    McMullen强调,症结其实就是“一个非常细微的技术细节——是否允许在客串中包含某些无效代码点。” 他指出,这个“技术细节”的决定并不是某个人或一家公司说了算,“提案经过了整个行业中很多专家的审查和投票,包括各家主要浏览器开发商。”

     

    开源平台工具厂商Suborbital工程总监、Grain编程语言联合缔造者Oscar Spencer也有类似判断:

     

     

    推广Wasm的力量来源并非用户

    鉴于这样的冲突和分歧,整体软件社区找不到使用Wasm的理由和必要性。

     

    尽管Wasm最初专门为浏览器所设计,但现在这类用例似乎不是特别重要。大家更多的关注和兴趣主要集中到 Wasm在浏览器之外的潜力,例如在服务器上使用(有望与Docker结合使用,甚至直接替代Docker),或者通过代码捆绑实现跨多应用程序运行。

     

    Spencer对于Wasm的发展历程也有自己的看法:

     

     

    但这并不是说Wasm在Web世界失去了生命力。相反,它找到了最适合自己的利基市场:强调速度和性能的场景。

     

    全球开源咨询公司 Igalia 软件工程师Andy Wingo提到,他最近刚刚为某受众庞大、基于浏览器的电子表格做了一个项目。在此项目中,他希望“提高JavaScript与Wasm之间的字符串转换效率。”在他看来,这类项目属于“大型利益相关方与浏览器开发商间的一对一合作”,也是Wasm最常见的应用环境之一。

     

    这也再一次提醒我们,虽然新兴技术总能引发炒作热情与激烈讨论,但其最终命运仍然要由非常具体的用例来决定。

     

    Wingo还提到,Fastly和电子商务平台Shopify等企业也在使用Wasm,而这两家公司之所以选择Wasm,是因为供应商们喜欢用。“所以,推广Wasm的力量之源并不是用户,而是先由平台所有者的意愿决定,再一步步传导至用户群体当中。”

     

    Wingo的观点跟McMullen可谓不谋而合,即:并不是所有平台都支持Wasm,“之所以无法广泛支持,是因为Wasm难以嵌入。而导致难以嵌入的原因之一,就是Wasm缺乏标准的交互模型。”

     

    因此,尽管大家普遍对Wasm的速度和性能优势赞不绝口、给予关注,但在实际应用方面仍存在很大的争议甚至是分歧。

     

    局外人眼中的Wasm

     

    对局外人来说,Wasm是种相当奇怪的语言。

     

    首先,这种语言最初的用途定位跟后来真正让它声名鹊起的用例几乎没有关系,但在脱离浏览器的过程中,Wasm也确实变得更加流畅灵活。于是问题来了:现在的Wasm,还是当初设想的那个Wasm吗?

     

    也许正是存在这个问题,才导致Wasm在标准制定方面遭遇困境——由于缺乏明确的共识,不同群体都在朝着自己心中正确的方向发力。

     

    这对用户和潜在的Wasm开发者来说当然不是好消息。Wingo表示,“人们其实都或多或少知道Wasm的一些特性,只是不清楚为什么会这样。”

     

    但这也未必是坏事,反而凸显出Wasm面临的最大挑战,即如何将其在浏览器中安全高效运行任意代码的能力在制定项目中成功应用。只要解决这点,Wasm必然能够一飞冲天。

     

    Spencer对此表示赞同,并在采访中坦言大多数尝试Grain的用户其实是想借此探索Wasm。其实很多用户都“愿意在Wasm当中做一些尝试”,只是发现跟Rust或C++等其他语言相比,Wasm真的让人望而生畏。

     

    虽然编程语言的实质就是帮助人们触及那些无比复杂的逻辑和事物。但有趣的是,Scott Logic调查给出的数据,其实跟Spencer的观点相互矛盾:

     

     

    看起来,虽然Grain是专门为了降低Wasm门槛而生,但有能力解决复杂工程问题的人们也完全不抗拒这种更简单的方法工具。

     

    Grain项目的主页上写道:很多语言都有着绝佳的设计思路,但最终却因为过于深奥难学而致人放弃,无法建立起庞大的技术社区。Grain希望为这些思路带来新的活力,通过易于使用、理解的方式加以呈现。

     

    这么看来,Grain 存在本身也许正是Wasm生态系统的最大短板——这证明Wasm没能用简单易行的方法,帮助开发者们了解如何用它解决问题。

     

    互联网上关于这个问题的讨论很多。

     

    在Quora上,IT支持软件厂商Licorice的CTO Julian Jensen就回答了Wasm是否难以上手的问题。

     

    Jensen的看法可能有些偏激,但他的基本判断是对的:虽然很多人都对Wasm抱有兴趣,但Wasm的生态系统始终没能提供一种简便易行的学习方式。

     

    更重要的是,这也凸显出Wasm面临的一大核心挑战:如何在帮助广大开发者降低理解门槛的同时,确保Wasm自身的很多特性不致因过度简化而失去意义?

     

    WebAssembly组件模型

     

    于是问题又回到了标准化上。没有标准化,我们就永远无法把大肆宣扬的各种技术期望变成现实。目前,最有前途的方案就是WebAssembly组件模型。

     

    根据Spencer的说法,就是因为负责这项工作的小组始终达不成共识,才“真正阻止了……Wasm的全面崛起。”McMullen也回应了这种说法,表示组件模型对于保障“标准交互模型”至关重要,甚至直接决定着Wasm能得到多少支持。

     

    组件模型的意义在于简化Wasm在浏览器以外的使用方式。通过为不同事物间的协同运行编写出规则和规范,组件模型应该能够消除Wasm实际应用中的不少认知负担(和额外代码)。

     

    “组件模型的关键,是让代码得以跨语言和生态系统实现安全高效共享与连接。除此之外,组件模型还有望帮助Wasm建立起睽违已久的代码公开接口。只有通过更高级的方式定义这些接口,我们才能就跨语言和平台的工作模式和标准达成一致。”McMullen表示。

     

    尽管组件模型对整个Wasm项目都具有重要意义,但W3C WebAssembly社区小组仍在讨论其中的具体细节,而且整个过程可能还需要一些时间。

     

    Spencer注意到,尽管大家的出发点都是好的,但由于民主化程度过高,人们其实是在相互内耗、把大量时间浪费在了对于小细节的争论上。

     

    那么,距离最终定稿还有多久?Spencer表示,他觉得具体实施可能要等到2023年春季去了。McMullen则强调,目前的延误其实有其道理:

     

     

    尽管进展缓慢,但Spencer和McMullen对这项工作的重要意义都给予了充分肯定。Spencer坦言,Wasm的命运由工具链决定,毕竟开发者最关心的就是一种语言有没有完备的工具链。

     

    Wasm会落入专有陷阱吗?

    脱离浏览器之后的Wasm,其未来命运似乎就取决于组件模型能否一战成功。但在此之后,Wasm还须着眼于更广泛的软件市场。

     

    Wingo预计,届时会有风险投资入驻这个领域,其中一些可能愿意遵循标准,但也有一些可能想让Wasm走向专有锁定。

     

    也许Shopify和Fastly等公司的当前贡献,就是在为后续的专有演变做铺垫。唯一的问题就是,供应商们能不能把Wasm轻松打包成边缘计算解决方案。只要Wasm项目的开发门槛不高,就会有更多工程师熟悉这项技术,最终影响供应商对于Wasm类方案的设计思路。

     

    而且Bytecode联盟也未必就有垄断Wasm的想法。McMullen更愿意将联盟视为Wasm的“元生态系统”。“我们绝不会在Wasm之内搞一言堂。我们所需要的不只是一种语言,更是多样性的平台和行业。”

     

    结束语

     

    无论风险投资方们怎么谋划、无论项目各种fork背后的核心开发团队选择哪条路线,Wasm本身永远是一项重要且极具价值的技术,完全有能力在正确的场景下改变游戏规则。

     

    所以,最大的难题其实就是,怎么按捺住激动的心、颤抖的手,忍着别把Wasm的影响力和价值抽象化成特定某一种软件工程工具。

     

    Spencer强调,归根结底,Wasm只是一种编译器目标、一种实现细节。如果Wasm能在未来几年内把自己的问题解决好,那它就会从流行词转化为润物细无声的开发方式。

     

    这样的未来看似简单,也是Wasm最合理的发展目标。但纵观整个发展历程,要让这个目标真正落地,还需要解决大量争论、探索、实验和共识。

     

     

    参考链接:

     

     

    链接

     

  • 0
  • 0
  • 0
  • 211
  • 请登录之后再进行评论

    登录
  • 任务
  • 实时动态
  • 发布
  • 单栏布局 侧栏位置: