AssemblyScript 与 WebAssembly 的资源解耦

最近我用 AssemblyScript 试了一下 WebAssembly，顺手做了个五子棋游戏。

但这件事里真正让我感兴趣的，其实不是小游戏本身，而是它再次让我看到了一种更值得长期关注的结构：应用逻辑、界面，以及运行资源，是否可以进一步解耦。

AssemblyScript 可以理解成一种从 TypeScript 走向 WebAssembly 的语言路径。它当然还不等于完整 TypeScript，很多特性并不支持，比如：

• 不能直接把 number 当万能数字类型用
• 需要更明确的 i8、i32、i64 这类数值类型
• interface 等更复杂的类型能力并不完整
• 一些复杂内存分配和类型场景还会暴露出奇怪问题

所以它还远谈不上成熟到可以无缝替代原有生态。

但它有意思的地方在于，它让“应用核心逻辑以 Wasm 形式存在”这件事开始变得更具体了。

我这次的实验里，把游戏 Engine 和 GUI 分开实现。

• Engine 只依赖 AssemblyScript
• GUI 依赖 as2d，通过浏览器 canvas 做渲染

这样一来，GUI 可以通过本地 JavaScript 粘合代码调用 Engine，也可以通过远程接口去调用服务器端运行的同一套 Engine 逻辑。

如果这个模式继续往前推，理论上就会出现一种更有意思的结构：

• 应用开发者主要提供逻辑和界面
• 运行方提供本地或远程的沙箱环境
• 双方通过标准接口交互、存储状态、传递调用
• 至于逻辑最终跑在浏览器、本地宿主，还是远端服务，未必需要由应用开发者自己强绑定

也就是说，程序开发和程序运行资源的提供，未来可能进一步分离。

这件事如果再和 FaaS、区块链、二层仲裁之类的机制放在一起看，会更有意思。因为它暗示的不是“浏览器里又多了一个新技术”，而是应用的执行位置和资源归属，可能会变成一种可切换、可协商的能力。

所以我会觉得，WebAssembly 真正值得持续看的方向，不只是性能，而是它能不能成为一种更中立的执行边界，让应用逻辑在不同宿主之间迁移时，少受平台和语言绑定的限制。

原微博中的媒体