在 WebAssembly 的官网定义中，for a stack-based virtual machine 这句话也值得关注，因为它引领了 WebAssembly 这一本来为 Web 设计的技术 (名字中就蕴含了Web 一词)，最终进入后端畛域。
这是因为，从晚期的 VMWare WorkStation、VirtualBox，到明天的 Docker，虚拟化技术始终是云计算的根底。因而，作为一种具备诸多劣势的虚拟机代码格局，WebAssembly 进入后端应用领域是必然趋势。Docker 创始人 Solomon Hykes 在 2019 年示意：
如果 WASM+WASI 在 2008 年就存在，咱们就不须要创立 Docker
可见 WebAssembly 在后端利用中的确具备广大的利用前景。
当然，Solon Hykes 示意，他的意思并不是稍后 WebAssembly 将取代 Docker.
这也是当今业界广泛的认识：WebAssembly 和 Docker 各有劣势，井水不犯河水。具体来说：
- WebAssembly 程序的大小通常在 1M 左右，而 Docker 镜像往往很容易超过 100M，因而 WebAssembly 的加载速度要快得多。
- WebAssembly 程序的冷启动速度比 Docker 容器快约 100 倍。
- WebAssembly 运行在沙箱中，任何与外界的交互都须要取得明确的许可后能力进行，安全性极佳。
WebAssembly 模块只是一个二进制程序，不蕴含操作系统环境，所以它不能像咱们在 Docker 中那样编译后执行。
如下图所示，无论是 Web 利用还是非 Web 利用，咱们都须要在宿主程序中嵌入 WebAssembly Runtime(运行时)能力应用 WebAssembly.
惟一不同的是，在 web 利用中，宿主程序是浏览器，而在非 web 场景中，宿主程序是咱们本人的利用，具体到后端利用，宿主程序则是咱们的后端服务。
目前可用的 WebAssembly 运行时包含 Wasmtime、WasmEdge、WAVM、Wasmer 等，各有优缺点。
上面以 Wasmtime 为例，介绍如何在 Go 语言开发的宿主程序中嵌入 WebAssembly.
嵌入 WebAssembly 运行时和实例化 WebAssembly 模块非常简单，如果省略错误处理，上面几行代码就能够实现所有这些工作。
func createWasmVM(code []byte) {engine := wasmtime.NewEngine()
module, _ := wasmtime.NewModule(engine, code)
store := wasmtime.NewStore(engine)
linker := wasmtime.NewLinker(engine)
inst, _ := linker.Instantiate(store, module)
_ = inst
}