 Mathias Bynens [X](https://twitter.com/mathias) [GitHub](https://github.com/mathiasbynens) [Homepage](https://mathiasbynens.be/)
## What the *smoosh* happened?!
A [proposal](https://tc39.github.io/proposal-flatMap/) for a JavaScript
language feature called `Array.prototype.flatten` turns out to be
Web-incompatible. Shipping the feature in Firefox Nightly caused [at least one popular website](https://bugzilla.mozilla.org/show_bug.cgi?id=1443630)
to break. Given that the problematic code is part of the widespread MooTools
library, it's likely that many more websites are affected. (Although MooTools
is not commonly used for new websites in 2018, it used to be very popular and
is still present on many production websites.)
The proposal author jokingly suggested renaming `flatten` to `smoosh` to
avoid the compatibility issue. The joke was not clear to everyone, some
people started to incorrectly believe that the new name had already been
decided, and things escalated quickly.
## What does `Array.prototype.flatten` do?
`Array.prototype.flat`, originally proposed as `Array.prototype.flatten`,
flattens arrays recursively up to the specified `depth`, which defaults
to `1`.
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
> [!NOTE]
> **Note:** Since the publication of this article, `flatten` has been renamed to `flat` to resolve #SmooshGate. The above example has been updated accordingly, but keep in mind that the original name was `flatten`.
The same proposal includes `Array.prototype.flatMap`, which is like
`Array.prototype.map` except it flattens the result into a new array.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
## What is MooTools doing that causes this problem?
MooTools defines their own non-standard version of `Array.prototype.flatten`:
Array.prototype.flatten = /* non-standard implementation */;
MooTools' `flatten` implementation differs from the proposed standard.
However, this is not the problem! When browsers ship
`Array.prototype.flatten` natively, MooTools overrides the native
implementation. This ensures that code relying on the MooTools behavior
works as intended regardless of whether native `flatten` is available.
So far, so good!
Unfortunately, something else then happens. MooTools copies over all its
custom array methods to `Elements.prototype` (where `Elements` is a
MooTools-specific API):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
`for`-`in` iterates over "enumerable" properties, which doesn't include
native methods like `Array.prototype.sort`, but it does include
regularly-assigned properties like `Array.prototype.foo = whatever`. But ---
and here's the kicker --- if you overwrite a non-enumerable property, e.g.
`Array.prototype.sort = whatever`, it remains non-enumerable.
Currently, `Array.prototype.flatten = mooToolsFlattenImplementation` creates
an enumerable `flatten` property, so it's later copied to `Elements`. But if
browsers ship a native version of `flatten`, it becomes non-enumerable, and
*isn't* copied to `Elements`. **Any code relying on MooTools'
`Elements.prototype.flatten` is now broken.**
Although it seems like changing the native `Array.prototype.flatten` to be
enumerable would fix the problem, it would likely cause even more
compatibility issues. Every website relying on `for`-`in` to iterate over
an array (which is a bad practice, but it happens) would then suddenly get
an additional loop iteration for the `flatten` property.
The bigger underlying problem here is modifying built-in objects. Extending
native prototypes is generally accepted as a bad practice nowadays, as it
doesn't compose nicely with other libraries and third-party code. Don't modify
objects you don't own!
## Why don't we just keep the existing name and break the Web?
In 1996, before CSS became widespread, and long before "HTML5" became a
thing, [the Space Jam website](https://www.spacejam.com/1996/) went live. Today, the website still works
the same way it did 22 years ago.
How did that happen? Did someone maintain that website for all these years,
updating it every time browser vendors shipped a new feature?
As it turns out, "don't break the Web" is the number one [design principle](https://www.w3.org/TR/html-design-principles/#support-existing-content)
for HTML, CSS, JavaScript, and any other standard that's widely used on the
Web. If shipping a new browser feature causes existing websites to stop
working, that's bad for *everyone*:
- visitors of the affected websites suddenly get a broken user experience;
- the website owners went from having a perfectly-working website to a non-functional one without them changing anything;
- browser vendors shipping the new feature lose market share, due to users switching browsers after noticing "it works in browser X";
- once the compatibility issue is known, other browser vendors refuse to ship it. The feature specification does not match reality (["nothing but a work of fiction"](https://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/#about-browsers)), which is bad for the standardization process.
Sure, in retrospect MooTools did the wrong thing --- but breaking the web
doesn't punish them, it punishes users. These users do not know what a moo
tool is. Alternatively, we can find another solution, and users can continue
to use the web. The choice is easy to make.
## Does that mean bad APIs can never be removed from the Web Platform?
It depends. In rare cases, [bad features can be removed from the Web](https://whatwg.org/faq#removing-bad-ideas). Even just figuring
out whether it's *possible* to remove a feature is a very tricky effort,
requiring extensive telemetry to quantify how many web pages would have their
behavior changed. But when the feature is sufficiently insecure, is harmful to
users, or is used very rarely, this can be done.
`