While ES2016 being so small caused a few raised eyebrows, it also highlighted another issue—that the
Array.prototype.includes method was originally going to be named
Array.prototype.contains, but it turns out that this name is not web-compatible (read it would have clashed with the MooTools library, potentially resulting in many broken websites).
And so it was renamed.
What we’re asking today is whether it is a good thing for the community to be driving the direction of the language like this, or whether it’s “kinda whack” that the spec was changed because of a library conflict. Two of our authors (Moritz and Tim) take opposing viewpoints on this issue.
Tim: the Spec Should Rule, Libraries Should Obey
It seems the programming world disagrees on naming a method to check whether an array item or substring exists in an array or string. C# and Java have
.contains() for array-like and string classes, Ruby has
.include?(), Python has the
in-operator and PHP has the
.contains(). Perhaps we can speak of a little convention going on here.
If they intend to take old libraries into account when naming APIs, I fear this is only the beginning of super weird names
I get the philosophy that changes may break many websites and/or apps, but we have to realise that with the diversity of existing libraries, breaking changes will occur. I hate the thought we are willing to make design choices to dodge one bullet. It’s not that I disagree with the chosen name, but this philosophy may lead to bad design choices in the future if it may break 1% of the web because of bad design choices on their part.