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

  • Dylan Schiemann
  • 盖磊

2018 年 3 月 28 日

话题:JavaScript语言 & 开发架构

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)等问题的辩论。

查看英文原文: #smooshgate and the Challenges of Web Compatibility

JavaScript语言 & 开发架构