WebAssembly十年：从浏览器的第四种语言到「隐形」的基础设施

2017年6月，Figma工程团队在官方博客发布了一组测试数据：将C++渲染引擎从asm.js迁移到WebAssembly后，大型设计文档的加载时间缩短了3倍。这是WebAssembly早期最有力的一次「实力展示」，也让很多人相信这项技术将彻底改变Web开发的格局。

八年过去了，WebAssembly确实改变了Web——但不是以大多数人预期的方式。

从asm.js到Wasm：一场「信任调用栈」的革命

WebAssembly的故事要从2013年说起。当时Mozilla的工程师Luke Wagner、Alon Zakai和Dave Herman发布了asm.js——一个JavaScript的严格子集，通过显式的类型注解（如x|0表示32位整数）让浏览器引擎能够进行更激进的优化。同一时期，Google正在开发Native Client（NaCl）及其继任者Portable NaCl（PNaCl），试图在浏览器中安全地运行原生代码。

两种方案代表了完全不同的设计哲学。PNaCl将不受信任的代码放在独立进程中，通过消息传递与JavaScript通信——这虽然安全，但引入了巨大的异步编程复杂性和独立的API表面。而asm.js采用了一种现在被称为**「信任调用栈」**（Trusted Call Stack）的设计：编译后的代码与JavaScript共享同一个调用栈，可以直接相互调用。

这个设计决策后来被WebAssembly完整继承，成为其能够在浏览器中无缝集成的基石。正如Mozilla的Dan Gohman所言：「这意味着asm.js能够与JavaScript共存。你可以调用JavaScript，JavaScript也可以调用你。」

2015年4月，Luke Wagner创建了WebAssembly/design仓库，提交了第一份设计文档。两个月后的6月17日，四大浏览器厂商——Mozilla、Google、Microsoft、Apple——同步发布公告，宣告WebAssembly项目的正式启动。Brendan Eich——JavaScript的创造者——在他的博客中写道：「我通常以一个笑话结束演讲：『永远押注JavaScript』。我期待着把『和wasm』加入这句话。」

性能的真相：比JavaScript快，但离原生有多远？

「接近原生速度」是WebAssembly最常被引用的宣传语。但这个「接近」到底有多接近？

2019年，马萨诸塞大学阿默斯特分校的研究团队在USENIX ATC会议上发表了一篇题为《Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code》的论文。这是第一篇使用SPEC CPU基准测试套件对WebAssembly进行大规模评估的研究，结果令人清醒：

• 在Chrome中，WebAssembly比原生代码平均慢55%（几何平均1.55x）
• 在Firefox中，平均慢45%（几何平均1.45x）
• 最慢的测试用例达到了2.5倍的性能差距（Chrome）和2.08倍（Firefox）

研究团队通过硬件性能计数器深入分析了性能差距的根本原因：

核心问题归结为几个方面：寄存器压力增加（浏览器引擎保留部分寄存器给JavaScript运行时使用）、次优的寄存器分配器（浏览器使用线性扫描算法而非原生编译器的图着色算法）、额外的安全检查（栈溢出检查、间接调用验证），以及代码体积膨胀导致的指令缓存效率下降。

不过，与JavaScript相比，WebAssembly的优势是明显的。同一篇论文显示，WebAssembly比asm.js快1.3倍。在CPU密集型任务中，这个差距可以扩大到10倍甚至更多。一篇2025年的研究论文指出：「在微基准测试中Wasm平均慢9.84%，但在实际应用中比JavaScript快17.24%。」

为何没有「杀手级应用」？

「JavaScript杀手」这个标签从一开始就是误读。

WebAssembly的设计目标从来不是取代JavaScript——它没有垃圾回收、没有DOM访问能力、没有事件循环。它的定位更接近于**「高性能计算模块」**，用于处理JavaScript不擅长的密集计算任务。

2026年1月发布的《Web Almanac》显示：在桌面端网站中，只有0.35%使用了WebAssembly；在移动端，这个数字是0.28%。虽然相比2021年的0.04%有了显著增长，但绝对数字仍然很小。

更关键的数据来自排名分析：WebAssembly的采用率与网站排名呈现明显的幂律分布——排名前1000的网站采用率最高，然后迅速下降。这说明什么？WebAssembly主要用于「重量级」Web应用：Figma、Google Earth、Adobe Photoshop Web、AutoCAD Web……这些应用确实需要将桌面级的计算能力搬到浏览器中。

但这个市场本身就很有限。大多数网站——博客、电商、企业官网——根本不需要这种级别的计算性能。正如一位开发者所言：「90%的应用场景都不需要用WebAssembly。」

另一个障碍是开发体验。虽然Rust生态已经提供了wasm-bindgen和wasm-pack等优秀工具，但将现有C++/Rust代码库编译到WebAssembly仍然是一项专业工作。调试体验也是长期以来的痛点——Chrome在2019年才支持WebAssembly源码映射，Firefox对此的支持也不完善。一位开发者抱怨道：「编译到asm.js进行调试，编译到WebAssembly用于生产」一度是常见的做法。

浏览器之外的「第二战场」

如果说WebAssembly在浏览器内的发展有些「不温不火」，那么在浏览器之外，它正在悄悄开辟第二战场。

2019年3月，Mozilla宣布了WASI（WebAssembly System Interface）——一个让WebAssembly模块能够安全地与操作系统交互的标准接口。Docker的创造者Solomon Hykes在Twitter上的一句评论引发了广泛关注：「如果WASM+WASI在2008年就存在，我们就不需要创建Docker了。」

WASI的设计哲学与POSIX不同。它采用基于能力的安全模型（Capability-based Security）：WebAssembly模块不能随意访问文件系统或网络，只能使用宿主显式授予的权限。这种设计使得WebAssembly成为沙箱化执行不可信代码的理想选择。

Cloudflare Workers、Fastly Compute@Edge等边缘计算平台已经基于WebAssembly构建了他们的Serverless基础设施。一篇2025年的文章指出：「一个结构良好的Wasm后端可以在个位数毫秒内冷启动。」相比之下，Linux容器的冷启动通常需要数百毫秒。

2024年1月发布的WASI 0.2.0（Preview 2）引入了组件模型（Component Model），这是WebAssembly生态的一个重要里程碑。它允许用不同编程语言编写的Wasm模块安全地互操作——一个用Rust编写的模块可以调用一个用C++编写的模块，而无需了解对方的内部实现。

2025年9月，WebAssembly 3.0正式发布，包含了11项标准化特性：垃圾回收（WasmGC）、Memory64、多内存支持、SIMD、尾调用优化、类型化引用等。这些特性使得更多编程语言能够高效地编译到WebAssembly——包括需要垃圾回收的语言如Java、C#、Python。

成功案例：谁在真正使用WebAssembly？

尽管没有爆发式的普及，WebAssembly在一些领域已经建立了稳固的立足点。

图形与设计工具。Figma是最早的WebAssembly「代言人」，他们用C++编写的高性能2D渲染引擎编译到Wasm，在浏览器中实现了桌面级的设计体验。Adobe将Photoshop、Lightroom、Acrobat等产品的Web版本都迁移到了WebAssembly。Google Earth在WebAssembly的支持下可以在浏览器中流畅地渲染3D地球。

媒体处理。FFmpeg.wasm项目将FFmpeg移植到了WebAssembly，使得在浏览器中进行视频转码成为可能——虽然性能只有原生FFmpeg的大约8%。但对于需要客户端视频处理的Web应用来说，这已经足够实用。

游戏引擎。Unity和Unreal Engine都支持将游戏编译到WebAssembly。虽然与原生性能仍有差距，但对于不需要极致性能的休闲游戏和互动内容，这已经是一个可行的选择。

AI推理。ONNX Runtime Web、TensorFlow.js等框架利用WebAssembly加速机器学习推理。WebGPU与WebAssembly的结合正在让浏览器成为AI应用的新阵地。

服务器端与边缘计算。Shopify使用WebAssembly运行自定义后端逻辑；BMW正在将WebAssembly用于车载系统的分布式验证。Fermyon、wasmCloud等项目正在探索将WebAssembly作为云原生的轻量级运行时。

十年后的反思

回顾WebAssembly的十年发展，一个清晰的趋势浮现出来：它没有成为「第四种Web语言」，而是成为了「隐形的基础设施」。

普通用户可能永远不会直接「使用」WebAssembly——就像他们不会直接使用TCP/IP或TLS一样。但当他们打开Figma设计一个界面、在浏览器中观看高清视频流、或使用基于AI的Web应用时，WebAssembly可能正在后台默默地工作。

这种「隐形」的成功或许正是WebAssembly设计者们的初衷。Luke Wagner在回顾十年历程时说：「有人说不因为它被用于浏览器之外所以不是『Web』……但W3C对开放Web平台的定义要宽泛得多，我认为它覆盖了WebAssembly今天运行和未来将要运行的更多地方。」

2026年即将发布的WASI 0.3将带来原生异步支持和协作线程，随后是1.0正式版。WebAssembly的故事还在继续——它可能永远不会成为每个开发者每天都在编写的技术，但它正在成为支撑下一代计算基础设施的基石。

有时候，一项技术的成功不在于它多么显眼，而在于它能让其他技术变得多么强大。WebAssembly的十年，正是这种「基础设施式成功」的最佳注脚。

参考资料

1. Haas, A., et al. (2017). “Bringing the Web Up to Speed with WebAssembly.” PLDI 2017.
2. Jangda, A., et al. (2019). “Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code.” USENIX ATC 2019.
3. Figma Blog. (2017). “WebAssembly cut Figma’s load time by 3x.”
4. Bytecode Alliance. (2026). “10 Years of Wasm: A Retrospective.”
5. HTTP Archive. (2026). “WebAssembly | 2025 | The Web Almanac.”
6. WebAssembly Official Documentation. https://webassembly.org/
7. Wagner, L. (2015). WebAssembly Design Repository Initial Commits.
8. Clark, L. (2019). “Standardizing WASI: A system interface to run WebAssembly outside the web.” Mozilla Hacks.
9. WebAssembly Feature Status. https://webassembly.org/features/
10. V8 Blog. (2018). “Liftoff: a new baseline compiler for WebAssembly.”
11. MDN Web Docs. WebAssembly Documentation.
12. Gohman, D., et al. WASI Specification. https://wasi.dev/
13. Component Model Specification. https://component-model.bytecodealliance.org/
14. LeadDev. (2024). “WebAssembly is still waiting for its moment.”
15. Chrome Platform Status. WebAssembly Feature Implementation.