The broader JavaScript community responded vocally when Michael Ficarra, the author of the Array.prototype.flatten TC39 proposal, jokingly suggested renaming flatten as smoosh in response to a bug report that the new feature breaks old websites in nightly versions of Firefox.
The debate occurred not merely because of the alternative name that was proposed, but because of the challenges in advancing the language without breaking web compatibility.
Array.prototype.flatten is a proposal to address a problem often solved by JavaScript libraries and frameworks, namely to take a nested array and flatten it into a single array. For example:
var arr1 = [1, 2, [3, 4]];
arr1.flatten();
// [1, 2, 3, 4]
This API change itself is an improvement to a common pattern within JavaScript. Unfortunately, early versions of some JavaScript libraries and frameworks such as Prototype and MooTools embraced a pattern of extending the native prototype of built-in language features to add support. Most libraries eventually realized that this was not a great idea, and used other approaches to provide language enhancements.
The issue was reported from wetteronline, a German weather website, though eventually, the discussion led to notes about how the Space Jam website from 1996 still works today, though the Space Jam website is not itself impacted by #smooshgate.
MooTools defines a non-standard version of Array.prototype.flatten which differs from the proposed standard. However, that alone is not the problem as MooTools overrides the native browser implementation. MooTools clones its custom array methods to its Elements.prototype API. JavaScript's for-in only iterates over enumerable properties, excluding native methods. If an engineer overwrites a non-enumerable property, it remains non-enumerable. Thus the native version of Array.prototype.flatten is not copied to MooTools Elements API, breaking MooTools' Elements.prototype.flatten.
The challenge with a long-lived system like the World Wide Web is that it is difficult to determine how to extend the programming languages used when old libraries have implemented features that limit the ability to introduce non-breaking changes. Many websites still work, but are long since forgotten and would be lost if incompatible changes get added to the web. Therefore, asking a website author to upgrade may not be feasible or possible when the site is no longer actively maintained.
To avoid issues like this is in the future, engineers are encouraged to not extend or replace native objects or features, and to not extend the global namespace. Today with ES2015+, features such as Symbols would be a better mechanism for extending native objects as needed, without changing the behavior of built-in native objects.
To finalize this proposal for inclusion in a future version of ECMAScript, alternatives under consideration include an alternative name for flatten (not smoosh), making flatten an accessor pair on Array.prototype, or creating a new intrinsic object for flatten.
#smooshgate is not the first time the JavaScript ecosystem has had a widely debated discussion. Previous examples include left-pad and trailing semicolons.
