ES2016: Should the Future of JavaScript Be Developer-Driven?
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.
Continue reading %ES2016: Should the Future of JavaScript Be Developer-Driven?%
LEAVE A REPLY
You must be logged in to post a comment.