By Moritz Kröger , Tim Severien

ES2016: Should the Future of JavaScript Be Developer-Driven?

By Moritz Kröger , Tim Severien

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.

  • MagusZoldik

    Tim side here. I’m a PHP dev and lack of consistency between names is really a pain sometimes, plus it’s not memory friendly.
    What if I already have a code (poorly designed) which define Array.prototype.includes() ? I will complain to TC39 and they will kindly rename it ? Nop. I know that my code will probably break in future browsers and will refactor it to support newer browsers. It’s the way of doing things in enterprises, legacy web apps almost always need refactoring to support newer browsers.

    I quote Moritz : “A website written in old standards (e.g. XHTML 1.0) is still usable today and won’t crash your browser”
    Crash maybe not, but potentially not usable many times, notably due to CSS changes and box models.
    And as I know, Mootools is not a standard ! So changing a name for one library is not a good argument.

  • Craig Buckler

    It’s admirable the ES spec authors consider this stuff but:

    1. It doesn’t matter what name is used – something, somewhere will break.

    2. MooTools is not as popular as it once was – even less so once this is implemented.

    3. Why would it break? Wouldn’t MooTools over-ride the method? If so, any existing calls would continue to work. If not, it’s (mostly) identical anyway, i.e. you pass a value and get true or false back.

    I agree with Moritz that we shouldn’t purposely break stuff. Introducing a global function named ‘$’ would cause havoc, for example.

    However, you can’t check everything and this appears to be a trivial, non-critical issue. We’ve known for years that prototyping core objects is dangerous. MooTools was developed before that was common knowledge but there’s been plenty of time to address potential issues.

    I’d call the method whatever is practical then contact popular library developers where necessary.

  • Dor

    MooTools isn’t relevant for anything anymore. Weird that they took into account. I think this decision was wrong, and the reason behind it even worse.

  • I’m not sure the comparison to Node.contains() is really relevant – the DOM is by nature a hierarchical structure, and as the MDN link says, contains() checks “whether a node is a *descendant* of a given node or not”, with “descendant” being the key word. Arrays aren’t hierarchical, so Array.includes() doesn’t check if a value is a descendant of the array, since that’s nonsensical.

    • True—it was the first .contains() I could think of. @morkro:disqus provided a better example, Element.classList.contains(), that is a plain list, much like an array.

  • I encourage a view firmly in the middle. While I would detest the PHP-ification of Javascript, I would also hate having a huge amount of broken websites – and remember that most websites are not under management by any sort of professional.

    I don’t know if MooTools is important enough to accommodate. I do know that a collision with jQuery could be a disaster. There is no reason to be doctrinaire. This decision should be made on a case by case basis.

    Any new language feature should account for its consequences in the real world. If the committee thinks it will be huge, then the workaround should be evaluated for PHP-ification. If the replacement name isn’t too stupid, then use it.

    We’re not talking about retouching Rembrandt here. Javascript is not likely to suddenly become perfect if we decide to screw all practical compromises.

Get the latest in JavaScript, once a week, for free.