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

作者｜Dylan Schiemann

译者｜ 盖磊

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

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

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

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

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

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

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

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

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

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

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

  原文链接

https://www.infoq.com/news/2018/03/smooshgate-web-compatibility