Design: WebAssembly 是否应该考虑与开放 Web 平台的兼容性至关重要？

我大致同意所写的声明，但我认为任何形式的正式承诺都不会避免与您相关的许多分歧。 特别是，您的陈述主要被表述为通过提案的额外障碍，但在许多相关问题中，您主张增加核心语言。

考虑假设的极端立场“如果一个特性有助于与 Web 的兼容性，我们必须将它添加到 Wasm”可能是一个有用的思想实验，我不同意，因为它最终会使语言变得臃肿。 JS 特定的钩子。 我并不是在暗示您主张这样的立场，但我确实认为您在 OP 中所写的声明并没有捕捉到您所链接的问题中似乎出现的概念分歧。

核心语言“WebAssembly”（我觉得它绝对必须与“开放式 Web 平台”保持兼容）与工具、主机接口和导入命名空间的生态系统之间也有区别，人们可能会选择围绕它进行标准化/工程化. WASI 保持“Web 友好”并不重要，因为它是一个导入命名空间，主机可以简单地选择不提供。 在最坏的情况下，如果后来有人标准化了一个对 Web 更友好的 API，它会导致重复工作/工具链分裂。

是的，其中一些问题有点老，我今天肯定会以不同的方式处理它们（如果当时存在这样的承诺，那就更是如此）。 我会考虑一下这个和你的其他观点:)

我对在许多问题上都提倡增加核心语言的印象感到有些惊讶，所以也许提供一些背景可能会很好。 偶尔，我确实制定了一个后袋替代方案（我猜），它在讨论的上下文中似乎很有帮助，这可以被视为我认为的补充，最值得注意的是通用字符串，我试图帮助解决接口之间的感知僵局类型和 GC 都指向对方以对我的担忧负责。 事后看来，我很遗憾在 IT 问题上再次提出这个问题，因为 GC 似乎是更合适的地方。 那么，它可能仍然在那里爆炸，不确定。 在一天结束的时候，我从来没有提出这些，也考虑到现有的紧张局势，但主要是出于解释我具体意思的愿望而创造它们。 事后看来，我发现自己陷入了两难境地，因为任何提议似乎都因紧张而注定要失败，而且更详细地阐述我的论点也是如此，所以如果我们可以让每个人的生活更轻松一点让 WebAssembly 的目标更加清晰，并致力于解决普遍的分歧，我非常感激。

假设的极端情况非常有趣，因为我还认为，Wasm 可能不必主动担心遗留的 JS 功能，或者可能根本不用担心，但仍有一条线需要在某处划定。 我的直觉告诉我，一项功能太多总比一项功能太少好，例如，因为兼容性非常重要。 有了承诺，也许至少更有可能以更少的摩擦来讨论少数人感兴趣的功能，并且更有可能成功实现更高的目标？

核心语言和更广泛的生态系统之间的区别同样有趣。 我认为，如果可以的话，我们应该尽量避免走上未来生态系统问题和不兼容的道路，并且应该更多地讨论避免网络上的 Wasm 和网络外的 Wasm 之间的碎片化，这似乎是一个到今天为止，这个话题基本上不存在。 例如，在 Node.js 生态系统中，事实证明，为非 Web 发明的所有自定义 API 最初都很酷，但今天也是一种负担，因为坚持（重用）Web API 通常比强制 polyfill 更可取。 可以说，Node.js 的第二次尝试 Deno 意识到了这一点，但更广泛的生态系统现在已经坚持了很长时间。

我不知道避免重复努力会有多大价值。 将其作为一种选择很有用，只要它不会导致可能可以避免的碎片路径？ 例如，WASI 是 WebAssembly 保护伞下的准标准，现在正潜入 Web 上的 Wasm，它越成熟，就越难解决我们在此过程中发现的生态系统问题，因此有一种机制可以防止这种情况发生。在为时已晚之前取得成果似乎很有用。

我们的设计目标不能绝对保证 Wasm 对于特定的生态系统或用例是最佳的，因为从根本上说，Wasm 服务于许多生态系统、用例和语言，这总是需要某种程度的妥协。

除了 web 和 non-web，Wasm 的设计到目前为止还非常重视为 web 带来更广泛的语言集，这些语言通常是几乎故意与 JS 非常不同的语言，因为它们最能补充 JS 的现有能力，从而使 JS+Wasm 的组合最强大。 它还允许将最大量的现有软件带到网络上，并使网络达到新的性能水平。 相反，如果 Wasm 被设计为支持与 JS 非常相似的语言，那将毫无意义。

这是一件好事，但自然意味着这些语言在涉及内存管理、字符串等的实现细节时可能会有很大的不同，并且应该考虑到它们的需求，特别是因为使用这些语言的全部意义在于让他们在这个新环境中更有效率。 说到边界的互操作，不仅要考虑与 JS 的互操作，还要考虑多种 Wasm 语言之间的互操作，未来这些语言与浏览器和其他 Wasm 主机的原生代码互操作，这将通常是相同或相似的语言。 诸如接口类型之类的建议试图平衡所有这些要求，而不仅仅是其中之一。

我相信在比赛中还有另一个误解可能很好谈。 我确实一直在提倡考虑我的项目的需求，最初更是如此，因为我希望它有些独特的观点（我相信今天的一些 AssemblyScript 问题是 WebAssembly 未来问题的金丝雀）对 CG 很有价值，但最近尤其是今天，我并不是在提倡一种特定的语言，而是为了在 Web 上实现更高的兼容性目标，同时希望能很好地利用这个机会来解决团队之间的分歧。 和你一样，我坚信 Wasm 不应该偏爱一种特定的语言，而且我担心我们正在失去对更重要的方面的关注，比如 Web 标准之间的兼容性，而不是支持或反对特定语言，从而导致讨论很可能变得过于激烈而无法具有建设性，从而阻碍了 WebAssembly 的发展。 举个例子，我对你表达你的评论的方式有点冒犯，因为我觉得它暗示了很多事情可能在我的议程上但不是，而我实际上同意你不赞成的更高层次的观点特定语言，补充 JS 的现有能力，平衡所有需求，在必要时做出妥协，并努力达到新的性能水平，只要它不会导致不再是 Web 标准的 Web 标准，这将是很不幸。

首先，我想说的是，我认为您在 CG 中有对手的经历是流程失败的标志。 即使我们在技术细节或优先事项上存在强烈分歧，以非对抗性方式工作对我们来说并不是一个不合理的目标。

其次，我同意与 JS 的互操作性对于 Core WebAssembly 的成功很重要。 这包括像 GC 和 EH 这样的提案，它们还没有完全充实 JS API，但会在它们标准化之前。 还有堆栈子组，它正在考虑将 JS 互操作作为其首要任务。 我还将在该声明中包括其他提案，例如 IT 分层，可能通过单独的规范，在 Core WebAssembly 之上，但仍旨在集成到 Web 平台中。

我确实认为对于 Core WebAssembly 规范的非 Web 消费者，尤其是 WASI，演算是不同的。 我不认为 CG 应该（或可以）尝试对如何在 Web 平台之外使用或嵌入 Core WebAssembly 施加任何控制，并且由于 WASI 子组目前没有提议对 Web 平台进行任何更改，我不认为用 Web 兼容性义务来约束它是有意义的。 考虑到 WASI 子组总是可以在其他一些标准组织中以相同的目标进行相同的工作，但我们在协作、思想的交叉授粉和组织开销方面都要好得多（更不用说兼容性了！ ) 因为它是 CG 的子群。

说到微积分，一个假设的极端场景“如果一个子组怀有恶意的意图来影响核心 WebAssembly/围绕其更高的目标工作怎么办”在这里也可能很有趣，我相信很多人会同意我的观点，但当子组是 WASI，但我仍然想提高认识，因为包含或排除接口类型功能，例如，这是由同一组有效推动的核心提案，可以很容易地优先考虑 WASI 的需求，实际上是非-Web 某些语言子组，超过其他人的需要。 从我作为 OP 的角度来看，我可能已经目睹了后者，所以我认为仅仅对风险保持警惕并采取预防措施并不一定是一件坏事，因为特别是当一个小组的努力与对于大多数人的利益，在对核心 WebAssembly、更广泛的生态系统甚至更糟糕的 Web 标准造成损害之前，可能很难意识到副作用。 或者换句话说：我认为作为 WebAssembly 保护伞下的一个子组应该意味着对核心 WebAssembly 及其更高目标的责任。

我认为最好保守一点，将恶意归咎于各种群体，即使是假设性的；）

很多这些有争议的问题，特别是在 IT 提案中，并没有多少人密切关注，只涉及并被少数人看到。 对于高能见度的设计问题，很难做出大多数 CG 反对的决定，因为 CG 中或多或少有代表性的子集参与了设计过程，或者至少在没有反对的情况下跟随。 但是，对于小众问题，可以在几个人之间做出一个完整的 CG 会不舒服的决定。 在这些情况下，在 CG 会议上提出具体问题以了解 CG 对提议方向的全面了解可能会有所帮助。

最近的一个例子是@lukewagner提出了不允许重复导入的问题。 正如您所经历的，CG 对模块链接人员提出的方向并不完全满意，因此，讨论的参与度越来越高，共识也转向了不同的方向。

最终，CG 不会接受的提案不会由 CG 提出。 当然，越早提出和讨论问题越好。 我希望每个人在确定问题时都能在 CG 会议上提出问题。

首先要说明这一点 - 我认为与 Web 平台的互操作性对于 WebAssembly 的采用至关重要，我大致同意您关于兼容性的观点。 也就是说，我不确定在提案中增加进入壁垒会带来积极的结果。 WebAssembly CG 由社区中的人组成，他们都可以有不同的目标，同时为积极推进标准做出贡献。 拥有不同的目标有时会导致摩擦，我希望这是一个我们在朝着不同目标努力时可以尊重地不同意的地方。

有人建议我在更 CG 级别的论坛之前对 WebAssembly 的总体方向提出以下担忧，我现在正在遵循这个建议，希望我们作为一个社区最终能够永久解决这些问题。

有些人可能知道，我对 WebAssembly 目标的看法在很长一段时间内一直与负责各种提案的某个小组的想法发生冲突，这常常导致或多或少的激烈讨论。 所以我认为这里有机会找出分歧的根源并解决问题，这样我们最终可以再次朝着共同目标保持一致。 我只能从我的角度来说，在有兴趣在 Web 上运行 WebAssembly 和 _also_ 在 Web 下运行的人中更常见，这恰好正是我正在从事的工作，而且我对其他人的想法非常感兴趣。

从我的角度来看，分歧源于最初并且仍在宣传 WebAssembly 作为开放 Web 平台的一部分所引发的期望（我将在下面简称为“Web”）。 例如，已经多次表示 Wasm 并不是要取代（或损害）JavaScript，而是一种配套技术，所以我一直认为实现出色的兼容性是首要任务（对我来说也意味着：互操作性) 与现有的 Web，这是 Web 上普遍期望的目标。 或者，正如 webassembly.org 所述：

不幸的是，在所有这些激烈的讨论过程中，我的印象是，我对 WebAssembly 目标的理解与我在 CG 中更有影响力的对手正在努力的方向不一致，我不禁将其视为创造新地位的尝试quo 这在很大程度上排除了与 Web 的兼容性。 这种分歧显示的第一个问题是STRING i32 对 UTF-16LE在接口类型（2017 年，在创建时名为 Host Bindings），在 1 1/2 年的沉默之后，许多争论已经交换了关于是否 UTF -8，一种与 Web API 和 JavaScript 基本上不兼容的字符串编码，实际上应该是唯一受支持的编码，或者从一开始就考虑兼容性是否有用。 在我的书中，这应该是给定的，所以我对一连串相反的论点感到非常惊讶，反过来又助长了分歧。 最终（大部分）解决了这个问题，承认有这么多语言使用类似 JavaScript 的字符串编码，我们应该支持它，这反过来又导致了适配器融合的彻底概念，但几乎没有人承认与Web API 尤其重要。 在这个问题的背景下，当然还有更多非技术性的问题要讨论，但我建议我们暂时避免这些，并专注于 WebAssembly 的方向。

另一个类似的问题是字符串的 GC 故事？ 在 GC 提案上，到目前为止还没有解决，如果目标是我们都可以同意的 MVP，它可能也不一定必须解决。 然而，到目前为止的讨论还表明，我们最终必须解决分歧，即一旦 GC 可能以需要 WebAssembly 和涉及字符串的 Web API 之间互操作性的方式使用，可能还涉及任意模块图，理想情况下，只需最少的转换和复制。 普遍的分歧也显示在关于阵列更好的 GC 故事的后续问题中？ ，这很快就转移到质疑我的能力和我正在从事的项目的价值，而不是讨论手头的问题，我今天更多地认为这是长期误解的不幸后果。 如果有的话，它强调这里有机会再次在共同点上结盟。

我也对最近禁止重复进口的努力感到惊讶？ , 一种机制，可用于与 JavaScript 等动态语言集成，在这种语言中，多重签名很常见。 演讲结束后，在同一次会议上匆忙对罢免进行投票至少让我抬起了眉毛，但这很可能只是另一个误解，或者是对流程应该如何运作的分歧。

不代表任何人，但对问题进行投票在历史上一直是衡量社区意见的过程中有用的一部分，我不会将其解读为匆忙投票，更多的是对方向的民意调查。 如果你看一下注释，CG 决定我们需要更多地关注这个问题，设计问题仍然是讨论的地方。

同样，我最近开始质疑WASI 是否会损害 Web 上的 Wasm 用例？ ，在我看来，在社区中更多关注 Web 的部分有机会找到一种解决方案来促进与 Web 的兼容性而不是碎片化之前，它似乎建立了一种新的现状作为副作用，因为相关的提议不远足够的。 我个人认为，由于问题中提出的原因，那里的优先事项存在问题。 巧合的是，WASI 的努力是由 CG 成员推动的，他们早些时候反对我在接口类型上的观点，虽然相关性并不一定意味着因果关系，但它最终让我质疑 WebAssembly 的总体方向，让我们回到这个问题。

WASI 设计原则我相信你现在已经看得很清楚了，明确指出它不仅限于易于在 Web 上填充的 API，同时还明确指出 WASI 应该尽可能与 Web 标准一起使用. 正如@conrad-watt 早些时候指出的那样，核心语言和生态系统之间存在区别，它是主机可以选择不提供的命名空间。 WASI 作为一个生态系统有不同的设计目标，强制 web compat 成为他们的目标之一似乎对 WASI 试图解决的问题没有成效。

现在应该很明显了，我越来越担心，作为一个社区，我们没有做必要的事情来确保与 Web 的出色兼容性，同时容忍新的提议和相关技术破坏与 Web 的兼容性太多，或以其他方式对其产生负面、直接或间接的影响。 这让我想知道，例如，Wasm，或者至少它未来的自我，是否可能不应该成为 W3C 的推荐，因为它一次妥协了向后兼容性，这当然是一个极端的结论，但将是我认为，当分歧程度进一步增加时，我们将不得不问的终极问题。

该社区确实由几个从事 Web 标准工作或对 Web 进行大量投资的人组成。 虽然我听到了你的担忧，但我不确定未来是否会如此可怕。 您能否添加具体示例，说明向后兼容性已经以一种有意义的方式受到损害？

在此背景下，我今天转向 CG，请求讨论以下对 WebAssembly 总体目标的补充，以期减少未来不必要的摩擦：

一般来说，与开放 Web 平台的兼容性，尤其是 Web API 和 JavaScript，对于 WebAssembly 的长期成功至关重要，如果可以避免，就不能妥协。 对于推广并非主要针对 Web 的功能的提案来说，门槛尤其高，因为可能没有什么动机不对该目标产生负面影响。

简而言之，这是我一直倡导的更高层次的方面，如果我们能达成一致，并把它写下来，上面讨论中的大部分摩擦都会（大部分）过时，至少就我而言我很担心，同时恢复我对这个过程的信心。

这可能意味着什么：

• 接口类型很好，但是由于兼容性，JS 字符串编码很重要，并且在其上推广 UTF-8 以提供温和的压力或类似的，或者用所谓的趋势证明它可能是有问题的
• 线程、SIMD、i31ref 等都很好，因为这些是不相关的，只会添加功能，除非它们不再存在/不再存在
• GC 很好，但最终会被激励为互操作性找到合适的解决方案
• WASI 很好，但在进一步走碎片化路线之前，它会被激励考虑替代目前本质上是 libc 的东西
• WASI-nn 很好，但会受到激励，例如与Web CG 的机器学习合作

如果事实证明 CG 无法就使这样一段官方化达成共识，或者如果有必要对其进行重大修改，我会非常担心 Wasm 的未来，尤其是在成为 Web 标准的情况下，并建议重新- 更详细地评估我们的目标以及我们公开交流的内容。 在这种情况下，我们可能还想对这样的课程进行合法性投票，我想。

让我知道你的想法，谢谢！ :)

回到以流程的形式添加明确的进入壁垒在实践中效果不佳，并且考虑到您的担忧是关于已经在进行中的提案，即使我们从严格的流程角度确切地知道在哪里包含此文本，这不会追溯适用。 从历史上看，我们一直试图保持提案流程的轻量级，以鼓励前进，并委托 CG 做出有意义的决定。 如果假设 CG 没有善意运作，那么添加流程障碍只会到此为止。 根本没有说这就是你的意思，只是进入壁垒并不是解决所提出问题的特别好的方法。

@tlively似乎我在之前的评论中触动了神经。 不过，请稍等片刻，因为我确实相信，在避免不良结果或减少未来紧张局势是目标时，充分考虑这一点可能很有价值。 例如，另一个更微妙的假设极端情况可能是“如果一个同时负责核心提案的参与者延迟推进这些提案，以使具有不同目标的子组的结果有时间在更广泛的生态系统中蓬勃发展——虽然我们无法阻止它，我们会怎样？想劝阻它？”。 就像，我确实考虑了一段时间，但我想强调这都是假设的，提到它是为了更高的事业。 我只是不想通过保留可能与理解我导致它的思维过程相关的方面来削弱我在 OP 中的建议。 我认为这可能是另一个两难境地，我正在尽我所能做到尊重他人。 例如，我删除了我之前的回复，上面写着“感谢您指出这一点并如此支持，我很抱歉”，因为在考虑了我们可能缺少讨论的内容后，我不太有信心坚持自己的想法. 我希望这没问题，考虑到我认为什么是危险的？

@dtig 非常感谢您的彻底回复。 阅读它让我对 WebAssembly 的未来更有信心，也更相信我到目前为止的经验并不像我最初想象的那样能代表整个 CG。 我可以提供的示例主要基于我在 OP 中链接的各个问题的讨论，而不是像我现在意识到的那样对整个 CG 活动进行讨论。 “WASI 应该在可能的情况下与 Web 标准一起工作”也是我非常同意的一个方面，并且可能被误解了，因为在我看来，它似乎在下一句“它不是必需的”中被相对化了，因为 JavaScript，它是上下文，是这样一个 Web 标准，与我迄今为止在 WASI 相关问题上的经验不匹配（参见 https://github.com/WebAssembly/WASI/issues/402，其结果是类似 syslog 的界面）。 如果可以的话，我将不得不重新考虑一下这里的含义，但我有兴趣讨论这一点，然后可能会争论更高层次的观点，即 WASI 的设计原则不应该是不可协商的，就像我的印象一样到目前为止，由于 WASI 在 WebAssembly 的保护伞下不仅赋予它创建新 API 的自由，而且还暗示了对核心 WebAssembly 潜在间接影响（我想提高认识）的责任。

我认为WASI不是一个好的设计。 第一，为web虚拟机设计的web assembly，设计一些与posix兼容的API，不符合发展方向。 其次，引入第三方API更好的方式是定义接口（两个域之间的交互），这样既可以控制API的数量，也可以控制安全性。

另一个更微妙的假设极端情况可能是“如果一个同时负责核心提案的参与者延迟推进这些提案以使具有不同目标的子组的结果有时间在更广泛的生态系统中蓬勃发展 - 虽然我们无法阻止它，我们是否希望阻止它？它？”

我相信，如果提案中存在分歧，异议方可以将他们的担忧提交给对提案拥有权力的 CG。 采用需要在一个实现中交付，但它不需要在所有实现中交付（我认为两个是数字，但我有一段时间没看它了）。 只要有实现，我不确定这将如何使某人能够违背其他人的意愿推迟提案。

@penzn不幸的是，如果过程完美，我们就不会在这里。 作为一个例子，我们可以看看我对 WASI 设计原则的不同意见。 我不知道如何正确处理这些问题，因为 WASI 在很大程度上是独立的设计，它所服务的当代大多数人认为这是一件好事，所以只能在 WASI 本身提出更大的问题，但我的印象是提出问题在 WASI 使用 WASI 不太可能导致解决，因为 WASI 的大多数人自然希望 WASI 保持原样，这是可以理解的。 例如，我已被送回 Interface Types，即使它是同一组并且他们知道我在那里遇到的麻烦，而且我经常指出的是“与 WASI 的设计原则不兼容”，仅此而已。 所以我试图找出更高层次的问题，在我看来，这归结为 WASI 被合法化，几乎无法与核心 WebAssembly 的目标保持一致，同时又不对核心 WebAssembly 的目标负责。 所以我建议调整这个过程，因为我要么不能使用这个过程，要么觉得没有能力这样做。

请参阅 2021-04-28 CG 会议上的 C API 安全性讨论，类似的情况是在提案中​​没有解决演示者的问题。 当然，WASI案例的不同之处在于它不是提案，但CG应该仍然具有程序权限。 在 C API 安全的情况下，在 CG 站在反对者一边后，提案的拥护者不得不接受提出的具体问题，但我相信你也可以在最后不投票地提出。

很抱歉，但我看不出“C API 的安全性”如何与更宏观的问题相提并论。 你能详细说明吗？ 例如，我觉得我在 WASI 上做一个支持 Web 的演讲只会更加激化分歧。 正如@dtig所说，这样做“似乎对 WASI 试图解决的问题没有成效”。

在 C API 安全辩论中，关于目标和需求（是否需要对不安全语言的 API 进行检查）也存在高层分歧，这在 CG 讨论中得到了解决。 这是一个开放的标准——提出建议和开始讨论是我们真正必须改变它的唯一工具。

关于生态系统问题的一些想法：我同意 Web 和服务器 API 之间的碎片化是一种风险。 随着 WASI 的加入，我们现在有两组标准化的 Wasm API，并且没有明显的统一路径，因为我个人怀疑浏览器是否会采用 WASI，并且鉴于 WASI 的存在，反过来似乎也不太可能。

如果 WASI 专注于将 Web API 移植到服务器，对 Web来说会更好。 但这并不意味着整个Wasm会更好。 我很欣赏与 Node.js 的比较以及那里的 API 历史，但我认为它是双向的：是的，Node.js 使用更多的 Web API 会很好，但也许 Node.js 的巨大成功部分归功于无论网络如何，都可以添加他们需要的 API。 也许 WASI 是 Wasm 在服务器上取得成功所必需的——考虑到 Web 和服务器生态系统的不同，API 碎片化可能是不可避免的。

这就是为什么我个人在 WASI 开始时没有批评它的原因之一。 虽然从 Web 的角度来看，它并不是最优的，但它对于 Wasm 在服务器上的成功可能仍然是必要的，这可能对 Wasm 的整体成功有好处。 （第二个原因是 WASI 的安全模型很有趣，也可能有助于 Wasm 蓬勃发展。）

更一般地说，除了 Web 和服务器之外，Wasm 正在以多种方式进行扩展，例如插件、沙盒解决方案、区块链等。 作为一个主要在一个领域工作的人，我不想批评在其他领域工作的人。 我们不应该让彼此慢下来。

我认为唯一的例外应该是非常严重的危险，无论是碎片化还是其他。 我目前没有看到这样的危险。 虽然拥有两个标准 API 会使一些事情变得尴尬且不太理想，但我们已经可以 polyfill server -> Web，最终我们也将能够做到 Web -> server，这将有所帮助。 对于字符串之类的问题，我认为预导入允许在 Web 上最终优化字符串使用——这也将使 Wasm 中的 API 碎片更加明显，但在这种情况下，由于无法跨越的语言差异，它是预先存在的。 总体而言，这些风险是真实的和令人讨厌的，但它们似乎是可控且不可避免的。

好的想法， @kripken ，这些都符合我对替代方案的理解。

关于 Node.js 的比较，我特别想到的是Buffer与Uint8Array之类的东西，它们仍然负责 Web 上的许多（慢）polyfilling。 或者可避免的global与window签入所有其他可移植模块。 或者TextDecoder暂时不是全局的，以减少启动时间。 或者crypto.getRandomValues仍然无法在全球范围内使用。 或者直到今天 ESM 支持的所有陷阱。 我认为 Node.js 在某些地方可以做得更好，而对fs等的支持可能是不可避免的。

在 WASI 中，情况似乎很相似，因为我们很可能需要一个 WASI 文件系统，但是还有其他 API 提供跨生态系统的通用功能，这些 API 首先是创建可移植基础模块所必需的，我认为我们可以比目前的方向做得更好。 例如，想象一个模块在出现问题时写入控制台，获取当前时间等，其中依赖（完整的）WASI polyfill 似乎是矫枉过正。 我想一些模块仍然需要一个随附的 polyfill，用于（仅）Web 上的 WASI 文件系统，我认为这确实是可以管理的。 我只是不认为我们在这里处于全有或全无的情况，但有很大的合作空间最终将在“但设计原则”方面得到回报。 我的论点是：如果可以，我们可能应该，如果我们需要稍微调整流程以适应它，那么我们也应该这样做。

关于预导入，我个人不太喜欢依赖这些进行非常基本的互操作，因为我认为字符串非常重要，以至于在这个级别上的分段已经不是我们最终想要的。 例如，您在其他地方提到，需要可移植性的生态系统最终可能会收敛到使用 JS 字符串，不是因为这样做很好，而是出于绝对必要。 我想尤其是那些以前不同意我的人，对这样的结果不会很高兴，包括我自己。

也许在上下文中有些相关，摘自 Deno 的最新博客文章，其中提到了服务器端碎片和遵守浏览器 API 的价值：

将 Web 编程扩展到浏览器之外并不是一个新想法。 事实上，我们在“Node.js”项目中取得了一定的成功。 但十多年后，我们发现服务器端 JavaScript 已无可救药地支离破碎，与糟糕的基础设施紧密相连，并且由没有创新动力的委员会不可撤销地统治。 随着浏览器平台的快速发展，服务器端 JavaScript 停滞不前。

Deno 是我们为这个生态系统注入新活力的尝试。 提供一个符合浏览器 API 的现代、高效的编程系统。 Deno 不是一个单一的系统，而是一组我们认为可以重新用于各种需求的技术。 并非服务器端 JavaScript 的每个用例都需要访问文件系统； 我们的基础设施可以编译出不必要的绑定。 这使我们能够为不同的应用程序创建自定义运行时：Electron 风格的 GUI、Cloudflare Worker 风格的无服务器函数、数据库的嵌入式脚本等。

这当然不完全一样，但他们可能仍然可以从他们学到的教训中学到一些东西。

绝对是一篇相关的文章，是的。 它的另一个关键引述：

我们认为，许多开发人员更喜欢 Web 优先的抽象层。

Web -> 服务器填充（如前所述）很重要的另一个原因。

旁注：我已经勾勒出一个构建块来解决我在基本级别上看到的 WASI 和碎片化的部分问题，命名为System Essentials for WebAssembly ，但想知道你对这样的事情之前是否听起来不错提出任何建议（随时在那边提出问题）。 如果有人像我一样看到它的价值（或者甚至想共同倡导/提供指导），请告诉我。 如果没有，我会对能够达到类似效果的替代想法感兴趣:)

快速浏览一下您的文档，“必需品”列表完全由系统_功能_组成。 默认情况下提供它们意味着环境功能的存在，从而破坏了 Wasm 精心设计的沙盒模型。

此外，即使在今天托管 Wasm 的环境中，也不能期望该列表中的任何功能都可以普遍使用。 例如，在区块链等去中心化系统上，当前时间（更不用说当地时间）、随机性和日志记录都不可用。

默认情况下提供它们意味着环境功能的存在

也许就像记忆的存在一样。 似乎没有那么不同。

并因此会破坏精心设计建立的沙盒模型。

我认为，只有内存或不同硬件（FP，宽松的 SIMD）上的非确定性也能做到这一点。 我不打算也不认为文档会“破坏” Wasm 的“精心设计”。

不能期望该列表中的任何功能都可以普遍使用

Wasm 二进制文件在某些​​机器上运行，在某些操作系统上带有一些 VM，所以我不同意这里。 我认为期望这些普遍可用是合理的，即使特殊用例可能希望限制它们的使用。

例如，当前时间（更不用说当地时间）、随机性和日志记录在区块链等去中心化系统上都不可用

以区块链为例。 到目前为止，这些通常不允许浮点数学运算，并且可能同样不允许获取时间或决定丢弃日志消息，但节点仍然在某些操作系统上的某些 VM 中运行。 我还要说这取决于分类帐的确切用例，因此很可能存在不需要限制的用例。 无论如何，我认为 Wasm 无法从纯粹意义上解决这个问题。 另一个极端是内存不足一页的物联网设备，具有不同的含义。

总的来说，我认为在如此重要的层面上与碎片化作斗争是有价值的，我显然有兴趣仔细考虑这一点，即使结果与我的文档中概述的完全不同（我可以扔掉它），但最终达到可比的东西。 就像一个建设性但消息灵通的妥协。 因此，我很想听听您对我们如何共同实现这一目标的想法，也包括个人的想法，因为这会让我觉得我的想法被我钦佩的人认为他们的技术专长很有价值。

无论如何，最好将此讨论转移到我的文档的存储库、Discord、电子邮件或语音聊天中。 所以请这样做（或在效果最好的地方联系我），如果这也是你的印象:)

我确实认为不让 WebAssembly 核心规范对其执行环境做出任何假设是有价值的，包括存在操作系统或时间或日志记录的环境概念。 对于任何依赖于或改变 Wasm 形式语义之外的状态的东西，Core 规范将导入的函数划分为包罗万象的逃生舱口，但当然没有指定将提供任何特定的导入集。

总的来说，我认为在如此重要的层面上与碎片化作斗争是有价值的

我认为这是该线程分歧的症结所在。 就个人而言，我强烈认为 Core Wasm 规范尝试提供统一的生态系统应该不是目标，但它应该尝试为纯计算提供尽可能便携（和高性能）的抽象。 打个比方，X86 和 ARM 都没有试图提供统一的生态系统（甚至是统一的 ABI）； 这留给了位于它们之上的操作系统抽象层，我认为该模型也适用于 WebAssembly。

话虽如此，在可能的情况下避免生态系统碎片化显然很有价值，但我认为应该在 Core Wasm 之上的一层完成。 这个生态系统统一层的明确候选者是 WASI。 如果您确定的基本功能由专门设计用于在 Web 上和 Web 外使用最少的胶水的 WASI 模块提供，它会起作用吗？ 当前的 WASI 时间和随机性设施在哪里不足？

也许这就是我们所需要的：一组标准化的 _optional_ 进口； 在 Web、大多数 WASI 系统中可用（因为它们是可选的，并且 WASI 可能在受限的嵌入式环境中运行），以及任何可能_可选_提供标准导入的地方。

在 Web 中，这将是_as if_ JS 胶水代码传递它们，但不是，系统传递它们并且 JS 开发人员不需要做任何事情，或者只需按名称列出它们以便选择哪些可用。

Web 开发人员可以理所当然地认为存在某些导入（或在 JS 端选择），但这并不强制 Wasm 本身在语言中使用它。

例如，区块链环境可能不提供（可选）导入。

用户应该负责了解他们在哪个环境中运行以及记录了哪些导入可用。

这意味着不需要编译器开关来输出不同的 API 调用。

WASI 将是两件事：标准导入的提供者，以及专门的仅服务器导入的提供者。

我认为在没有任何 JS 的情况下在 Web 上提供标准导入的问题是一个稍微不同的问题（但@dcodeIO ，如果您不同意，请告诉我）。 即使给定了一组在 Web 内外使用的标准导入，当前的 JS API 仍然需要编写 JS 来编译和实例化模块，因此 Web 开发人员让一些隐式导入的边际收益很小。 给定一组标准的导入，它们可能由诸如 ESM 集成提案之类的东西隐式提供，但这里的问题是我们还没有这样的标准导入集。

@dcodeIO

我认为 System Essentials 的想法很有趣，但我不同意它们的新标准。 最理想的情况是他们可以加入 WASI（正如@tlively所说），或者是 Web API。

关于 Web API：关于获取需要新 Date 对象的时区的链接中的公平点。 这在wasm中很麻烦。 但是可以使用 JS Reflect API（特别是Reflect.construct ）。 我们可以根据需要在 JS 或 Wasm JS API 端添加更多此类 API。 仍然需要声明导入，但代码大小成本应该是最小的。

关于 WASI API，我坚信我们需要做更多的工作来弥合 Web/WASI 的鸿沟。 向 WASI 添加更多对 Web 友好的 API 对我个人来说是有意义的 - 可能类似于 System Essentials。 上个月我描述了另一个可能的方向，并提出如果有兴趣可以勾勒出具体细节，但尚未收到 WASI 人员的回复。 反馈将非常受欢迎！

对我来说关键的一点是，对于 Web 上的基本功能和 Web 上/外的通用功能不应该有必要的胶水代码，因为我相信一个依赖于强制性 polyfill 来实现非常基本功能的生态系统不是我们应该努力的为了。 我也希望我们可以找到一种双向的方法，既不需要在 Web 上也不需要在 WASI 中使用 polyfill，以实现双赢（尽管从 Web 上填充 Web API 的问题可能会更小——但我'宁愿为两者做点什么）。

这就是我有点缺乏“系统要点”指令想法的来源，主要基于我迄今为止的观察，由于前面提到的原因，添加导入命名空间可能不会在浏览器中发生，所以我的直觉可能是指令实际上可能即使有很好的论据反对，问题也不会那么严重。 我同意你关于保持核心 Wasm “核心”的观点，并希望我们可以在核心 Wasm 之上做一些更好的事情，同时适用于 Web+WASI。

因此，我并不特别关注我的特定想法，并且会很高兴在 [x] 的方框中打勾的任何东西都可以消除胶水代码，无论是通过指令，一个通用的导入命名空间 on+off the Web（WASI 与否） ，或间接通过 ESM 集成并在 Web 上支持其中的一部分，从而我们最终实现 [x]更少的碎片（相同的模块在仅使用通用功能时无需 polyfill 即可在 Web 上和 Web 上运行；在文件系统和 DOM 上划清界限，这是相当特定于环境的）。 那有意义吗？ :)

另一个想法：也许我们的对话可能有助于了解子语言的想法——比如“web+wasi”的“个人资料”或类似的东西？ 然后可以归结为标准化子语言 API 表面之间的交集。

此外，由于这个问题已经开放了将近一个月，可悲的是几乎没有任何 IT/WASI 人员加入进来以改善这种情况，因此我决定尝试自己进行冲突分析。

我想强调的是，以下内容非常主观，实际上仅代表了我对 Wasm 环境的新兴心理模型。 这并不意味着任何人都在做坏事，只是有不同的关注点，这是很自然的。 如果您觉得受到不公平对待，请告诉我，这不是我的本意，我会更正或删除。

我的目标是确定 Wasm 参与者之间的一致性或缺乏一致性，无论是在使 Wasm 更丰富方面，即包含更多功能和用例，分别保持其纯粹性，即强调最小 ISA 的点，同时还包含专注于硬币的某些方面，这里主要对在 Web 平台上分别在边缘或区块链上运行 Wasm 感兴趣，通常有非常不同的要求。

• 浏览器：服务于本质上相当丰富的Web平台。 “新的桌面操作系统”可以这么说。
• 服务器：本质上相对准系统，例如“自带东西”。 中性的。
• 研究：想让 Wasm 对每个人都有好处，除非附属于其他演员。
• 谷歌：专注于将东西移植到网络并使其快速； 只要不损害他们的需求，就可以考虑其他人的需求？
• Dfinity：全押在区块链上； 显然需要一些丰富的功能； 但是准系统越多越好吗？
• 快速：以边缘为中心； 精益/最小 VM 对他们的产品至关重要； 有效地负责 IT/WASI？
• Apple：对适用于 Web 的方法还不错； 不一定渴望与应用商店竞争？
• AssemblyScript：想要现实世界的实用性； 倾向于 Web，但由于 Edge/BC 上的利益相关者而有些模糊？
• 英特尔？：目前迹象不多； 对高效计算最感兴趣？
• Redhat?：到目前为止还没有很多迹象； 主要对基础设施感兴趣？
• 微软？：目前迹象不多； .NET 在 Web 上并最终无处不在？
• Mozilla？：不存在？

虽然这在很多层面上都可能是错误的，但我发现它相对较好地说明了我的心理模型。 我还画了一条线，我认为“WebAssembly 中的 Web”会根据我的期望发挥作用，但这又是有争议的。 如果有的话，我希望它有助于理解我来自哪里以及为什么我会觉得 Wasm-land 出了问题，同时也为那些对我对这个问题的浓缩观点感兴趣的人提供了一些启示但可能不知道发生的每一个细节。 拿，但要加一粒盐:)

两便士……我真的很惊讶这次谈话竟然发生了。 对于 WebAssembly 来说，允许其范围由早期采用者碰巧提出的任何用例来定义总是一个坏主意。

Web 需要 WebAssembly 的方式是其他平台所不具备的，因为 Web 必须限制其开发人员可以做的事情，尤其是在 WebAssembly 级别。

如果 WebAssembly 朝着加密矿工不喜欢的方向发展，他们可以分叉或其他方式。 这不是我们在设计 Web 标准时需要关心的事情。 其他所有人都可以完全控制底层平台。 在网络上，我们只有给定的平台，一旦它成为标准，我们就会永远坚持下去。

WASI 应该被分叉来做自己的事情，Web 应该有自己的虚拟机，它专门针对浏览器进行了全面优化。

对于 WebAssembly 来说，允许其范围由早期采用者碰巧提出的任何用例来定义总是一个坏主意。

实际上，它的范围是由 CG 定义的，任何人都可以加入，包括你。 在那里，人们投票决定方向，如果你想花时间积极参与其中，就会受到影响，并提出经过深思熟虑的技术论据。

如果愿意，任何人都可以分叉 Wasm，但是共享生态系统有很多优势，所以这是最感兴趣的各方所追求的。

每个人都能够加入 CG 意味着您无法阻止对 Web 没有兴趣的人加入，恐怕。

我真的很惊讶这次谈话必须发生。 对于 WebAssembly 来说，允许其范围由早期采用者碰巧提出的任何用例来定义总是一个坏主意。
...
WASI 应该分叉做自己的事情

WASI _is_ 做自己的事； 这是一个导入命名空间。 它没有被标准化为与 WebAssembly 语言功能相同的水平。 我们应该宣布非 Web 功能超出范围并且不允许 WASI 规范在社区组的名义保护伞下发生的建议吗？ 在防止碎片化方面会取得什么成就？

调查 WASI 的某些部分是否可以调整为更整洁的 shimable 是有好处的（ @kripken在这里列出的 Web->WASI 或 WASI->Web），但即使在最坏的情况下，我们也只是最终得到无法在 Web 上导入的 API，就像 WASI 是作为非 Web 运行时的第三方项目完成的一样。

同样，阅读@dcodeIO链接的问题，我没有看到任何人认为 Web 对 WebAssembly 不重要。 我所看到的只是人们在功能/路线图上存在分歧（有时是不礼貌的），以解决非常具体的互操作摩擦，如字符串编码。 我坚信，将这些技术分歧描述为 Web 与非 Web 权力斗争的证据是错误的，这样做不会产生任何积极的结果。

我不认为这是一场权力斗争，而是范围过于广泛和有效开放的问题。 万维网非常重要，它拥有自己的虚拟机，有自己的规范和标准，按照自己的条款，使用自己的命名法。 将所有内容都概括和抽象化的尝试导致了对 Web 开发人员不熟悉且通常陌生的规范、文档和对话。

需要明确的是，WASI 成为官方项目的问题纯粹是象征性的。 它没有技术上的区别，但它的状态清楚地表明 Web 使用 WebAssembly，但它不是由 Web 和为 Web 创建的技术。

我不认为这是一场权力斗争...

@7ombie道歉，我的最后一段主要是对上面的“冲突”图进行评论。

将所有内容都概括和抽象化的尝试导致了对 Web 开发人员不熟悉且通常陌生的规范、文档和对话。

我同意关于接口类型的一些技术期望已经变得非常深奥。 在 CG 中肯定有对话空间，例如“为什么是接口类型而不是一流的字符串类型”，我们依靠像@dcodeIO这样的以 Web 为中心的开发人员分享他们的意见和关注点，以保持流程正常运行。 我对上次谈话结束的方式感到沮丧，我希望我们将来能做得更好。

明白了，@conrad-watt。 我还没有看到那个对话，但就我而言，我不想参与 Web Vs。 非网络思维，或类似的东西。 我只是分享个人对我通常非常满意、兴奋和感激的技术的抱怨。

我之前的评论非常批评和公然，但我只是随便。 我不难过。

@conrad-watt 等人。 接口类型技术描述可能会在不久的将来变得更加深奥之前变得更加深奥。 作为解释，这在很大程度上是出于将可重用性与严谨性结合起来的愿望。

我想强调的是，我也看到了尽可能多地（与 WASI 和其他人）合作的价值，因此我建议以涵盖交叉点的方式研究导致生态系统之间可移植性的解决方案，包括我在哪里'd 当前画线（DOM，文件系统）。 我知道我的建议可能很难，或者可能有更好的方法来实现类似的目标（让我知道！:)）。 就是这样（在 OP 中引用我自己的话）

我越来越担心，作为一个社区，我们没有做必要的事情来确保与 Web 的出色兼容性，同时容忍新的提议和相关技术过多地破坏与 Web 的兼容性，或者以其他方式影响它消极地、直接地或间接地。

导致我建议通过明确说明以某种方式重新评估我们的目标

一般来说，与开放 Web 平台的兼容性，尤其是 Web API 和 JavaScript，对于 WebAssembly 的长期成功至关重要，如果可以避免，就不能妥协。 对于推广并非主要针对 Web 的功能的提案来说，门槛尤其高，因为可能没有什么动机不对该目标产生负面影响。

我不再像在 OP 中那样将其作为提案的要求（正如暗示的那样），因为我同意提出的许多观点，但仍然希望集中努力有效地改变我们朝着那个方向。

@dcodeIO ，您的冲突分析中可能的讨论项目是什么，您列出的所有公司都需要透露和比较他们的计划吗？ 您认为这是可能的吗？它将实现什么目标？

虽然无法真正评论图表中的任何公司，但我认为这样比较它们会产生误导，因为没有任何一个实体能够在没有其他人同意的情况下为自己改变标准。 我还发现图表轴是主观的和令人困惑的。 例如，在 web 上的 wasm 中运行计算（比如说渲染或 NN）应该是“边缘”，因为它将计算从“云”向下移动，但它也应该是“网络”，因为这是一个关键部分现在的交互式网络（绝对不是“服务器”，因为它在客户端机器上运行）。 另一个维度是更主观的 IMO，因为您定义中的纯粹性和丰富性是相对术语。 示例 - 关于 Go 的调用约定所激发的控制流限制的讨论非常长。 根据您询问的对象，这些限制将被视为有用的功能还是不必要的，我认为这会影响该人将讨论放在“富与纯”轴上的位置。

要问一个直接的问题，WebAssembly 的长期方向是由采用它的人定义的吗？ 例如，如果从长远来看，Web 开发人员的采用率很低，但有数十亿投资的大型工业参与者将 WebAssembly 用于与 Web 无关的事情，他们的需求最终会优先考虑吗？

要问一个直接的问题，WebAssembly 的长期方向是由采用它的人定义的吗？ 例如，如果从长远来看，Web 开发人员的采用率很低，但有数十亿投资的大型工业参与者将 WebAssembly 用于与 Web 无关的事情，他们的需求最终会优先考虑吗？

我们是一个社区/共识驱动的标准。 考虑这些假设情况并没有多大用处，因为从根本上说，它们不能通过任何形式的正式程序来防范。 欢迎来到社区/建立共识的存在焦虑。

是的，如果唯一关心 Wasm 的人是核心边缘计算工程师，那么该语言很可能会朝着这个方向发展。 在这种情况下，即使我们设法以某种方式将一条原则铭刻在石头上，即只有与 Web 兼容的功能才能在 CG 中标准化，这只会导致分叉，或者没有人在使用该语言。

需要明确的是，我绝对不相信这是我们所处的情况。一个人要么必须相信 CG 成员充分代表了 Web 的利益，要么自己参与其中。

看，这是我不明白的事情。 目标显然是最终在 W3C 的保护下产生一个 Web 标准，该标准具有非常明确的原则和价值观，并且在类似挑战的长期历史中积累了很多经验。 我不认为 Web 的领导者和每个有分支的人都与 Web 人想出的东西保持一致，如果那是他们想要的，会更糟。 所以，是的，我建议首先为 Web 创建 WebAssembly，然后再为其他所有内容创建 WebAssembly，因为如果我到目前为止的经验值得的话，相反的情况是无法忍受的。 无论需要什么，我们都应该考虑并讨论它，因为我认为这是问题的根本原因。

正如我上面所说，虽然我同意 Web 应该是 WebAssembly 的优先事项，但我不认为您与其他 CG 成员的技术分歧主要是由于 Web 与非 Web 派系分裂. 即便是纯粹关注 Web 的人也愿意为您的几个提案寻求替代方案，这是有原因的，您不应该将此解释为不同意您的人不关心 Web 的证据。

WASI 不会成为 W3C 规范，它不会干扰我们生产 W3C WebAssembly 规范。 声明 WASI 不应该在 CG 下开发，因为它是“非 Web”，不会导致相关人员将注意力转向 Web。 它只会关闭有价值的沟通和协作线路，这可能（例如）允许我们找到与一些假设的 Web 友好 API 的重叠。

公平点，但那时我们根本不同意，因为我无法将你的立场与我所经历的一切相调和。 我认为已经有非常明确的迹象表明问题存在并且必须解决，而不是不断地告诉我我们对此无能为力。 对我来说，这似乎很荒谬，以至于人们应该为他们对 WebAssembly 所做的事情感到羞耻，WebAssembly 曾经是 Web 标准中最耀眼的明星，但显然没有达到它曾经的目标。

我认为已经有非常明确的迹象表明问题存在并且必须解决，而不是不断地告诉我我们对此无能为力。

我认为我们没有抓住这个问题，而不是决定对此无能为力。 显然人们对改进 WASI 或接口类型很感兴趣，但对于那些从根本上被破坏或错误的东西似乎并没有达成共识。

感谢您解决问题 :) 我想为我在这里的崩溃道歉，这不好，我希望自己能做得更好。 我想继续与小组互动，包括讨论这个（我认为）重要的问题，我希望表明我可以以建设性的方式做到这一点。

作为开始，我提出了一个关于我对字符串编码的担忧的演示文稿，我认为这与接口类型的后续步骤相关，即最近向组件模型的发展。 在此过程中，我们最终决定尝试一种新的预录演示格式，讨论时间安排在 6 月 22 日的 CG 视频会议上。 录音可以在此评论上方链接的随附问题中找到，我希望它有助于以更简洁、更有建设性的方式提供必要的背景。

如果我可以提供一个轻松的建议：如果有人要在 Binaryen 或 Rust 中重新编译 Web 浏览器源代码的非 WASM 部分，并在桌面上定位 WASI，是否可以说大多数浏览器只是一个大的填充物，还是只是将争论转向自身，导致灾难性的崩溃并将地球变成一个黑洞？

严肃地说：IIRC，网络最初是 Tim Berners-Lee 爵士在 CERN 的电话目录的超链接文档。 Web 本身超出了所有预期，包括复杂性和内存消耗。 Web 浏览器已经从一个文档查看器演变为一个完整的发布媒体。 那就是特征蠕变。

WASI 作为一种编程环境，有可能让网络技术回归其作为计算机科学分支的根源，其中出版和交互性融合在一起。 从什么时候开始聊天室必须在浏览器中运行才能成为一种网络技术？ 无论如何，最初的聊天协议 IRC 的存在时间比网络浏览器要长。 同样，SMTP 早于 WWW，FTP 也是如此。 互联网不仅仅是网络，它应该是这样的。