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.
Moritz: We Shouldn’t Break the Web Just Because of Naming Preferences
The focus should be on fixing real language flaws and needs, not adopting more syntactic sugar from other languages.
As Tim already pointed out, naming a function that checks for the existence of an item, is an active discussion across the programming world. The DOM API started with the
contains() naming schema (Element.classList.contains(), Node.contains()), then the language specification changes an API to
Besides that, I welcome the new release process of the ECMAScript specification. Not having a huge bundle of new features every year, will help developers to keep up with the language. Although, there should still be a rough plan of the direction ECMAScript is heading. Adding new features just to answer the needs of a current trend will end in a bloated language. The focus should be on fixing real language flaws and needs, not adopting more syntactic sugar from other languages.
Over to You
So there you have it. Should we stand firm and focus on the future and durability of the language we love, or should we avoid breaking the web over naming preferences?
There’s no denying that naming things is dificult. As the saying goes, there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Which side of the debate do you fall on? We’d love to hear from you in the comments.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers