Basically mootools screwed up, and this is what smooshGate was about as well.
They modified the array prototype directly with their own methods. They did feature detection on the prototype by checking if the method of that name existed ("flatten" in the case of smooshGate, "contains" in the case of "includes"), and didn't replace the prototype method if a function of that name already existed on the prototype (whether or not its a compatible implementation or not). Unfortunately, the behavior of these mootools methods differed enough from the official spec that they cannot be used interchangeably.
The consequence is if "flatten" or "contains" were to become part of the official spec and implemented by browsers, then all legacy mootool applications would break and mootools is apparently a big enough deal that it ends conversation.
That just proves that "contains" is the correct name for the language feature.
Implement it correctly, without regard to any silly things that 3rd parties were doing. 5 years from now, nobody will remember that library.
Do it the way they're doing, and 5, 15, 50 years from now people will still be asking why this stupid language used a non-standard method name for Array.contains.
Extra points for encouraging all the other poorly implemented javascript libraries to fix their things before they break for similar reasons.
I disagree. "contains" might be a nice name, but if it breaks a significant number of websites and forces many to have to update and fix websites that have worked for years, then a simple rename is a fantastic solution in my opinion.
This isn't about being "right", it's about finding the best solution to the problem at hand, and a solution that breaks things but is "technically correct" is worse than one that doesn't break things but has a slightly wonky name.
Only one of those solutions has negative ever-lasting effects though and a bad name definitely does break things.
A broken app can be fixed once, by one developer. A bad name will cause confusion among all developers and waste their time.
Unfortunately, JS already has such shitty names for things that everybody just accepted this. But, they were wrong. They should have definitely broken apps built with mooTools because of the reasons that I stated and also since browsers have already broken tons of sites for lesser reasons such as removing ads.
JS prioritizes backwards compatibility to a very high degree. This has proven to be a strength over the years, as it allows the language to evolve quickly without big drama like python.
It's not comparable with Python, which broke correct code to the point where even `print "Hello world"` was broken! This mootools issue only affects a very small number of users.
It amounts to a denial-of-service attack against the language, if you author a popular enough JS library you can screw things up for everybody in perpetuity. That isn't a healthy way to design a language.
The Unix-Haters Handbook also has a story about backcompat:
> Way back in the early 1980s, before each of the bugs in Unix had such a large cult following, a programmer at BBN actually fixed the bug in Berkeley’s `make` that requires starting rule lines with tab characters instead of any whitespace. It wasn’t a hard fix—just a few lines of code.
> Like any group of responsible citizens, the hackers at BBN sent the patch back to Berkeley so the fix could be incorporated into the master Unix sources. A year later, Berkeley released a new version of Unix with the `make` bug still there. The BBN hackers fixed the bug a second time, and once again sent the patch back to Berkeley.
> …The _third_ time that Berkeley released a version of `make` with the same bug present, the hackers at BBN gave up. Instead of fixing the bug in Berkeley `make`, they went through all of their Makefiles, found the lines that began with spaces, and turned the spaces into tabs. After all, BBN was paying them to write new programs, not to fix the same old bugs over and over again.
> (According to legend, Stu Feldman didn’t fix `make`’s syntax, after he realized that the syntax was broken, because he already had 10 users.)
The real pain is from people that don't know better when saying a URL out loud. "domain.com/page" gets incorrectly spoken as "domain dot com backslash page"
Basically the web is designed with backwards compatibility in mind, or at least, not completely breaking old websites which is why they chose not to go down that path.
"The Chrome Devs" is not a single entity, it would seem.
These don't seem like the same "The Chrome Devs" who broke every WebAudio app in existence by removing .noteOn within 12 months of .start being proposed as a replacement for it.
And that was a case where there was absolutely no long term harm keeping the recently deprecated method name around. It just seemed tidier to some junior dev someplace and nobody questioned it. There is actually a thread someplace where they moved it back by a build so that they would have a chance to fix Google's "Chrome WebAudio Showcase" site which had broken because of the change.
In this case though, I disagree that we're talking about backward compatibility. That's about not breaking things you previously released with things you release in the future. It takes Microsoft-Windows-esque attention to detail and testing effort to ensure you never break some fool's reliance on an undocumented feature.
They modified the array prototype directly with their own methods. They did feature detection on the prototype by checking if the method of that name existed ("flatten" in the case of smooshGate, "contains" in the case of "includes"), and didn't replace the prototype method if a function of that name already existed on the prototype (whether or not its a compatible implementation or not). Unfortunately, the behavior of these mootools methods differed enough from the official spec that they cannot be used interchangeably.
The consequence is if "flatten" or "contains" were to become part of the official spec and implemented by browsers, then all legacy mootool applications would break and mootools is apparently a big enough deal that it ends conversation.
This is what happened when Mozilla implemented flatten on firefox nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1443630