---
title: AssemblyScript 与 WebAssembly 的资源解耦
date: '2019-04-18 19:22:17'
draft: false
summary: 试验 AssemblyScript 时，真正值得关注的不是 demo 本身，而是逻辑层和运行资源能否进一步拆开。
slug: assemblyscript-wasm-sandbox-and-separable-runtime
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/Hqe88nTNm
tags:
- webassembly
- assemblyscript
- sandbox
- runtime
topics:
- software-engineering
type: post
---

最近我用 `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` 真正值得持续看的方向，不只是性能，而是它能不能成为一种更中立的执行边界，让应用逻辑在不同宿主之间迁移时，少受平台和语言绑定的限制。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4362508485696024-1.jpg)

![](./weibo-4362508485696024-2.jpg)
<!-- WEIBO_MEDIA_END -->