目前看到的浏览器外的客户端应用似乎大多还只是把wasm当成一种“更好的Lua“来用，因为都是可以在一个内嵌的虚拟机中运行可更新的代码，所以常被用来实现代码逻辑的热更新。但要在封闭的花园中使用本身就有阻力（比如iOS版的微信小程序，如果允许热更新，应用审核就形同虚设）。 服务端方面，传统的组件大都提供了脚本扩展的功能（比如Nginx官方支持JavaScript，OpenResty和Redis等支持lua），同时也都可以编写原生组件来扩展功能（如Node.js的N-API）。wasm相比原生代码在可移植性上更好，同时性能上优于脚本，应该可以在一些新的场景中找到自己的位置。但从标准化的系统接口这个角度来说，这是以JVM为代表的一众生态一直在解决的问题，所以wasi更像是在另一个生态中重新发明一遍轮子。 当前有很多语言都号称支持wasm，但实现方式各不相同，性能也不一样。需要手工内存管理的语言通常都支持直接编译为wasm；带gc的语言可能就需要额外输出一个wasm实现的gc；脚本语言最省事，用wasm实现一个解释脚本的虚拟机就可以跑起来了。 对于web前端开发人员来讲，为了极致的运行性能而去重新学习和使用一门支持wasm的系统级编程语言，开发效率不升反降。所以wasm可能并不会为前端开发带来多少新的机会，相反应该是为系统级开发人员提供了一个进入前端的窗口。 以上是我当前的看法，希望学完之后能有新的认识。