我很喜欢 TypeScript，它是一门设计得很精妙的语言。但我觉得 TypeScript 不太可能支持编译成 WASM。两个原因：
首先，二者的类型系统有一些鸿沟（前文已经提到了），如果强要把 TypeScript 编译成 WASM，需要 AssemblyScript 这样的语言。然而，这样就意味着整个 TypeScript 和 javascript 的生态圈就很可能无法使用了。而 TypeScript 最大也是最成功的优势就是在为项目渐进式地引入类型系统的同时，保持了对整个生态圈的兼容。如果这个优势不存在，那么使用它的意义何在？
其次，为什么我们要把 TypeScript 编译成 WASM？它能带来什么好处？
更好的性能？如果项目对性能的需求真的变态高，高到是 TypeScript 解决不了的，比如构建一个游戏引擎，那为何不换一种效率更高的语言，比如 rust 撰写，然后编译成 WASM 呢？
更小的代码体积？抱歉，这个 WASM 真的要吼：臣妾做不到啊。
更高效地和 DOM 以及浏览器事件互操作？抱歉，WASM 操作 DOM 需要经过 javascript。。。再看看上图 vim.wasm 是怎么做的。
如果我们无法回答这个问题，那么花那么大精力支持把 TypeScript 编译成 WASM 有什么意义？仅仅是为了赶时髦搭上新技术的列车么？
我们看 chrome 里对 javascript 和 WASM 的支持：
可以看到，二者是不是取代，而是并存的关系。它们背后使用了同样的执行引擎 TurboFan。javascript 代码在解析和 JIT 阶段会耗费不少时间，但一旦代码在运行时被优化后，其执行效率和 WASM 并没有太大的区别。而对 javascript 这样灵活的语言来说，运行时的优化比 AOT 时期的优化能够做更多的事情。如果强行把它在编译期编译好，反而可能影响运行时的效率。所以，我想不太出来把 TypeScript 编译成 WASM 的在 web 上的使用场景。
当然，WASM 还有一个不容忽视的使用场景是服务器端。它脱胎于 web 的安全性使得它成为后端取代 docker 这样的沙箱的绝好平台。如果 WASI 相关的应用在后端蓬勃发展，那么对于一个 TypeScript 工程师，可以写能够运行在服务器端的 WASM 运行时 wasmer / wasmtime 上，也许还是有些吸引力的。这也许是唯一的，把 TypeScript 编译成 WASM 的理由。
|
|
