WebAssembly 为何在网页平台上被视为次等语言？
WebAssembly 虽然功能强大，但在网页平台上仍面临诸多挑战，如加载复杂、与 Web API 交互困难等，导致其用户体验不如 JavaScript。
WebAssembly 与 JavaScript 的交互机制
WebAssembly 可以直接与 JavaScript 交互，但无法直接访问 Web 平台的 API。这意味着 WebAssembly 必须通过 JavaScript 来调用这些 API，这增加了开发的复杂性。JavaScript 是网页平台的第一语言，而 WebAssembly 则被视作次等语言。
这种设计并非故意为之，而是因为 JavaScript 是网页平台的原始脚本语言，与平台共同演化。然而，这种设计使得 WebAssembly 用户在使用过程中面临诸多不便。例如，加载 WebAssembly 代码需要复杂的 API 调用，而 JavaScript 则可以通过简单的 script 标签完成。
WebAssembly 代码加载的复杂性
WebAssembly 代码的加载过程远比 JavaScript 复杂。开发者需要使用 WebAssembly JS API 手动加载和实例化代码，这涉及多个 API 调用，且不同方式之间存在权衡，对开发者来说并不直观。
尽管有一些提案如 esm-integration 可以简化加载过程，但这些方案仍无法完全解决 WebAssembly 在网页平台上的次等地位问题。加载复杂性使得开发者更倾向于使用 JavaScript，从而限制了 WebAssembly 的广泛应用。
Web API 调用的额外开销
WebAssembly 调用 Web API 时需要通过 JavaScript 进行桥接，这增加了额外的开销。例如，调用 console.log 需要编写复杂的 JavaScript 代码，而 JavaScript 本身则可以直接完成这一操作。
这种桥接代码通常被称为“绑定”或“胶水代码”，它负责在 WebAssembly 和 JavaScript 之间转换数据。这种转换不仅增加了开发难度，还带来了运行时的性能开销，使得 WebAssembly 在某些场景下不如 JavaScript 高效。
工具链和文档的不足
WebAssembly 的工具链和文档主要面向 JavaScript 开发者，而非其他语言的开发者。这使得非 JavaScript 开发者在使用 WebAssembly 时面临更大挑战。例如，开发者需要先理解 JavaScript 的 API，然后再将其转换为其他语言的 API。
此外，许多标准编译器并不直接支持 WebAssembly，开发者需要依赖第三方工具链，这进一步增加了使用难度。这种工具链的不统一也限制了 WebAssembly 的推广和应用。特别是在跨语言支持方面，WebAssembly 的体验远不如 JavaScript。
性能优化的挑战
尽管 WebAssembly 在某些场景下性能优越，但在与 JavaScript 交互时仍面临性能瓶颈。例如，调用 Web API 时需要大量的 JavaScript 胶水代码，这会增加运行时的开销。
实验表明，移除 JavaScript 胶水代码可以显著提升 WebAssembly 的性能。然而，目前仍无法完全绕过 JavaScript 层，这使得 WebAssembly 在某些场景下无法发挥其全部潜力。
概念边界与实用理解
WebAssembly 在网页平台上的次等地位并非技术上的不足，而是由于其与 JavaScript 的交互机制和工具链支持的差异。开发者在使用 WebAssembly 时，需要理解 JavaScript 的底层机制，这增加了学习和使用的难度。
要充分发挥 WebAssembly 的潜力，需要在工具链、文档和 API 设计上进行改进，使其更易于使用，并减少对 JavaScript 的依赖。这将有助于 WebAssembly 在更广泛的场景中得到应用。
资料与延伸阅读
你可以通过以下原始资料核对文中概念，并继续深入阅读。