跟Docker容器一样，Wasm在诞生之初就拥有着确切且自适应的计算结构。它能够适应多种不同编程语言，除了常见的HTML和CSS之外，它还能将JavaScript（JS）、C++和Rust集成至单一运行时平台之内，并以二进制格式执行函数。
Wasm既可用于支持Web应用程序，也能扩展至CPU上运行的各类边缘环境/云原生平台，包括服务网格和边缘Kubernetes等场景。另外，Wasm的历史也不算短了，并于2019年被万维网联盟（W3C）指定为Web标准，成为继HTML、CSS和JavaScript之后的第四项Web标准。
而之所以目前的竞争用例间还没出现大量交集，主要是因为Docker容器，特别是容器自身的结构和功能特性。也正是凭借这些特性，让Docker和容器成了DevOps领域的宠儿。如今，除了容器和Wasm之外，市面上还存在裸机、虚拟机、函数即服务（FaaS）等多种不同应用计算架构，未来肯定还会出现更多。
在Levirne看来，这意味着“开发者在选择代码运行方式时，将继续拥有更大的灵活性。容器的优势在于提供丰富的应用执行能力，允许这些应用程序随意使用当前Linux提供的全部开源和商业库、包及工具，同时又提供了相对轻量化的隔离机制。相比之下，Wasm的隔离方法更轻量化，但却只适用于特定一部分纯新建应用程序。换句话说，这些应用程序无法依赖以往无数开源项目的既有成果。”
容器技术在这两大应用场景中势头仍然强劲，“相信这种优势至少还能再持续几年。”在Butcher看来，“原因有二：首先，容器仍是对现有应用程序不加修改、直接打包的最佳选项。换言之，任何现有应用程序都能轻松进行打包、分发并以容器形式运行。其次，数据库和持久数据存储天然跟容器更对路。PostgreSQL、MongoDB和Redis等数据服务用例都更适应传统服务器模型，即一个进程启动完成后，会一口气运行数天、数月甚至数年，期间绝不中断。在这两点上，我认为WebAssembly在很长一段时间内还发挥不出自己的独特优势，所以不可能成功压倒Docker。”
但另一方面，Wasm也不乏证明自身价值的舞台。Wasm的价值核心在于面向二进制结构，因此可以直接在CPU层次上运行，并消除容器镜像内包含代码缺陷等潜在风险。
Adobe公司高级软件工程师Colin Murphy在采访中表示，Wasm代表的正是“人们所说的「业务逻辑」，即用应用代码直接构建Web服务产品”。以Adobe为例，他们使用Wasm和WASI帮助用户在Adobe Sign中签署文档，并在Lightroom中编辑图像。但在除此以外的其他场景下，Docker“仍将主宰一切”，例如数据库、代理和只运行NGINX/Apache的Web服务器等。
Murphy还强调，“具体来讲，任何与WASI基于能力的安全模型相冲突的事物，都还是得由Docker来处理。另外，受到安全模型或其他因素的限制，很多遗留应用程序无法被轻松移植至Wasm。”
SingleStore公司首席软件工程师Bailey Hayes表示，使用用户代码扩展系统的方法多种多样，Wasm的独到之处在于提供一种可移植且安全可靠的沙箱，能够以接近原生的速度在进程内运行。
Hayes解释道，“对数据库而言，只有回避其他解决方案的缺点，例如数据重复、网络通信或进程间通信，才能真正实现高性能。正因为如此，我们才选择Wasm来支持SingleStoreDB中的代码引擎。”
另外，安全性也是Wasm的一大主要卖点。Murphy表示，“与Docker相比，Wasm的优势主要体现在安全性、性能、模块化和大小。而且即使是在允许的范围内，Wasm的要求也更严格一些。”
Murphy解释道，与Docker不同，“我们不能在Wasm上简单构建一个巨型应用程序，把它复制到容器里再直接丢掉生产环境运行。这么干也有好处，比如在运行一个堆大小达128 GB的JVM时，这样能防止效率下降。但同时，这样会大大提升应用程序的移植难度。毕竟Wasm本身就是一种语言，虽然很多语言都能被编译为Wasm，但最终会受到Wasm范式的约束。事实证明，已经针对容器化完成了优化，或者说最没必要移植的应用，反而是最易于移植的。而大部分不符合容器原则的应用程序反正处处受限、难以编译。”
