Recently, it was announced that the next version of JavaScript (ES2016) will be comprised of a very small feature set, namely Array.prototype.includes (which determines whether a specific value is included in an array or not) and the exponentiation operator (which raises a number to the power of an exponent). Considering the plethora of new features introduced by ES6, some people might be surprised at exactly how small a release ES2016 will be. Others, on the other hand, may be happy that there are only two new features to learn—a manageable goal by most people’s standards.
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
If you ignore its quirks, JavaScript is easy to grasp and really flexible—it makes a great first language. It also makes a great second language. Many developers I know had history programming in other languages prior to writing JavaScript, and with Node becoming increasingly stable and better, I believe many others will follow.
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 in_array() and strstr() functions. It’s kind of a mess. In JavaScript-land however, there’s jQuery, Underscore, MooTools and a bunch of other frameworks/libraries that all have .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.
What bothers me more is inconsistency. This one change won’t turn JavaScript into another PHP, but TC39 should keep the standard high. The DOM specification, for example, includes Node.contains(). Although one may argue that the currently implemented .includes() is part of JavaScript’s core while the DOM API is not, this is confusing when you’re building for the web, which seems the prior concern of choosing .includes() over .contains().
I think TC39 should focus on keeping JavaScript neat. In other languages you can often build for and stick to a specific version. The web, however, doesn’t play nice with deprication or changes—every choice is permanent. Choosing between breaking 1% of the web using a poorly designed library vs. focus on the future and durability of the language, I’d rather choose the latter.
Moritz: We Shouldn’t Break the Web Just Because of Naming Preferences
The web has always been about accessibility. A website written in old standards (e.g. XHTML 1.0) is still usable today and won’t crash your browser. JavaScript has almost become a necessity and powers a large fraction of what we call the internet. A good part—if not the most—of last year’s ECMAScript 2015 feature set is syntactical sugar, intended to provide backwards compatibility.
The focus should be on fixing real language flaws and needs, not adopting more syntactic sugar from other languages.
JavaScript hasn’t always been so feature-rich as it is today. With libraries and frameworks like Prototype, jQuery, MooTools and many more, the web community filled the gaps and needs themselves. Some of them became very popular, others vanished, but all of them eventually shaped the web—and language specifications.
Many of the latest JavaScript additions have just been an answer to what these libraries already provide. It only makes sense to take this into consideration when creating a new language feature. Hence, I am very happy to see the Technical Committee 39 renaming Array.prototype.includes.
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 includes(), and the rest seems to proceed with the initial pattern: Selection.containsNode(). I also want JavaScript to be a consistent language, but we shouldn’t start to break the web just because of naming preferences. Consistency matters, but keeping the web accessible does more.
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.
Tim SeverienTim Severien is an enthusiastic front-end developer from the Netherlands, passionate about JavaScript and Sass. When not writing code, he write articles for SitePoint or for Tim’s blog.
Moritz KrögerMoritz is a German front-end developer living in Berlin. Although Germans typically have a thing for extra long compound words, he's a friend of short functions.
