2022年，WebAssembly（通常简称为Wasm）突然成为焦点。新的Wasm初创公司涌现，老牌公司宣布支持Wasm。字节码联盟推出了一些Wasm标准。CNCF主办了两次WasmDay活动。而Wasm最大的用户之一Figma被Adobe以惊人的200亿美元收购。
Wasm的核心是二进制格式。许多不同的语言可以编译成相同的格式，这种二进制格式可以在多种操作系统和架构上运行。Java和.NET在这方面类似，但Wasm有一个主要区别：Wasm运行时不信任它执行的二进制文件。
Wasm应用程序被隔离在沙盒中，只允许访问用户明确允许的资源（如文件或环境变量）。Wasm还有许多其他令人满意的特性（例如卓越的性能），但正是这种安全模型使Wasm在从浏览器到边缘和物联网，甚至到云的各种环境中都非常有用。
如果说2022年有一个Wasm趋势，那就是Wasm现在在浏览器之外和在浏览器内获得了同样多的成功（甚至更多）。这是2023年将要发生的事情的基础。从嵌入式设备到大数据中心，Wasm无处不在，2023年将成为Wasm的一年。以下是笔者对2023年Wasm生态系统的五个预测。
1.组件模型将是分水岭
标准很少是生态系统中最令人兴奋的部分。有了“组件模型”这样的名字，激动人心的时刻到来。在这个无聊的名字背后，是Wasm给软件世界带来的最重要的创新。
组件模型描述了Wasm二进制文件相互交互的方式。更具体地说，这两个组件可以告诉对方它们提供了什么服务以及需要实现什么期望。然后Wasm模块可以利用彼此的能力。这为软件开发人员提供了构建应用程序的新方法。开发人员可以声明他们的应用程序需要哪些组件，或者更抽象地说，他们的应用需要哪些功能（而不是用他们首选的源语言查找库），然后Wasm运行时可以代表用户组装正确的组件集。
组件模型正在迅速成熟，已经出现了参考实现。2023年将是组件模型开始重新定义我们如何编写软件的一年。
2.无服务器将是Wasm的最佳选择
在过去几年里，服务器的前景已经很明显了。AWS Lambda让我们看到了一种新的、简单的编程模型，即功能即服务（FaaS）。然而，尽管无服务器概念背后的势头正在形成，但底层技术的运行成本很高。这一成本已经转嫁给了用户。此外，虽然FaaS应用程序的启动时间比容器快，但它们仍然没有达到今天对web性能的期望。速度还有提高的空间。
Wasm改变了无服务器环境的潜力。由于几乎即时的启动时间、较小的二进制文件大小以及平台和架构中立性，Wasm二进制文件可以用运行当今无服务器基础设施所需的一小部分资源来执行。
如果进入一个经济不确定的时期，大家会很高兴知道Wasm将帮助我们节省开支，同时推进开发人员最喜欢的无服务器功能模型。与基于容器的系统相比，Wasm更快的启动时间和适度的资源消耗所需的计算能力要低得多，使用成本也比Lambda等FaaS系统便宜。
Wasm能够改变无服务器环境的这一认识正是Fermyon创建Spin的原因。Spin是一个面向开发人员的工具，用于引导、构建、测试和部署无服务器功能。Spin的核心是基于Wasm的运行时。它是开源的，已经得到了Fermyon Cloud和Microsoft Azure的AKS的支持，2023年还会有更多。
更小、更快、更便宜、更好。这就是Wasm在2023年为无服务器世界提供的组合。
3.Wasm应用程序将存储在DockerHub和容器注册表中
包管理——从编程语言到操作系统，再到Kubernetes这样的集群编排器，它都是必不可少的功能。每次我们发明一项新技术，我们似乎注定要（重新）发明一个管理该技术资产的系统。
2022年初，我们看到了几种管理Wasm对象的竞争方法。一小部分工程师坚持将OCI Registry（又名Docker Registry）作为存储Wasm的系统。但事实是，OCI Registry格式不支持非容器工件。它用于存储Docker镜像。
然后，OCI Registry的重大变化改变了形势。OCI（开放容器倡议）是一个小型标准机构，致力于管理OCI容器（或我们过去称之为Docker容器）的标准。OCI定义了容器格式、安全模型和运行时。它还定义了如何在注册表和客户端之间移动容器镜像。
2022年底，OCI Registry工作组宣布了一种存储容器镜像以外的其他内容的官方方式。这可能包括Helm图表、照片或Wasm应用程序。这个新功能被称为“工件存储”。
当DockerHub宣布支持这一新的工件存储规范时，一个信号在Wasm生态系统中回响：我们不必重新发明轮子，只需将应用程序存储在DockerHub等OCI注册表中。为了实现这一目标，必须在Wasm生态系统中开展新的工作，但这项工作正在进行中。2023年将是Wasm应用程序在OCI注册表找到归属的一年。
4.所有大型编程语言都将得到W
asm支持
语言支持是Wasm成功的关键因素。随着每一种可以编译成Wasm的新语言出现，一个新的开发者社区都可以获得Wasm的好处。几乎所有排名前20的编程语言都加入了Wasm支持。
2022年，我们看到了Wasm的三次飞跃。Python增加了支持。然后是Ruby。10月，长期以来一直在浏览器中使用Wasm的.NET为Wasm添加了更深入的支持，使其可以在浏览器之外运行。
今年又有三种语言取得了一些进展，2023年将标志着这些语言可以使用。这三种语言是Kotlin、Dart，以及世界上最流行的编程语言：JavaScript。
Kotlin和Dart社区都积极参与建立Wasm编译目标。不过，两者都在等待一个特定的Wasm标准成熟——一个描述垃圾收集的标准，这是一个语言运行时的工具，允许在程序执行时清理内存。我们的预测是，Wasm GC提案将在2023年初可用并得到支持，因此Kotlin和Dart将很快发布Wasm编译器。
5.JavaScript将成为最流行的Wasm语言
在所有语言中，JavaScript与Wasm的关系最为复杂。正如最初设想的那样，Wasm将在浏览器中与JavaScript交互。事实上，Wasm最初的承诺是将浏览器语言支持扩展到JavaScript之外。
但在现实世界的用例面前，这个设想有所变化。
由于Wasm不在浏览器中，许多开发人员希望能够在可以运行Wasm的任何地方运行他们的JavaScript代码。最好的方法是在Wasm运行时内运行JavaScript（而不是像在浏览器中那样在它旁边）。2022年，我们看到几个新的Wasm项目专注于将JS引入新的运行时。其中大多数使用了一个名为QuickJS的开源项目。
QuickJS有很多优点，最重要的是它完全符合最新的JavaScript标准。但它并不是设计成最快或最健壮的JavaScript引擎。嵌入如此简单，以至于许多早期的Wasm项目已经找到了将解释器编译成Wasm，然后在Wasm运行时内运行JavaScript的方法。
但有一个主流的JavaScript运行时加入了争论。Mozilla的SpiderMonkey引擎以其性能和健壮性而闻名，正在进入Wasm世界。它最著名的是在Mozilla Firefox浏览器中使用，但也可以在浏览器之外使用。作为一个可以不断优化其执行的脚本的运行时，SpiderMonkey引擎将是Wasm世界中速度最快的JS引擎。早期数据表明，由于可以在这种环境中进行优化，在SpiderMonkey的Wasm版本中运行的JavaScript在浏览器中的执行速度可能比JS快13倍。
JavaScript是世界上最流行的编程语言。而且，有了像QuickJS和SpiderMonkey这样的Wasm运行时，Wasm的潜力对一个庞大的开发人员社区来说突然变得可用了。是的，C是第一个支持Wasm的编程语言。是的，Rust有相当大的立足点。当然，我们也看到了Python和Ruby的发展。但JavaScript将爆发。
结论：2023年是Wasm年
笔者对Wasm生态系统内部会发生什么做出了五个大胆的预测。随着这些里程碑的实现，Wasm作为浏览器之外的通用技术将变得更加有用。2023年将是Wasm年，因为新功能、巧妙的用例、与Docker Hub的集成以及广泛的语言支持，使其成为一项对开发人员友好的技术，前景广阔。
原文链接：
https://thenewstack.io/webassembly-5-predictions-for-2023/
