可让开发者编写类TypeScript语言，再将其编译成WebAssembly的项目AssemblyScript，在前些时间，宣布移除对WASI（WebAssembly System Interface）的支持，由于许多社群成员要求他们提出进一步解释，因此AssemblyScript项目现在完整公开他们的考量，他们认为WASI和W3C对其所提供的支持，对开放标准有害，特别是伤害WebAssembly的规范，在满足特定条件下，他们才会重新考虑参与WASI制定工作。
WASI是用于非网页WebAssembly，类似POSIX的导入命名空间，其提供了一组像是fd_write这样的外部函数，WASI的设计参考C++和Rust等系统程序语言中所开放，但是不存在网页平台的低端层，AssemblyScript提到，WASI被营销成为一个标准，但是其发展不仅几乎没有与WebAssembly范畴以及目标重叠，WASI还由一个强大且很大程度是独立运行的W3C子工作组霸道管理。
随着WASI的发展，该子工作组扩大了WASI的范畴，并且埋头设计自己的提案，AssemblyScript认为，这些提案有一定程度与已创建，或是当前设计的网页标准竞争，该子工作组在提出标准的同时，又同时增加了碎片化。
而在AssemblyScript项目和其他社群成员对此提出异议的时候，却遭到系统性歧视，WASI主席以职权操作，回避其他人对WASI制定方向的疑虑。AssemblyScript项目表示，目前WASI和该工作组，并非追求与WebAssembly一致的目标，而WASI的想法和概念持续扩散影响WebAssembly，在制定标准的过程却造成生态系统分裂，对于标准本身是一种讽刺。
AssemblyScript在文章中，公开了所有他们认为WASI制定上，尚未解决的具体技术和相关问题，该项目认为，WASI与一般网页标准，特别是WebAssembly规范中的技术目标和组织价值没有交集，对一个适合网页平台的语言来说，WASI导致WebAssembly出现shim，并且缺乏如JavaScript Polyfill的替代方案，使得两者概念中断，因此他们认为WASI不是一个能够良好支持许多程序语言的正确抽象。
AssemblyScript也提到，WASI中出现网页上不常见像是字符串等概念，从根本上和类Java、JavaScript不兼容，这代表当以现有网页平台作为兼容目标时，WASI不会是一个合理的抽象。WASI还引入许多冗余功能，网页平台上已经可以使用的部分功能，WASI却坚持要以不同的方式实例。
以目前设计看来，AssemblyScript认为过度使用WASI会导致WebAssembly程序代码在网页中膨胀，增加大量程序代码容量，且WASI要求根据不同环境重新编译模块，并且扩展其应用版图和独立设计竞争API，都会导致各种碎片化的情况产生。
AssemblyScript要求WASI项目进行大刀阔斧改革后，他们才会重新考虑参与WASI制定，其包括搬迁WASI存储库移出W3C/WebAssembly组织，真诚地对造成的伤害道歉，并且在处理问题时，不使用政治手段。另外，AssemblyScript也对Bytecode Alliance表达了不信任的态度，他们认为该联盟是由几家科技巨头，以及经过挑选的合作者组成，在WebAssembly上选择性地削弱参与者，以程序性手段破坏协作、包容性和开放性等价值。AssemblyScript提醒，在创建于开放和协作名号下的标准化工作，需要有反垄断力量介入，整体而言，他们认为Bytecode Alliance消失对WebAssembly和网页的发展会更好。