Ending定律：一切可编译为 WebAssembly 的，终将被编译为 WebAssembly（Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually）。
作者 | 柴树杉 责编 | 梦依丹
出品 | CSDN（ID：CSDNnews）
引子：作者在 2018 年写作《WebAssembly 标准入门》时，有幸邀请到 CSDN和极客帮的创始人蒋涛先生为该书作序，当时蒋涛先生就对 WebAssembly 的技术做出了高度评价。2022 年我们针对 WebAssembly 开源了凹语言，CSDN 平台也在第一时间提供了报道。在此一并感谢CSDN 平台对 WebAssembly 技术推广的支持！
WebAssembly 作为一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率。2018 年 WebAssembly 第一个规范草案诞生，2019 年成为 W3C 第四个标准语言。到了 2022 年底可以说我们已经进入了WASM 原生时代……
Ending 定律和 WASM 原生
1、什么是 Ending 定律
Ending’s law: “Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.”
Ending 定律：“一切可编译为 WebAssembly 的，终将被编译为 WebAssembly。”
Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emen 技术交流会上针对 WebAssembly 技术给出的断言。Ending 定律的威力不仅仅在语言层面。WebAssembly 是第一个虚拟机世界标准，以后将人手至少一个 WASM 虚拟机。不过和之前被大家鄙视的 Java 语言大举入侵各个领域的情况不同，这次 Python、Ruby 这些语言将彻底拥抱 WebAssembly 技术，因为它是一个更底层、也更加开放的新兴生态平台。从 Ending 定律可以预测 WASM 原生时代迟早都会到来。
2、什么是 WASM 原生
WASM 原生可以类比云原生的定义：就是天生就是为 WebAssembly 平台设计的程序和语言。比如专门为 WebAssembly 设计的 Assembly 语言和 凹语言就是 WASM 原生的编程语言。如果一个应用天生就是考虑了 WebAssembly 的生态支持，那么就是 WASM 原生的应用。一个 WASM 原生应用很容易支持纯浏览器环境，因此不支持纯浏览器环境的应用大概率不是 WASM 原生。
现在 Docker 已经开始支持 WASM 程序，因此 WASM 原生软件天然也是云原生的软件，但是反之则不能成立。而云原生因为受限于云的环境、导致其应用的场景和领域有较大的限制，比如云原生应用强依赖网络因此无法在很多单片机环境、甚至是本地环境运行，因此云原生更多是在互联网企业流行。但是 WASM 原生的程序则可以轻松在 Arduino 等受限环境、本地台式机机环境、个人智能手机环境和 Kubernetes 等云原生环境执行。可以说未来 WASM 原生应用将无处不在！
WebAssembly 简史
WebAssembly（简称 WASM）是 W3C 定义的第 4 个标准，是 Web 的第四种语言。说 WebAssembly 是一门编程语言，但实际上它更像一个编译器，其实它是一个虚拟机，它还包含了一门低级汇编语言和对应的虚拟机体系结构，而 WebAssembly 这个名字从字面理解就说明了一切：“Web 的汇编语言”。简而言之、WebAssembly 是一种新兴的网页虚拟机标准，它的设计目标包括：高可移植性、高安全性、高效率（包括载入效率和运行效率）、尽可能小的程序体积。
展开全文
1.1 Emen 项目
WebAssembly 的前身是 Mozilla 创建的 Emen 项目（2010年）——通过将 C/C++ 通过 LLVM 编译到 Java 的 asm.js 子集来提速！Java作为弱类型语言，由于其变量类型不固定，使用变量前需要先判断其类型，这样无疑增加了运算的复杂度、降低了执行效能。因为 asm.js 仅包含可以预判变量类型的数值运算，有效的避免了 Java 弱类型变量语法带来的执行效能低下的顽疴。根据测试，针对 asm.js 优化的引擎执行速度和 C/C++ 原生应用在一个数量级。
2015 年 6 月 Mozilla 在 asm.js 的基础上发布 WebAssembly 项目，随后Google、Microsoft、Apple 等各大主流的浏览器厂商均大力支持。WebAssembly 不仅拥有比 asm.js 更高的执行效能，由于使用了二进制编码等一系列技术，WebAssembly 编写的模块有更小的体积和更高的解析速度。目前不仅 C/C++ 语言编写的程序可以编译为 WebAssembly 模块，Go、Kotlin、Rust、Python、Ruby、Node.js、Assembly、凹语言等新兴的编程语言都开始对 WebAssembly 提供支持。
1.2 WebAssembly 1.0 草案
WebAssembly 技术自诞生之日就进入高速发展阶段。在 2018 年 7 月 WebAssembly 1.0 草案正式发布，在 2019 年 12 月正式成为 W3C 国际标准，成为与 HTML、CSS 和 Java 并列的唯四前端技术。2019 年，同样诞生了 WASI（WebAssembly System Interafce）规范，用于将基本的系统调用带入到WASM生态。2022年Docker对WASM提供支持，目前 WebAssembly 已经是一个独立的生态。
1.3 WebAssembly 生态大图
下面是 “WebAssembly 将引领下一代计算范式” 展示的生态大图：
可以看到从工具链、基础设施、到应有和 Web3 均有涉及，生态已经非常丰富。正和 JVM 构建的生态类似，WebAssembly 也在构建自己的庞大生态。
WASM 社区 22 年的变化
2022 年，国内外自媒体社区对 WebAssembly 的评价态度可谓是完美遵循了欲扬先抑的剧本。先是有热文爆大佬 WebAssembly 创业失败引发质疑，然后是传出社区分裂、应用争议再引发炒错的方向等争论，然后随着 Docker 对 WASM 支持的预览版发布带来风向 180 度大转弯，简直是要把不明真相的群众彻底忽悠拐了。其实 WebAssembly 从诞生之日起，真正的从业人员始终在稳步推进，完全没有自媒体想象和策划的这些剧本演义。
3.1 WebAssembly 2.0 草案
4 月 20 日，W3C 公布了 WebAssembly 2.0 的第一批公共工作草案。主要包含向量类型、引用类型、多返回值、多 Table 支持、Table 和内存指令增强等。向量类型的支持可以用于优化纯计算类型的并发程序、引用类型可以用于和外部的浏览器 DOM 对象等更好的交互、多返回值可以可以简化某些程序的表示（比如凹语言后端依赖该特性）、多 Table 支持可能用于灵活支持多模块连接等。可以说 WebAssembly 标准是该生态的统一基准平面，而且这些特性的实现已经相对普及，可以作为实验特性试试用。
完整文档参考：/
3.2 Docker 支持 WebAssembly
2019 年，Docker 创始人 Solomon Hykes 发布了一条推文，他说如果 2008 年就诞生 WebAssembly 和 WASI 的话，Docker 就没有必要诞生了。
其实作者在 2018 年写作《WebAssembly 标准入门》时， 通过推演也得出过类似的结论：当时的结论是 WebAssembly 更大的生命力在浏览器之外，如果配合文件系统、网络系统将得到一个更为迷你的操作系统无关的运行平台。
Docker 与 WasmEdge 合作创建了一个 containerd shim，该运行时支持运行 WASM 程序。下面是 Docker 对 WASM 的支持原理图：
Docker 执行 wasm 需要指定一些额外参数：
首先 runtime 参数指定 wasmedge 运行时，然后 platform 指定采用 wasi/wasm32 规范（指定有哪些宿主 api）。
完整的信息可以参考 Docker 的官方文档：/
3.3 SQLite3 官方支持 WebAssembly
SQLite3 作为一个纯粹的 C 语言库，其实在 WebAssembly 标准诞生之前就可以通过 Emen 技术将 C 代码编译为 as
