# 标准反对
在特殊情况下，当不再认为协作能够最终解决问题时，AssemblyScript 可能反对 WebAssembly 标准化背景下的个别努力。此页面涵盖我们的反对意见及其相关背景。
# W3C WebAssembly 工作组和社区组
经过深思熟虑，AssemblyScript 认为 WASI、衍生提案、W3C 对其子组的认可以及 Bytecode Alliance 的实践，并非其所有成员都必然知悉和/或认可，对开放标准总体而言以及对 WebAssembly 规范而言都是有害的。
# WASI，2022-09
WASI (在新窗口中打开) 是一个适用于非 Web WebAssembly 的类似 POSIX 的导入命名空间，它提供了一个 外部函数集 (在新窗口中打开)，例如 fd_write，其灵感来自在 C++ 和 Rust 等系统编程语言中公开的低级层，但在 Web 平台上却没有。WASI 被 宣传为 (在新窗口中打开) 一个标准 (在新窗口中打开)，与官方的 W3C 标准化工作紧密相邻，与 WebAssembly 的范围 (在新窗口中打开) 和 高级目标 (在新窗口中打开) 几乎没有重叠，并且由一个强大且大部分独立运作的 W3C 子组管理，该子组致力于实现 特定自定义目标 (在新窗口中打开)。随着时间的推移，WASI 子组扩大了其范围，设计了 自己的提案 (在新窗口中打开)，其中部分与已建立或当前制定的 Web 标准竞争，如今在标准目的的紧张局势中促进碎片化。作为脱节的一部分，我们已经接触到一种滥用权力的操作模式，当我们表达担忧时，我们的代表遭到系统性歧视，他们的担忧被压制，例如，由 WASI 主席 在附带贬低性回顾的借口下 (在新窗口中打开)，结果是表达的担忧未得到解决。
总而言之，WASI 和 WASI 小组让其他参与者几乎不可能 进行 (在新窗口中打开) 努力 (在新窗口中打开)，这些努力与 WebAssembly 的目标一致，其中许多目标如今仅存在于纸面上，让更广泛的社区感到震惊，而 WASI 的概念和想法继续渗透到 WebAssembly 的方方面面，推动着过早的生态系统分裂，讽刺的是，这种分裂是通过标准本身进行调解的。
我们对 WASI 与 WebAssembly 的高级目标 (在新窗口中打开) 和价值观的几个方面的关系评估如下。
| 传达的技术目标 | 评估 |
|---|---|
| 可移植的 虽然它可以 进行填充 (在新窗口中打开)，但 WASI 并非针对高级语言/Web 的合理可移植抽象。 | 违反 |
| 对 C/C++（和 Rust）以外的语言的支持 本来自然适合 Web 平台的语言不仅被忽视，而且 WASI 自行强加的回避 Web 概念的做法，破坏了其他语言与 JS 和 Web 平台之间互操作的潜力。 | 违反 |
| 在现有的 Web 平台中执行并与其良好集成 WASI 并没有与现有的 Web 平台集成，而是从根本上与之竞争。 | 违反 |
| 保持 Web 无版本、功能测试和向后兼容的演进故事 WASI 的概念与 Web 平台概念不 向后兼容 (opens new window)。 | 违反 |
| 在与 JavaScript 相同的语义环境中执行 WASI 的语义从根本上不同于 JavaScript 的语义，实际上建立了一个替代宇宙。 | 违反 |
| 通过与 JavaScript 可访问的相同 Web API 访问浏览器功能 WASI 不关心 Web API 和 JavaScript，其团队拒绝考虑它们的存在。 | 违反 |
| 推广其他面向 WebAssembly 的编译器和工具 WASI 扼杀了其他编译器，并通过引入低效和不兼容性来破坏其他语言。 | 违反 |
| 传达组织价值 | 评估 |
|---|---|
| 章程 (opens new window) WASI 对范围、参与、沟通和决策政策的坚持总体上令人质疑。具体而言，WASI 的交付成果当然不“与 JavaScript 和 Web 优雅地互操作”。 | 违反 |
| CEPC (opens new window) WASI 小组系统性地滥用 CEPC 来“赢得”失败的论点。 | 违反 |
总结来说，WASI 与 Web 标准（特别是 WebAssembly 规范）的技术目标和组织价值几乎没有重叠。其小组营造了一个歧视性和排斥性的环境，以利于自身，并偏袒地强化其技术偏见。我们认为，WASI 小组故意使用这些做法是为了 严重不利于其竞争对手 (opens new window)，他们心甘情愿地冒着整体标准化工作严重受损的风险。
我们已经表达过但仍未得到解决的具体技术或相关问题是
- 对于自然适合 Web 平台的语言，WASI 导致 Wasm 中出现 垫片 (opens new window)，由于缺乏替代方案，JS 中出现 polyfill，两者之间存在概念上的断裂，这表明它不是支持许多编程语言的正确抽象。
- WASI 强制使用 Web 上不常见的概念（例如 字符串），这些概念从根本上与 Java 类语言和 JavaScript 不兼容，这表明当与现有 Web 平台的兼容性是目标时，它不是一个合理的抽象。
- WASI 在 Web 平台上可用的功能上引入了冗余，这些功能在 WASI 之上以不同的方式被急切地实现。
- 过度使用 WASI 会导致 Web 上/在浏览器中 WebAssembly 代码膨胀，而代码大小可以说是最重要的事情。
- WASI 通过引入为不同环境重新编译模块的要求来促进碎片化。
- WASI 通过急于扩展其范围并独立设计竞争 API 来促进碎片化。
尽管如此，我们仍然愿意考虑将 WASI 作为自定义工作重新纳入，前提是满足以下条件
- 将 WASI 代码库和场地从 W3C/WebAssembly 组织迁移到
- a) 清楚地表明其不一定是面向多种语言的、非 Web 方式，以及
- b) 结束对所有其他努力的认可造成的负面影响。
- 明确沟通 WASI 不关心 WebAssembly 的许多总体目标和现有的 Web 平台。
- 承认错误并真诚地道歉，以减少对受歧视、失去声誉和被排斥的人的伤害。
- 在解决这些条件时，要展现良好的意愿和诚实，避免政治技巧。
我们建议 WebAssembly CG 确保在任何情况下都满足第一个条件，因为我们预计如果未能做到这一点，将延长认可产生的新兴政治属性，这些属性违背了理性和建设性的技术讨论。
# 组件模型，2022-09
与 WASI 相同的考虑因素也适用于其 组件模型 (opens new window)，这是一个针对所有 WebAssembly 定义“可移植、虚拟化、静态分析、能力安全、与语言无关的接口，*尤其是那些由 WASI 定义的接口*”的提案，虽然它没有明确说明，但知情者却恰当地将其称为“WASI 组件模型”1 (opens new window) 2 (opens new window) 3 (opens new window)。组件模型不仅将 WASI 的偏好确立为标准的基础，而且几乎悄无声息地取代了长期期待的提案，例如 JS+DOM (opens new window)、WebIDL 绑定 (opens new window) 和 接口类型 (opens new window)，尽管 Wasm/JS 互操作性的改进通常被认为是显而易见的优势，但令人惊讶的是，它仍然缺席于 WebAssembly 平台。到目前为止，我们还没有看到任何可靠的证据来支持从绑定到不同范围的组件模型的转变，并怀疑存在战略原因。
我们对组件模型与 WebAssembly 的几个高级目标和价值观的评估与我们对 上面关于 WASI 的评估 相同，而组件模型影响所有 WebAssembly，同时违反了兼容性和安全性等重要属性。我们对组件模型与 其自身目标 (opens new window) 的关系的评估如下：
| 传达的技术目标 | 评估 |
|---|---|
| 可移植、跨语言的组合 如果所有涉及的语言都是 Rust 类语言，则有效。在所有其他情况下，包括与 JS/Web API 交互时，都会出现问题。 | 违反 |
| 语言中立性 组件模型只支持一类编程语言——正是它声称要避免的偏见。 | 违反 |
| 形式语义 组件模型没有在与核心 Wasm（即 Web 平台）相同的语义框架中定义。 | 违反 |
| Web 平台集成 组件模型破坏了 Web 平台对本来自然适合的语言的集成。 | 违反 |
我们已经表达过但仍未得到解决的具体技术或相关问题是
- 组件模型不必要地限制了其概念（例如 字符串），通过面向目标的设计选择（如其“规范 ABI”）或“外部”和“内部”函数调用之间有问题的区分，引入了不兼容性和安全问题，其中这种区分对 WASI 的受众来说方便地没有区别，但“外部”调用破坏了 Web、JS 和自互操作性，对于任何自然适合 Web 平台的语言来说都是如此。组件模型没有提出对受影响用例的支持。
- 组件模型专门提出了 Rust/非 Web 概念，而 Java 类/Web 平台概念却无处可寻。
- 组件模型选择的“规范 ABI”不必要地使 WebAssembly 对 Web 平台不利，而有利于 C++ 和 Rust。
- 组件模型声明了“语言中立性”和“Web 平台集成”的目标，但实际上它并没有遵守这些目标。
- 使用组件模型进行 ESM 集成将会在函数调用的基本级别破坏 Web 平台，例如当 JavaScript 模块（包括透明地依赖项）升级到或被 WebAssembly 模块替换时。
在组件模型建立过程中，观察到各种流程差异以及违规行为。
2020 年 5 月，组件模型提案（当时称为接口类型）的负责人 承认 (opens new window) 接口类型首选的语义不匹配 Java 类语言（包括 JavaScript），并且技术上可以轻松支持 Java 类语言或 Web 平台语义。该小组表示支持该解决方案。但是，在后续的一次没有说明关联性的重新整合提交中，完全相反 (opens new window) 内容被提交，并以毫无意义的文字进行了解释。
虽然所有数值类型的规范表示都很明显，因为它们的大小都是 2 的固定次幂，但
char要求提案选择一个任意的字符编码。为了与核心 wasm 规范的 UTF-8 选择 (opens new window) 一致，以及 “UTF-8 无处不在” (opens new window) 的更普遍趋势一致，该提案也选择了 UTF-8。通过选择规范字符串编码的最佳路径，同时提供对有效转码的优雅回退，接口类型为最终收敛提供了温和的压力，同时避免了性能悬崖。首先，除了任意选择之外，还有更好的选择：做 Web 平台正在做的事情。其次，文件格式的选择与 API 调用的要求关系不大。第三，“UTF-8 无处不在”是那些公开宣称 JavaScript（仍然是 WebAssembly 的主要互操作语言）有害的人的观点。第四，对于 Java 类语言和 JavaScript 互操作，不存在“最佳路径”、“优雅回退”和“有效转码”。第五，任何提案都无权施加压力来对抗 Web 平台。第六，由于向后兼容性的严格限制，最终的收敛是不可能的。第七，肯定会出现性能悬崖，甚至更糟糕的兼容性问题，不仅仅是在过渡时期，而是永远如此，如果最基本的构建块
char类型本身已经被人为地限制了。Unicode 代码点本应该是一个兼容的选择。2021 年 5 月，一系列投票 被提议 (opens new window) 加入 CG 的会议议程，以建立组件模型。配套演示 (opens new window) 包含不准确的“拟议的下一步措施”，以证明一个单一的“规范 ABI”的合理性，该 ABI 将刻写 WASI 的语义选择，将其他任何东西称为“仅仅是优化”，这显然是不正确的，同时回避了“艰难的设计问题”，鉴于之前的承认，这也是一种牵强附会的说法。AssemblyScript 提出了一个澄清演示，以告知小组关于这些影响的信息 被提议 (opens new window)，但被简单地拒绝了，因为在投票之前不允许进行。
尽管如此，AssemblyScript 还是急于发布了一个 问题，附带了演示 (opens new window)，该问题在投票前周末出现。在投票结束后，该问题和演示都没有得到解决。在 投票前的讨论 (opens new window) 中，提到了这些担忧，但该思路被接口类型负责人粗暴地打断，因此没有充分讨论。随后的投票通过，WASI 游说团体投票赞成。AssemblyScript 代表投票“反对”，因为他受到 WebAssembly WG 成员的建议，不要强烈投票。据说是因为这样做会被视为不当行为。在讨论中，接口类型负责人应另一位成员的要求澄清，投票不会规定具体的语义，但后来事实证明并非如此，但可能说服了更多人投票中立或赞成。
为了准备他们的演示，AssemblyScript 代表请求加入 WASI 子组会议的持续邀请，接口类型以及后来的组件模型的设计选择最初是在这些会议上提出的。他最初由于 WASI 主席含糊其词的指控而没有被允许加入，之后礼貌地同意了特殊规则，只被允许参加一次会议，并且被劝阻不要发言，WASI 主席说这些担忧没有意思，没有人会理会。与此同时，在提出组件模型的一天后，WASI 子组 宣布自己成为标准化过程的平等部分 (opens new window)，尽管其背书已经引发了许多先前的流程和组织差异。当 AssemblyScript 代表在怀疑有不正当行为时寻求帮助时，其他主席无视了最近发生的事件。最终，WASI 主席公开暗示，这位男性可能在她的 个人 Twitter 帐户 (opens new window) 上让他感到不舒服，这可能是他职业生涯的终结之举，尽管他们之间从未有过私人通信。
投票结束后，2021 年 6 月，一位 Google 员工在 W3C 技术架构组撰写了 两个 (opens new window) 帖子 (opens new window)，这些帖子将通过设计原则来破坏 JavaScript 字符串语义，从而破坏与 Web 平台的兼容性。仅仅几天后，这些帖子就被用作 类似性质论据列表 (opens new window) 的一部分，以证明与 JavaScript/Web 平台语义分离的合理性。
在 2021 年 6 月的一次会议中，尽管是在之后的会议上要求的，但一个接口类型冠军 进行了一场冗长的辩论 (在新窗口中打开)。当时间用完时，CG 主席建议举行后续会议。后续会议很快就被取消，理由是“不愿意”。该小组没有被告知，即使是事先要求的。尽管有人建议，但仍然没有建立一个井然有序的接口类型小组，因此，直到今天，接口类型和组件模型都仍然在很大程度上独立运行的 WASI 小组中进行规范。
对于 2021 年 8 月的会议，组件模型冠军将 一个摘要和难以理解的投票 (在新窗口中打开) 添加到了 CG 会议议程中。AssemblyScript 要求 (在新窗口中打开) 通过至少引用相关的 WebIDL 概念来澄清投票文本，以便更多人理解投票的内容，但这被 WG 成员和主席集体拒绝了。我们更新的 担忧和建议 (在新窗口中打开) 在最终的决策过程中被 巧妙地绕过 (在新窗口中打开)（见下一项）。
在 2021 年 8 月的会议上，组件模型冠军没有按照 议程项目 (在新窗口中打开) 提交摘要，而是提交了 支持的单方面论据 (在新窗口中打开)，即使在 事先澄清 (在新窗口中打开) 冠军会进行总结。2021 年 5 月的投票据说是没有规定具体语义的，却被用来作为决定具体语义的论据。投票结果通过了，WASI 游说团体投票赞成。这次有两个成员强烈反对，他们在会议结束时表达了沮丧之情，并遭到该小组的嘲笑。他们强烈的投票没有任何效果。其他 AssemblyScript 贡献者后来表示，他们没有理解投票的内容，并且对单方面的陈述感到惊讶。
在 2021 年 9 月，组件模型仓库创建，具有讽刺意味的是，它声称的目标 (在新窗口中打开) 是“语言中立”和“Web 平台集成”，而这两者正是组件模型没有遵守，或者说是被破坏的。
同样在 2021 年 9 月，WASI 主席以一个借口关闭并锁定了一个 关于 WASI 背景的讨论 (在新窗口中打开)，这种做法是不寻常的，并且附加了一个未经请求的回顾，将 AssemblyScript 代表描绘成负面形象，而 AssemblyScript 代表无法做出回应。该代表后来向 W3C 监察员 (在新窗口中打开) 进行了投诉。监察员没有回复，反而主席们无视了投诉，WASI 主席修改了他们的评论并加倍强调，当 AssemblyScript 代表最终对一系列程序违规和差异表达了极大的沮丧时，AssemblyScript 代表被 W3C 首席执行官禁止以任何形式参与 WebAssembly 组织，这是根据 WASI 主席的要求做出的。作为回应，提供了一份类似此事件的程序和行为违规清单，但被无视。
因此，我们有理由相信，围绕组件模型的事件是出于政治动机，技术事实要么被歪曲，要么被忽略，人们被劝阻、歧视和排斥，目的是让他们闭嘴。
尽管我们认为围绕组件模型的程序和行为违规非常严重，技术误导和偏见程度不可接受，但我们愿意与修改后的组件模型提案进行建设性地重新接触，前提是满足以下条件：
- 冻结组件模型提案，直到 Wasm/JS 交互性得到显着改善，从而减轻了提前标准化带来的风险，这些风险可能会导致市场出现问题，或者与 WebAssembly 的总体目标发生危险的冲突。
- 坚定地承诺 将与开放 Web 平台的兼容性视为至关重要 (在新窗口中打开)。
- 承认错误并真正遵守 Wasm 和组件模型的沟通目标。
- 在解决这些条件时，要展现良好的意愿和诚实，避免政治技巧。
如果不可能或拒绝，我们建议 WebAssembly CG 剥夺组件模型提案的合法性，不再推进它，因为将其标准化将过早地使 WebAssembly 偏向现有的 Web 平台，或者偏向那些本应按照设计与 Web 平台相适应的编程语言，鉴于力量对比和由此产生的经验，这种情况几乎肯定会永远持续下去，因此将树立一个致命的先例，即通过可疑的做法在政治上破坏 W3C 标准化工作的目的和目标是一种可行，甚至更糟，是合法策略。
# 关于 W3C 的说明
尽管 W3C 无疑已经意识到这一点，但它在这些事件中的作用我们仍然不清楚。无论我们经历了什么，我们都明确同意，一个值得尊敬的标准化机构应该负责任地指导 WebAssembly 的标准化工作，我们愿意扩大与 W3C 的合作，前提是满足以下条件：
- 将 WASI 代码库和场所从 W3C/WebAssembly 组织转移出去，以结束这种有害的认可。
- 任命公正且负责任的主席，以重新建立对 W3C 程序和价值观的信任。
- 清除那些滥用 CEPC 来歧视和排斥成员表达意见的成员。
- 坚定地承诺 将与开放 Web 平台的兼容性视为至关重要 (在新窗口中打开)。
- 承认错误并真诚道歉，以减轻那些受到系统性虐待的人的痛苦。
- 在解决这些条件时，要展现良好的意愿和诚实，避免政治技巧。
如果不可能或拒绝，我们建议社区调查 Ecma 是否会成为更合适的场所。我们认识到，如果浏览器供应商有意将这种情况保持在他们的自由裁量权范围内，那么就没有这样的路径。
# 关于字节码联盟的说明
我们对与字节码联盟的重新合作持怀疑态度，字节码联盟是一个由几家科技巨头和一些合作伙伴组成的联盟，它 (在新窗口中打开) "致力于创建……新的软件基础，建立在……标准，例如……WASI"的基础上。它的创始成员描述 (在新窗口中打开)了 WebAssembly 的黎明，将其视为“修复已损坏部分”（可能是 Web）的机会，“为原生开发构建新的基础”（可能是非 Web），同时采取“刻意的跨行业行动，以确保此事以正确的方式发生”（可能是解释政治特性）。随后，从我们所见到的情况来看，它似乎选择性地赋予 WebAssembly 空间中各自的玩家权力，削弱其力量，应用可疑的流程价值 (在新窗口中打开)，例如“不同意并提交”，这些价值观实际上适合打破任何东西，包括它自己的技术价值 (在新窗口中打开)，仅凭权威声明，并且，如果我们对它的管理层人物的经验教会了我们什么，那就是它运作远远超出了其声称的社会价值 (在新窗口中打开)“协作”、“包容性”和“开放性”。鉴于其并非严格必要但非凡的权力集中，以及其成员在据称开放和协作的标准化工作中的行为所传达的非常明确的信息，我们希望提醒公众注意潜在的反竞争行为，这些行为表明需要反托拉斯立法介入。我们认识到，并非字节码联盟的所有成员都一定知道或认可其表面层面的行为，因为他们中的许多人已经真诚地与我们接触，即使字节码联盟的代表没有这样做。总而言之，我们认为 WebAssembly，反过来就是 Web，没有它会更好，因为实际上，推动其想法的流程和场所已经存在，但现在有被其运作的刻意行为使其变得功能失调的风险。
# 生态系统考量
我们相信 WebAssembly 标准、其生态系统、Web 平台、其利益相关者和公众将极大地受益于WebAssembly 与现有 Web 平台的兼容性 (在新窗口中打开)，同时强调培养一个真正开放和协作的空间，每个人都可以参与其中，不受骚扰的困扰，从而可以交换想法，更多编程语言和用例变得可行，并遵循 Web 的原则和价值观。我们认为，一种被政治接管并忽略了技术问题、既定事实和公众广泛利益的任意阉割的技术，其价值为负。任何创造性的营销和政治手段都无法弥补一小部分人分裂努力对 WebAssembly 技术造成的巨大损害，WebAssembly 技术以其将众多编程语言和用例不仅带入 Web，而且将人们更紧密地联系在一起的承诺而让我们惊叹不已。鉴于适合 Web 平台的用例被人工地处于劣势，而难以上手的编程语言以及通常是按流量计费且概念不同的用例却毫无道理地处于优势地位，因此，我们不仅对 Web 平台的未来感到悲伤，而且对 WebAssembly 空间中的各种新尝试也感到悲伤，因为在目前这种受政治限制的形式下，它剥夺了 Wasm 的真正潜力，同时引入了可移植性、兼容性和安全问题，市场很可能不会很快增长到足以支持所有这些尝试。因此，我们相信，几乎所有人的最大利益在于确保开放 Web 标准的目的、目标和价值观得到尊重，而目前这显然不是这种情况——而且令人遗憾的是，这种情况被许多将几乎宗教般的编程语言偏好、支持非 Web 用例的掠夺性商业行为或两者兼而有之置于曾经如此有希望的愿景之上的人所强化。
我们希望我们能够清楚而详细地表达我们的反对意见。感谢您的考虑。