WASM为语言提供了一个编译目标，使它们能够被编译，例如在浏览器中可执行。
当然，它目前缺乏某些功能 - 例如从WASM直接访问DOM和在不使用JavaScript的情况下初始化二进制文件。
忽略这一点，今天的JavaScript满足了浏览器兼容编译目标的目标。 但是，输出 JavaScript 通常会很复杂，因为它本身是一种高级语言，并且通常会导致输出大于源代码本身。
假设一个 DOM 访问存在于 wasm 中的世界，将：
- 排除语言运行时，编译为 WASM 的 JavaScript 或 TypeScript 是否会导致二进制大小小于使用 Webpack 生成的等效 JavaScript 包？
- 运行时是否会单独共享和交付？参见Java，SilverLight，Flash，Shockwave
可以想象，这不是一个可以肯定回答的问题，但是，我可以让您更好地了解当前的情况以及事情的发展方向。
编译为 WebAssembly 模块的应用程序将具有以下组件部分：
- 应用逻辑本身
- (可选(运行时
- (可选(主机 API 集成
依次看：
关于(1(，WebAssembly模块是一种大小高效的二进制格式。出于这个原因，它比缩小的JavaScript表示的等效逻辑更紧凑(即更小(。
Re：2，WebAssembly缺少常见的运行时功能，如(堆(内存管理和垃圾收集器。因此，运行时通常与应用程序逻辑一起提供。在某些情况下(Rust(，此运行时非常轻量级，而在其他情况下(Blazor(，它非常重。我们可能会看到这些运行时的权重随着时间的推移而显着减少，这是由于新的WebAssembly功能(垃圾收集，模块缓存(和更好的编译技术(提前编译(。
Re：3，正如你承认的，WebAssembly 缺乏 DOM 访问 - 实际上缺少任何形式的 I/O。目前，您的"标准"WebAssembly工具会生成"绑定"，从而为您的WebAssembly模块和一些JavaScript"胶水"代码增加额外的权重。随着接口类型提案等举措的吸引力，这可能会随着时间的推移而减少。
所以要回答你的问题，是的，我确实认为wasm模块将来会比它们的同类模块更紧凑。我还认为运行时将单独交付并缓存，但更重要的是，这将显着减小大小。