这个有点儿远了，我一直认为 wasm 之于 js，并不是替代而是互补。一开始 node 想要调用 native 模块非常麻烦，后来有 n-api 但还是麻烦。但有了 wasm 之后，完全提供了另外一个解决问题的思路，而且只要发布一个 wasm 文件也相当方便。

另外，js 有许多 runtime，现在最火的是 node，但也有了 deno。bun 虽然很新但是已经融到了一笔钱，至少未来几年是有发展的。但竞争带来的改变却非常有趣：
1. 喊了好多年的 fetch API，node v18 终于支持了，没 deno 的话不知道要拖到啥时候
2. deno 一直不打算支持 node modules，bun 火了一把之后，马上说3个月之内支持

我目前的工作流已经尽量直接跑 ts 文件，避免编译这一步了。node 有很多历史问题，比如 commonjs vs esmodule，包管理也是乱七八糟的。deno 已经提供了一套解决方案，而前不久 bun 又提供了另一套，用的还是 jsc 不是 v8。除了 cpp 的 node，go 的 esbuild（不是 runtime 但在我 node 工作流里非常重要），rust 的 deno，zig 的 bun。说不定哪天再冒出来个基于 cpp2 + spidermonkey 的 runtime，或者 v8 用 carbon 重构，反正我不会感到意外。

另外 wasm 本身的应用还是比较广的，至少是 web service 这个方向。比如我们公司有一大堆 oracle stored procedures，产品的核心业务逻辑都是在 db 里面的。想把它们拿出来重写的话，我觉得这个场景就非常适合 wasm。前端只要浏览器不太老都可以直接用，后端如果已经自带 wasm runtime 当然最好，不带的话做成单独的 service 问题不大，前端也可以调。

【 在 gondar 的大作中提到: 】
: 你觉得啥能替代js？wasm还不成熟吧，而且搞起来也太麻烦，除了对性能有要求的，感觉wasm撼动不了js的地位，而且我知道的几家用wasm的公司，都是用的cpp
--
FROM 203.184.25.*