CNCF在2023年底公布首次Wasm大调查，显示Wasm应用范围已扩散到各类型的应用需求，6成开发者用来打造Web应用，35%用于数据可视化处理，也有3成2用于IoT环境，结合Wasm和AI应用的开发者也高达3成。／CNCF

Wasm技术最吸引开发者的特色，包括了超快启动速度，可以用于探索新应用，以及可跨项目共享代码、可提高JavaScript性能、满足高运算任务的需求、可到处运行的二进位档等等。这些都是吸引开发者，让他们愿意，甚至很想用的原因。

开发者打造Wasm应用所用的开发语言排名，JavaScript理所当然是第一名，高达45%，几乎有一半的Wasm应用采用了JavaScript，其次则是C#（31%）、C++（30%）、Python（29%）和Java（29%）。特别的是，用COBOL这个老牌语言来打造Wasm的开发者竟然也高达15%。超过34%的开发者在开发项目中开始采用WASI，另有34%开发者预计未来一年会采用。

对于可以提供组件模式的WASI项目，多数Wasm开发者都知道这项项目，目前有34%的开发者正在用，也有3成预计未来一年会开始采用。吸引开发者采用WASI的主要原因，高达四成看上了WASI能让Wasm代码具有可移动性（Portability），也能大幅简化Wasm的部署。另外减少复杂度、提高WebAssembly原生能力和Runtime独立性，都是WASI受到青睐的原因。目前WASI项目也计划比照Wasm，申请成为W3C标准，正在提案讨论过程中。Wasm开发者最期待WASI未来可以增加HTTP、IO/streams、SQL这三项能力。

根据CNCF在2023年底公布的Wasm大调查，开发者头号痛点是调试困难，像是现有调试工具的支持还不够，第二项困难是不同Runtime的性能差异很大，导致开发者得自行挑选适合自己应用场景的runtime，增加开发项目管理的复杂度。／CNCF

不过，从这次调查中，也可以看到目前Wasm开发的挑战和相关工具还不够成熟，有待发展之初。Wasm开发者最头痛的三大困难，高达2成开发者认为调试非常困难，像是现有调试工具的支持还不够或是得自己寻找调试作法，第二项困难是不同Runtime的性能差异很大，这就导致开发者得自行挑选适合自己应用场景的runtime，或是针对不同场景采用不同的runtime，这也增加了开发项目管理的复杂度。第三个挑战也是runtime的问题，高达15%的Wasm开发者认为现有Wasm runtime的开发者体验落差太多，彼此的操作习惯，命令语法差异很大，得学习不同套的作法，提高了不少学习门槛和开发复杂度。其他开发挑战还有像是，缺乏了更完整的工具、学习资源不足、特定浏览器有兼容问题、需要不少代码客制等挑战。

这些困难都是Wasm目前技术发展的挑战，也是相关Wasm工具链未来的机会。

WASI小组加速发展组件模式，要让不同语言的Wasm组件直接交互

Cosmonic首席技术官Bailey Hayes也是WASI小组共同主席。这位将Wasm推广到浏览器以外世界的关键推手，在今年初KubeCon欧洲大会的演讲中，她介绍了WASI最新的组件模式，目前是预览第二版，也就是0.2版，吸引了云原生社群的高度关注。这个WASI组件模式，可以让不同开发语言所编译的Wasm程序，有一套标准的输入输出方式，互相沟通，甚至放到同一个更大的Wasm组件中交互。举例来说，用Go语言写的Wasm组件，和用Rust语言写的Wasm组件，有共同的标准输入输出方式，就像用同一种语言开发的组件一样，甚至可以把这两个组件，放入一个更大的Wasm组件中混用。这个组件模型，让Wasm具备了跨各种语言的能力。

Bailey Hayes指出，组件模式将会限制不同组件只能用标准输入、输出管道来确保安全性，但也可以在组件内部创建全域式变量和内存，用同一个runtime的跨组件间调用速度，甚至可以短到奈秒等级的超高速回应。她预告，新版WASI 0.2版草案标准即将完成，就会纳入这个全新的组件模式。

不只如此，WASI在0.2版中，也将开始支持网络能力，换句话说，Wasm组件不只是可以在单一应用环境中彼此沟通，未来也看好能与外部环境，甚至互联网上的第三方应用组件相互沟通，有了网络沟通能力，也可以让Wasm组件更适合用来打造一支支微服务代码，甚至创建一个全用Wasm组件组成的微服务架构。

下一步，Bailey Hayes预告，WASI预览第三版的0.3版，要进一步开始让WASI支持原生的异步能力，让浏览器外的wasm组件，可以用异步的方式，来彼此调用和协作，这是2025年接下来的发展重点。

后续报导请见：WebAssembly生态圈有哪些重要项目？Wasm生态地图重点剖析