ECMAScript 6

By: on December 11, 2015

Recent projects got me dealing with JavaScript and this got me thinking about the language. You know, The Bad Parts. The damage has been done and there is no simple way to backpedal out of it. But hey, there is ECMAScript 6 to our rescue, is there not? Its final shape and form is known so we can have a closer look at what’s coming.

What are we getting? 2015, JavaScript introduces classes, maps and sets. Tail calls and generators are cool. Promises and weak collections less so. Either way, let’s face it, such changes don’t address the long standing problems.

What in that respect does ES6 bring to the table? I.e. we are getting let and const. From a brief look, let gives variable scoping like in Python, that is, it makes sense now (BTW, is it me or generators are lifted from Python?) What I don’t quite get though, is that you can mix the old var with let/const. For example, the following contrived function will throw a ReferenceError when you try to use it:

function foo(x) {
  "use strict";
  const y = z;
  let z = x + x;
  return y;
}

It is not so unthinkable that somebody types var instead of let, and the function “works” now:

function foo(x) {
  "use strict";
  const y = z;
  var z = x + x;
  return y;
}

It only makes sense to completely drop var in favour of let/const, but that’s a convention, not something enforced by the language. I’m guessing, this is meant to be migration friendly. But as friendly as making it optional seems, it also looks like yet another source of bugs.

Relatedly, class definitions in ES6 are not hoisted but functions still are. So this is invalid because classes cannot be forward referenced:

function foo() {
  "use strict";
  class FooBar extends Bar {}
  class Bar {}
}

But this is ok:

function foo() {
  "use strict";
  class FooBar extends Bar {}
  function Bar() {}
}

Again, while most likely intended to ease migration, I think this is also going to add up to the mess. And speaking of interoperability, defining a class still creates a function but it no longer can be used like a regular function, so rewriting a drop-in replacement using new classes may be tricky.

What else? To be honest, I cannot fish out much more regarding The Bad Parts. The much loved type coercion isn’t going anywhere, undefined remains misdefined, arguments pretend to be Array, Array pretends to be an array, etc. Even parseInt still doesn’t reliably parse ints, I guess too many people’d get upset if all of sudden it did. All the things we love to hate stay here for us to enjoy. As if a prevailing theme in designing ES6 was avoidance of even a slightest bump on the migration path.

Should we even bother given the potential migration pains? There is a lesson to be learned from the slow adoption of Python3, but I think JS is in a different position. JavaScript’s spread is mostly controlled by end users, or by respective vendors in case of mobile devices. When leading browsers get a new feature, in a few years vast majority of users will have installed it on their desktops or received it on their mobile devices and then it’s up to developers to take advantage of it. If anything, problems with new JS features used to happen at the sending not receiving side of the picture. But even browser vendors seem to be interested in improving the language. Microsoft promotes TypeScript. Chrome experiments with what they call strong mode. Mozilla keeps a good record of implementing whatever is becoming a standard. Ecosystem is ready for more substantial changes. It is “how” rather than “if”.

How then? ES6 automatically activates strict mode in the context of module or class. As far as I could gather, this is still the same strict mode. Now, why not introduce some sort of new strict mode? Ok, we don’t wanna introduce a dual personality of strict mode, JavaScript is schizophrenic enough without it. Why not introduce a whole new mode, say “use commonsense”? By now people are well accustomed to “use strict”, introduction of another opt-in mode sounds like a natural step to make. Guess what? Nope. Not even an opt-in. And that perhaps is the saddest part of ECMAScript 6, it just slaps on some more lipstick on this pig. Something we’ve been doing with a bunch of libraries anyway.

Share

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*