“#smoosh门”引发Web兼容性上的挑战

TC39提案Array.prototype.flatten会导致旧网站在Firefox Nightly版中无法正常显示。在回应这一软件缺陷报告时，该新特性的建议者开玩笑称会考虑将“flatten”改名为“smoosh”。这在 社区引发了大范围的口诛笔伐。

这场争论之所以愈演愈烈，不仅在于建议更改名称这个玩笑，更是因为在不破坏Web兼容性的条件下如何推进 语言的问题上存在着挑战。

作为一项提案，Array.prototype.flatten意在解决一个通常由 软件库和架构解决的问题，即如何将嵌套数组展平为单一数组。例如：

var arr1 = [1, 2, [3, 4]];
arr1.flatten();
// [1, 2, 3, 4]

该API的更改，本身是对 中的一个常见模式的改进。不幸的是，一些 软件库和框架，例如Prototype和MooTools等，其早期版本中为添加对此特性的支持，采用了一种扩展内建语言特性原生原型的模式。很多软件库最终认识到，这并非是一种好做法，因而决定另辟蹊径去实现语言上的改进。

问题由一家名为“wetteronline”的德国气象网站爆出。最终，问题的讨论转向对为什么Space Jam网站自1996年至今一直正常工作的关注，尽管Space Jam网站本身并未受到“#smoosh门”的影响。

MooTools中定义的Array.prototype.flatten，是一种不同于TC39建议标准的非标准版本。MooTools覆盖了浏览器的原生实现，这一做法本身并不存在问题。但是，MooTools将其定制的数组方法克隆到Elements.prototype API。 的“for-in”只支持遍历可枚举属性，不包括原生方法。如果工程师覆写了一个不可枚举属性，该属性依然是不可枚举的。这样，原生版本的Array.prototype.flatten并未拷贝到MooTools的Elements API，破坏了MooTools的Elements.prototype.flatten。

当前Web网站上的挑战已转变为，一旦旧软件库中已实现了一些限制引入非破坏性更改能力的特性，人们难以确定如何扩展Web。一些从长期缺乏维护的网站虽然依然工作，但是一旦添加了不兼容的改进，就会不工作。这时，让编写网站的人去实现升级可能并不现实，或许在网站不再需要活跃维护的情况下才有可能。

为避免将来出现此类问题，不鼓励工程师去扩展或替换原生的对象或特性，也不要扩展全局命名空间。就当前的ES2015+而言，Symbols等特性提供了更好的机制，可在需要时扩展原生对象，而不会更改内建原生对象的行为。

为终结该提案以添加到ECMA 的将来版本中，所考虑的一些替代方案包括：对flatten更名（当然不是smoosh）、将flatten作为Array.prototype上的值存取器（accessor pair），以及为flatten新建一个固有对象。

“#smoosh门”并非 生态系统中首次爆发的大规模辩论。以前曾发生过涉及“left-pad”和“尾随分号”（trailing semicolons）等问题的辩论。