The Case For The Prosecution
That's my summary of the case for the prosecution. How'd I do?
Let's take these one at a time, starting with the backwards compatibility argument. Why not simply introduce a new language? Surely, the magnitude of the changes for ES6 are comparable in scope to a new language. And surely some of the compiler technology used underneath the hood can be repurposed for a language that isn't handicapped by what amounts to ancient history (1995) in the computer industry. So why not make a clean start of things?
Here's what you missed: that's exactly what is happening.
Hello, Web Assembly. From Brendan Eich's blog:
It’s by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let’s say. Today I’m pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
This work, which an Open Web effort, supported by all the major browser vendors, is even better than a new language, because it offers a compile target instead of a language. In other words, developers will have their choice of languages. Of course, this is simply a refinement to a process that's already happening. But it's nonetheless a tremendous step forward:
[…] once browsers support the WebAssembly syntax natively, JS and [Web Assembly] can diverge, without introducing unsafe or inappropriate features into JS just for use by compilers sourcing a few radically different programming languages.
The Light Of A Thousand CoffeeScripts
This is important: part of CoffeeScript's success was also a huge constraint.
when you use
extends—but the point is that the underlying semantics
of the languages are the same.
There Aren't Any New Features, Just New Standards
Leave the language as is.
Change the language and break existing code.
Change the language without breaking existing code.
No one is really arguing for the second option because that's an obviously terrible idea. So really we're talking about either leaving the language alone or updating it without breaking existing code.
So what we really have are two completely different choices: extend the standard to support some or all of this evolution, or don't. The advantage of standardization is pretty clear: increased interoperability. Instead of a dozen slightly incompatible Promise libraries, there's one standard everyone can build upon. Instead of requiring transpilers to simplify asynchronous programming,you just add support for it into the language. And so on.
The disadvantage of standardization? Uh…is there one? Since backwards compatibility is preserved, everything that was already working still works. And if you want to keep doing what you were doing before, you're free to do so. The only difference is that you now have the option to take advantage of standard libraries and language constructs. Oh, and the spec is larger. But honestly, how many of you are really affected by that?
Complexity Is A Shell Game
var a = [1..5] var i = a[Symbol.iterator]()
That looks pretty weird, right?
But here's the thing.
Lots of people have extended the
That was probably not a great idea, but they did it,
and now that code is out there.
And you can't just add a function to the global namespace because, again,
that would break a lot of existing code.
So, while we might prefer an interface like this:
var i = a.createIterator()
var i = createIterator(a)
This would likely break existing code. So the folks involved in ES6 came up with a clever, if ugly, workaround. And since iterators would mostly be used in the context of the language's looping constructs or libraries, that particular interface would not often be used directly. Of course, there are edge-cases, like everyone over in CoffeeScript-land, where the looping constructs don't know about ES6 iterators. Which sucks, but I can still recognize that this was probably the optimal path forward.
Ladies And Gentlemen Of The Jury…
And all this has been done in the form of open standards, meaning no single vendor controls them or can manipulate them for it's own ends. That's pretty important, kids.
It's pretty much the best of all worlds, actually. So maybe we did learn from C++, after all. (Or maybe C++ is just the world's most misunderstood programming language. But I'll save that rant for another day.)