undefined | Better HN

0 pointscwp13y ago0 comments

Because of the 1JS principle, ES6 will be a strict superset of ES5. CoffeeScript can maintain its existing semantics, produce the same JS output that it does now, and nothing will break. But then it's not really targeting ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does, from ES6's backward compatibility with ES5.

So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.

0 comments

rodw13y ago

To be candid I don't know the details of what is changed in ES6. Is there a specific aspect of ES6 you're thinking of?

But the new features of ES6 aren't features of CoffeeScript. Why would we expect them to be?

It's like noting that Java 7 adds support for strings to switch statements and wondering how the syntax of Closure is going to change in response.

There is no strict requirement for the languages to be tied together at a syntax level, they just "compile" to something compatible.

There may be strong technical reasons for the CoffeeScript compiler to take advantage of the new features of ES6, but that doesn't force a change to CoffeeScript-the-language. (In other words, it can target ES6 while remaining backward compatible.)

I wouldn't be surprised to discover I'm missing something, but I'm genuinely confused why this is seen as a technical problem. It's not that CoffeeScript-the-language is "not interested in the new features of ES6", but that, technically speaking, CoffeeScript-the-language is not interested in ES-the-language at all.

Apples and oranges. (Or maybe lemons and limes.)

As an aside, I do see this as a potential social problem. CoffeeScript would probably like to remain conceptually-compatible with JavaScript, and that gets much harder if the two have different semantics for similar syntax-es, but I'm going to guess this isn't the only example of it.

j / k navigate · click thread line to collapse