如何看待 WebAssembly 这门技术？

千姿百态

如何评论浏览器最新的 WebAssembly 字节码技术？

原文地址：https://www.zhihu.com/question/362649730

清风寡欲

方向是好的,但目前来说webassembly非常鸡肋.
对于性能上的优化，如果说“达到原生水平为标准”，那么单核的性能可以说基本逼近到50%~80%，多核性能仍然有明显差距，为了综合测试其大致性能，我前段时间有专门使用了WebAssembly写了一个CPU跑分程序并和本地二进制编译后的程序进行比较



Webassembly版CPU Rank



原生二进制版本CPU Rank

你可以在下面的链接中在线测试一下，手机跑分大约在800-1500分左右，PC目前看到的最高分是3000多，手机仅支持Chrome浏览器，不支持国内魔改的那堆妖魔鬼怪，分数只做了一个大致评估，不能说100%准确，和浏览器和设备当前状态都有关系，参考参考就好。
https://www.painterengine.com/main/instances/instance2021122401/index.html之所以鸡肋，主要是WebAssembly的权限问题实在卡的太死了，当然出于浏览器对安全的考虑，这实在是一个鱼和熊掌不可兼得的问题。
首先是文件系统几乎是残废的，资源必须打包在一块上传，并且是readonly的，这导致很多的配置资源比如数据库无法动态的更改，当然有一个emscripten支持挂载的虚拟文件系统。但你完全无法知道这些数据搞不准什么时候就没了（默认的MemFs刷新一下就没了,NodeFs则是薛定谔状态）,当然最主要的是无法直接访问本地文件系统,这导致很多的生产力工具根本无法直接落地.
然后是网络,没错,webassembly目前提供的网络socket基本是由websocket模拟的,UDP这个协议注定就是不支持,要支持必须用中间件做模拟(那我为什么不直接发布二进制程序呢?),基本注定了很多高时延要求的网络游戏,工控程序的开发和移植绝对有一堆问题,可以说这点不解决,很多的应用基本不会考虑webassembly平台,同时,TCP也不是真正的TCP,仍然是websocket包装后的连接,意味着很多人梦想中的本地开发后直接移植到web端跑,抱歉,不行.你得重写服务端~,当然,我也可以理解为什么要这么干,如果真直接开放了上面的权限,某天你打开一个网页,黑客通过反向连接不直接可以内网漫游了么.
再说说上面这个跑分程序用到的多线程,你想开多线程?这个功能很基础吧,抱歉,不行呢,首先启用多线程需要SharedArrayBuffer的支持,因为某个CVE.导致Chrome后来不直接开放它的权限,你必须在对应页面http的header上添加
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin这样就行了么?当然不行,你的网页必须基于https而不能是http,否者仍然不予支持,所以你还得去搞个整数把网站的链接升级到https,当然,仍然是出于安全的考虑.就这个我和muastar都折腾了一个下午.
我觉得安全这块,完全可以弹出一个提示窗来提示用户是否能给予开放更多的权限，同时自己承担相应的风险.现在来看,实在做的过于的紧张了,也让很多的应用根本没有施展拳脚的余地.
我发现网上讨论webassembly应用的相当大一部分都是"愿景",实际根本没有实际去开发应用过,而实际上手开发,就会发现一堆问题导致很多的功能实现根本无法落地,现在的webassembly端的环境,我更愿意说他是一个半成品,所以目前我也只能说:方向是好的,但要达到吹爆,就完全不行呢.

队长是我

最近有很多碎片化时间，读了下wasm的规范，也实现了一个完整的wasm的VM，谈下自己的看法:

wasm类似于一个跨平台的C语言，但是出于安全因素加了一些限制，比如不能内嵌汇编，不能任意跳转，其抽象
程度类似于C语言，所以VM,JIT,AOT都很好做，而且做的也可以很轻量级。

先不考虑web相关的东西，wasm 的价值主要有以下几点：

- 它是一个标准，解析起来也比较简单，能跑wasm的设备会比较多，甚至包括大量低端的IOT设备

- 分发比较容易，reachability很高。

由于跨平台特性，一旦生成了字节码以后可以预计将来十年，二十年依然可以跑起来。
这一点其实很重要，现在的软件构件系统太复杂了，一旦软件的作者不再维护了，已有的软件大概率就被废弃了。
编译输出成wasm以后，它的软件寿命会大大延长。

- 安全。因为前面提到wasm的运行时实现起来很容易，所以相对定制一个也比较轻松，这样可以做一些细粒度的控制。
比如只允许部分网络，文件访问等。

wasm对于web 我觉得不会削弱javascript的生态，反而会增强这个平台的生态，以前一些web不能做的，现在借助wasm
也可以做了。当然也有些不利的因素: 比如原本有simd.js proposal,因为wasm的出现simd指令只能在wasm上实现了，
但总的来说利大于弊。

长长的路

怎么看待？当然是看好，应该说，对于一切在垂直领域有效率提升、且业界有案例支持的技术，都应该看好。
<hr/>如果从 2017 年浏览器纷纷开始以实验性的方式，支持 Web WebAssembly 功能来看，在浏览器使用非 JavaScript 来完成计算的风已经吹了五年了。
不过，感受到 Wasm 生态真正发力的是近三年。而且不仅仅停留在“前端”范畴。
大环境的变化，让行业生态中音视频、云计算、物联网有了更广阔的市场，以及在降本提效上更高的追求，此为天时。如果说 Wasm 生态中的 C 位是 Mozilla，那么去年在 Mozilla 裁员事件出现后，他们迅速成立 Rust 的基金会，以保障 Rust 开发团队能够独立、稳定地运行，保护 Rust 以及周边项目的持续发展，为生态提供土壤，此可谓地利。
天时地利，只待人和。
国内外经济环境均有了前所未有的变化，在少了不少外部资本诱惑之后，能够感受到这几年来，基础技术设施的蓬勃发展，这里面少不了各种优秀的工程师正在将注意力从“业务”，逐步转移到“技术”上。目前 Wasm 王国在它的一等公民 Rust 高速发展和推动下，已经吸引了不少其他语言生态、知名商业公司的注意力。至于何时爆发，我个人认为，只是时间问题。
不过需要注意的是，没有技术会是银弹，只有把技术放在适用的场景下才能达到事半功倍的效果。
<hr/>适合 Web Assembly 的场景，其实蛮有限的，远不如传统语言的运行范围广阔。
近几年来，业界公开表明已使用它的场景有哪些呢：

• 做在线设计工具的业务场景，比如 Figma：早在 2017 年，Figma 就借助这项技术进行了产品优化，《WebAssembly cut Figma's load time by 3x》，他们的工程师 Rasmus Andersson 也从比较底层的角度分析了 wasm。
  
• 复杂的在线 IDE 产品，比如 vim.wasm：在 2019 开始正式进行开发的 基于 wasm 的 VIM 完整移植版。使用 Web Worker 和 SharedArrayBuffer 解决了在浏览器端 JS 和 wasm 进行数据交互时的延迟问题。
  
• 云计算场景的边缘计算，比如 Cloudflare、fastly ：《WebAssembly on Cloudflare Workers》、《Compute@Edge》
  
• 云计算场景网关能力扩展，比如 Envoy & istio、蚂蚁金服、MegaEase、ApiSix：《Istio1.5 & Envoy 数据面 WASM 实践》、《WebAssembly 在 MOSN 中的实践 - 基础框架篇》 、《用 Easegress + WebAssembly 做秒杀》、《云原生网关 APISIX 核心流程源码分析与进化方向思考》
  
• 在线音视频处理，比如 Zoom、声网 agora、字节跳动：《Zoom on Web: WebAssembly SIMD, WebTransport, and WebCodecs》、《How WebRTC & WASM are opening new opportunities for web apps》、《如何通过 WebAssembly 在 Web 进行实时视频人像分割》、《Bilibili - WebAssembly在多媒体场景的实践与思考》
  
• 高性能的复杂在线数据可视化，比如 perspective：https://github.com/finos/perspective
  
• 浏览器端的前端加密场景，比如coupang ：《WebAssembly 在性能及加密场景的深度探索》
  

如果将上面的场景进行归纳，我们可以看到，在浏览器端、云计算、嵌入式方向，WebAssembly 的优势还是比较大的：

• 用比较低的代码量来扩展现有业务能力（云端、浏览器端）
  
• 充分使用客户端的计算能力，节约云服务器带宽和计算资源成本（浏览器端）
  
• 利用 wasm 高性能计算方面带来的优势，解决复杂的计算的执行效率问题（可视化、通用计算场景）
  
• 快速复用其他语言技术栈道能力，借助容器化的思路快速迭代产品（云端、浏览器端、嵌入式）
  
• 使用更流行、易于开发维护，或者贴合自己团队的语言来进行产品迭代（嵌入式）
  
• 前端敏感内容的加密处理（浏览器端）
  
• 群里还有朋友说他们在游戏领域也有使用，效果还不错。（游戏）
  

<hr/>看到这里，如果你想快速的、低成本上手，可以参考专栏里最近更新的一篇内容折腾下，不需要 Rust 基础，不需要折腾 WAT 、不需要折腾环境，基本跟着一路 Next 就能开启 Wasm 世界的大门了：
苏洋：使用 Docker 和 Golang 快速上手 WebAssembly<hr/>最后，个人认为目前的 Wasm 领域的生态还有待完善，像极了十年前的前端生态。Wasm 和前端技术一样，出现和发展不是为了取代谁，而是为了让解决事情的路径多一条，让已有多技术产品效能更高。我始终相信会出现那么一批人，和十年前的老前端们一样，将它的生态完善起来的。

希望，能够帮助到徘徊在这项技术前无从下手的你，并为你打开一扇新的大门。

继续前进

现代浏览器的功能早已不局限在简单的页面呈现，这就是为什么WebAssembly会诞生的重要原因之一。为了将沉重的任务性能提升到一个新的水平，在JavaScript和机器代码之间搭建了一座桥梁，由此才有了——WebAssembly。
<hr/>从理论上讲，这项新技术最终实现了让我们可以编写机器代码以在浏览器的虚拟安全沙箱中运行，甚至升级后的WASM被设计为其它语言的编译目标，允许将服务器端代码（例如C或C ++代码）编译到其中，同时在浏览器中执行。
业界一度认为它潜力巨大，但实际上在WASM发布3年后就在不那么热了，可以从几方面思考：

WASM的设计初衷是什么？
1 . WASM的出现绝不是要让它成为一门新的编程语言，正相反，它被规划并设计为一个编译目标，允许C的开发者编译其代码，并在浏览器上运行。
2 . WASM旨在提供高度优化的网络计算能力，并被期待去打破JavaScript在既有环境中的垄断（尽管JavaScript是一种很不错的语言，但其在设计之初就没有考虑到性能上的问题）。
3 . WASM并不是被拿来实现网站优化的，而是尝试在运行以下这些繁重任务时，将浏览器（以及服务端运行时，例如Node.js）的运行推升到一个水准：

• 视频编辑
  
• 游戏开发
  
• AR / VR实时应用
  
• 音乐编辑和流媒体
  
• 加密
  
• VPN
  
• 影像辨识
  
• 以及，其它的一些繁重的任务
  

可以这样说，那些你可以想到的、原本工作量巨大的web代码编译以及性能调试，回到设计初衷上，都可以被用来反向证明WASM的价值。

WASM的使用方向？

• Tensorflow.js：是的，就是那个Tensorflow，那个是把AI和ML带给JS开发人员的库，在添加了WASM后端支持后，Tensorflow一直致力于实现更多的模型，效果如何？与纯JS版本相比，这些模型性能平均提高了10倍。
  

https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html

• Unity：另一个很牛很牛的技术大厂牌，最最重要的游戏开发引擎之一，它能够将你的项目导出与Web相兼容。从2018年开始，该过程通过编译为WebAssembly来完成——在Unity上的应用成为了高效利用WASM技术的一个强大示范；游戏开发人员不再需要为Web做代码编译、更不需要去摆弄JS，他们只需要专注于编写用于支持游戏运行那部分代码，然后，其它交由编译过程去处理并完成。
  

https://connect.unity.com/p/unity-2018-2zheng-shi-zhi-chi-webassembly

• AutoCAD web app：你并没看错，Autodesk的web cad应用确实已部分被“移植”，它们使用了基于WASM编译的C ++代码。对于WASM来说，在AutoCAD上的应用是其所迈出的重要和极具潜力的一步，因其重新利用了为完全不同的平台编写的代码（且是用完全不兼容的语言）使用到现代浏览器中。
  

https://www.autodesk.com/products/autocad-web-app/overview?plc=ACDIST&term=1-YEAR&support=ADVANCED&quantity=1

• Google Earth：不是所有人都了解，至今Google Earth已经发展15年，它曾经是桌面应用程序，现在有了WASM，产品团队通过把部分旧代码编译为WASM（类似于Autodesk在其CAD应用中所做）并将其部分移植到了Web中，这是个不小的成就，无疑，这又给WASM“履历”中加分了。
  

https://earth.google.com/web/

• Blazer：http://ASP.NET框架的一项功能使我们可以构建直接在浏览器上运行的各种交互式UI；通过Web Assembly释放的“魔法”，.NET代码可以直接在浏览器上执行，这样我们可以充分利用C＃编写的服务器端代码（对于Web UI）的全部优势。
  

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

• yew：是否曾考虑过将Rust用于Web应用程序？现在，我们要感谢Yew和WebAssembly给我们带来的多一种“可能性”——你不仅可以将Rust用于UI，而且此框架还提供了一个多线程环境来工作。该项目尚未投入生产环节，但是无论你是对Rust很狂热还是有兴趣，都可以持续关注下。
  

https://github.com/yewstack/yew
好吧，无论上面这个名单延展有多长（至少还有100多个厂牌），但仅就Microsoft、Unity和Google就绝对表明WASM这一技术的潜力了～

好了，需要聊聊为什么WASM有点凉了。
其实原因和技术无关，答案是：营销不给力。
令人印象深刻的技术/项目到处都是（瞅瞅github你就知道），但这其中有些技术/项目终会销声匿迹，重要原因是“无法吸引真正的使用者“，WASM大概率正在重蹈覆辙——
WASM的确是有用的技术，问题是：

开发者很在意它吗？

WASM其实并不适合Web开发者，原因是Web开发者自然知道如何使用JS，并且很了解自己日常已有的工作量，为什么要费力混入WASM去把问题搞复杂？
WASM更适合开发一个计算密集型应用，这意味着不会是个本机应用，大概率是游戏、VR/AR应用、虚拟机等等，又因为把技术推向极限不是每家公司的目标，这样，WASM的蛋糕再次被往小了切。
WASM会被“扶正”成为一门Web编写语言吗？
要强调的是，WASM并非由开发人员去编写，而是允许开发人员借助C、Go或其它语言编写，并使该逻辑在浏览器上工作。
WASM离被实际应用到Web项目中还有很长的路要走，更别提被用来支撑应用逻辑编写。
最终我认为它不会很快取代JavaScript，不过，由于迁移到云的趋势有助于打破现状，对于WASM的社群人数增长会有一定推动力。

关于“如何看待 WebAssembly 这门技术？“，作答完毕。

继续前进

我不太认为 WASM 是值得前端 all in 的技术，概括地说几点问题：

• WASM 运行时性能在原理上就是受限的，跑不到真正的汇编级别。Rust 编译到 WASM 后有不小的性能损失，极致优化后的 JS 不会输它多少——所以真实世界 benchmark 里，WASM 往往并没有压倒性的优势。不要以为这是因为它不够成熟，而是原理上就决定了。
  
• WASM 不是计算密集型应用的唯一救星。对于真正高度并行且精度要求不高的算法，用 WebGL 做 GPU 加速往往更快，然后才是 WASM 这种 CPU 上运行的字节码。
  
• 嵌入 WASM 函数到 JS，未必就能提高性能。JS 自身的 JIT 已经内置了机器码级的优化，你手动把算法重写成 C，未必比 Happy Path 上的 JIT 更快。
  
• JS 与 WASM 的双向调用并不像 Python 嵌入 C 那么简单，你不能随便把 JS 里的对象直接交给 WASM，至于喊着打通一切运行时类型的 WASM Interface Types 才刚有了个影子。
  
• 主流前端 UI 框架未必值得用 WASM 重写，它们的场景是 IO 密集的，换语言彻底重写的投入产出比很难说。按相同逻辑，既然 JVM 比 V8 快，你愿意用 Java 重写 Node 服务吗？
  
• WASM 生态跟前端工具链基本无关，它的 Emscripten 工具链搞的完全就是 C++ 系语言交叉编译，从编译器到依赖库都完全跟 JS 这一套无关。
  

以上六点都不是信口开河，每个结论我都详细论证过了。欢迎感兴趣的同学阅读我的这篇文章：
一个白学家眼里的 WebAssembly我不是说 WASM 不好，它非常适合把原生应用搬到 Web 上——编译出一个 C++ 应用的 Web 版就像把它编译到安卓一样，换一套工具链就行。但是，不要把 WASM 当作一切前端性能问题的灵丹妙药，更不要觉得把你的 JS 随便用 Rust 重写一下就能快几倍。
还是那句老话，没有银弹。