老外写了一篇为什么 WASM 流行不起来的文章。

[3dwelcome]

最近追赶潮流，学习把 Swift 移植到 web 开发的项目，https://swiftwasm.org/ 有提供完美操作 DOM 的 JS KIT 库。

感叹这是好东西啊，Swift 是目前最新的语言，去网上一顿搜索，最后发现 WASM 那么多年，技术早已成熟，市场却一直止步不前。

好奇查到去年这篇文章，https://blog.bitsrc.io/whats-wrong-with-web-assembly-3b9abb671ec2 ，里面的内容，就是说 Web 开发人群和传统语言开发人员，是完全不同的两批人。

会用 TS/JS 的前端，他们根本不需要 WASM 的存在。前端 NPM 已经有足够多的积累，能用 TS/JS 这把锤子，敲任何前端的钉子，他们并不需要 WASM 这项新技术。

感叹浏览器这些年的迅猛发展，早已把浏览器开发领域的内部世界和外部世界，隔离成了两个世界。

[Buges]

不止吧，wasm 目前还不完善，很多东西还在草案阶段，生态支持差，操作 dom 性能低下，而且带 runtime 的语言 runtime 太大等问题都没有解决。

[nomagick]

WASM 就好比浏览器的 ffi

ffi 这个东西早就成熟了几十年，也没见他们在各自的语言里扑腾出什么花来，
也没见 C 代码猛调 Java 函数，也没见 C++取代 Python 实现核心功能

不过前端和其他语言开发人员确实是两批人，这是前端行业的大问题，老是融入不了大家庭

[3dwelcome]

@Buges https://madewithwebassembly.com/ 上有项目大全，2019 年刚出来还挺火，google earth 和 doom3 移植之类的。

但是最近发展越来越颓废，很少有重量级项目出现。

前端不会去用，后端也懒得用。这就是 wasm 的尴尬处境。

[DOLLOR]

我觉得 wasm 更多的意义是把其他语言编写的基础设施移植到前端，成为前端的基础设施。形成“JS/TS 为主+其他语言为辅”的生态。

而 wasm 操作 dom ，用“其他语言编译成 wasm”，试图干掉 JS 的做法就本末倒置了。
实际上在 wasm 出现之前，就有“其他语言编译成 JS”这种技术路线，同样也没流行起来。

[3dwelcome]

@DOLLOR 前端同学想要通过 nodejs 写后端。后端同学想要通过别的语言写前端。

结果大家谁都不服谁，各占一片疆土，谁都不肯让步。

[murmur]

wasm 的意义在于 JAVA + script ===WASM===> JAVAscript

[Rwing]

看看 C#的 blazor ，出来几年了，已经纳入到微软的 web 框架 asp.net 中了，也有一些生产应用。

[3dwelcome]

@Rwing 这篇文章的内容，就是原来用 C#的后端，会通过 wasm 多一个浏览器发布平台。本来后台管理界面是 windows 上运行，现在浏览器里也能用。

但是传统前端是不会去改学什么 C#的，React/VUE 组件够多了，有这点时间学 C#，早就把需求给写完，去楼下喝咖啡了。

[aneostart173]

浏览器历史包袱太重啦，最早浏览器只是一个类似报纸的东西，谁知道后来变成了 OS 。
除非把 html 和 css 都扫进垃圾堆。

[juzisang]

生态也是一个重要因素吧，其它语言的各种 UI 库有现在的前端丰富吗？构建界面有前端简单吗，看国内国外一大票软件都用 Electron 来构建应用就能看出来，前端都去侵占其它语言构建软件的市场了。

[gjquoiai]

wasm 现在的场景似乎集中于高性能前端应用和插件系统，已经离传统前端很远了。不过前端应用复杂到一定程度肯定还是得用回 wasm ，毕竟也没别的提升性能的手段了。

[wobuhuicode]

wasm 主要是走错了门。需要密集型计算的 JS 做不了？那就交给后端呗，核心业务全部都是后端化。

[adoal]

互联网开发，糙、快、猛 rules all

[3dwelcome]

@gjquoiai "不过前端应用复杂到一定程度肯定还是得用回 wasm "

国内互联网一个前端项目就是三个月到半年，复杂前端属于极少数需求。

页面卡一般都是 DOM 过多，wasm 也解决不了。

就算有性能瓶颈，后期不是转 flutter ，就是用原生语言重新开发了。也没 wasm 什么事情。

[mxT52CRuqR6o5]

增加技术栈数量会增加维护难度，所以正常的工程上的考虑，如果是 js web 项目不会考虑再去用其他语言开发 wasm 项目子模块(顶多引入已经封装成 js 调用的一些 wasm 库)，要么就是完全不考虑 js ，上其他语言 all in wasm

[flashback313]

写 js 的人嫌 wasm 麻烦，写其他语言的人不想写前端

[gjquoiai]

@3dwelcome #14 emm 我只好说你说的这种项目当然不需要 wasm 。。。确实场景肯定很少，但真的到了这个程度也只有 wasm 可用。现在越来越多东西搬到了 web 上，从原型设计到在线文档，都是 wasm 的目标用户。

[duke807]

@wobuhuicode 錯，密集計算後端做的話，再乘以用戶數量，服務器根本抗不住，抗的住費用也受不了。

對性能有非常高要求的才會用 wasm ，所以大多是配合 C/C++，而且大多數可以直接用的 C/C++ 程序是 linux 程序，傳統前端會 C 和 linux 的人極少。

有調查顯示，有一半的 wasm 用戶是為了加密自己的代碼，傳統 js 代碼容易被分析。其中很多加密是為了做壞事怕被發現。

[duke807]

@duke807 一半以上

[HFX3389]

wasm 现在我觉得流行用在视频加密播放那一块，想把网站的视频下载下来结果看到 WASM 人都傻了...完全不会

[murmur]

@HFX3389 防的就是爬虫，个人用户录屏他怎么防，浏览器在牛逼也没法监测录屏和采集卡

[jim9606]

我理解 js+wasm 的关系有点像 python+C 的关系，js/python 主要做胶水，要求快速开发，wasm/c 负责有性能瓶颈的部分。wasm 相比起 native ，有更好的跨平台能力，同时能较为方便地移植原来 C 计算类库。
之所以需要 wasm ，是因为 js 引擎的性能还没有强到可以应对所有 web 应用的需要，这类需求对性能要求高一点点，但可以接受一定的性能下降换取跨平台能力。
比较典型的例子是视频解码，这个直接拿 js 来做，不是不可能，但性能会很难接受。wasm 做到让近 5 年的 CPU 可以流畅解码 1080p 级别的 AV1 视频就够了。

[longbye0]

@jim9606 av1 不如靠浏览器支持，chrome 因为不支持 265 ，所以视频站和直播，比如 B 站虎牙，才会用 wasm 做 265 解码。

[duke807]

@longbye0 誰不想啊，垃圾蘋果就是拖着不支持 av1 啊

[Cbdy]

stackblitz 的 webcontainer 用的 wasm ，很好用，我天天用

[stevefan1999]

現在有 blazor 了 應該能火起來了

[L1shen]

B 站好像用 wasm 跑 ffmpeg 截用户上传的视频当封面

[keyword233]

@L1shen 推荐封面记得一直是服务端截的图，B 站目前应该只有 H265 支持用到了 wasm

[L1shen]

@keyword233 https://www.w3.org/2020/08/wasm-media.pdf

[xzh654321]

有刚需还是会用的，没有的话当然还是拿 js 解决了……