Coffeescript 2 -- too many breaking changes

[littlebee]

Before I say anything, let me say, thank you, Jeremy and crew for all you've done for me. I've been using and, on a very small scale, evangelizing the virtues of CoffeeScript for just about seven years. I've written a lot of it and I can't tell you how many bugs I've closed with a single ?. Thank you.

I was very excited this morning to dig in and convert my team's > 500,000 line CoffeeScript code base including about 200,000 lines of CJSX to CoffeeScript 2, but there is no way I can make that happen with so many breaking changes. I'm hoping that there are some transforms or migration tools that maybe that will make this easier?

Choose one: is this a bug report or feature request?
feature request + recreational bitching

Provide a general summary of the issue in the title above.

Some of the changes I understand, even if it doesn't make it any easier on me:

• not being able to access this before calling super - this was one of the things I use to point to as a half baked implementation of OOP given to us by ES6 and why CoffeeScript was better at OO :)

And some of the changes seem like they are just blindly following the less capable:

• method parameters not defaulted if null. This is not just going to cause run-time only errors, but will also cause the worst kind of sporadic defects.

• not allowing super without parens - this was a really useful feature of coffeescript, because it allowed a subclass to call the parent's method without knowing the parameters the parent currently expects. Base class method, might later add parameters, but anyone using the subclass would not be able to that new feature on the parent until the sub was updated.

...

If you are going to make CoffeeScript more like ES2015, which tried to make Javascript more like CoffeeScript, why would anyone choose CoffeeScript?

Possible Solution

AST Transforms to allow CoffeeCcript to ignore ECMA standards. Again, why is Coffeescript trying to be more like ECMA?

Migration / code transform tools like Facebook provides for React breaking changes: https://github.com/reactjs/react-codemod (which also don't work with Coffeescript)

Context

It has made me sad. I loved Coffeescript, but I think maybe even you guys are trying to tell me it's time go back to Javascript.

Environment

• CoffeeScript version: 2.2.4
• Node.js version: 6.10.3

[jashkenas]

Hi Bee,

I completely agree that the changes you list are steps backward, not forward. If you don't need the compatibility that CoffeeScript 2 offers with today's JavaScript, of course, you're welcome to continue to use CoffeeScript 1. It compiles to ES3 that will continue to work forever.

Realistically, I don't think that we're going to provide a migration tool that rewrites CS1 to CS2. So don't wait around for us to create one (although someone in the community certainly might).

[GeoffreyBooth]

Seconding what @jashkenas wrote. The primary goal of CoffeeScript 2 was to support modern JavaScript, not just as its own inherent good but because using modern syntax is required for interoperability with modern frameworks. A CoffeeScript 1 class can’t extend an ES2015 class, for example; and popular frameworks like React use ES2015 classes extensively. In order to use CoffeeScript with React in ways that users expect (i.e., similarly to examples found online, rather than their ES3 equivalents) we need to output the ES class keyword. That locks us in to all the limitations of ES2015 classes, unfortunately. We tried to minimize breaking changes whenever possible; there are no changes simply because we felt a different decision might be better today, like block-based scope. If a change wasn’t necessary for the goal of supporting modern JavaScript, we left things unchanged.

With regard to your other points:

method parameters not defaulted if null

Unfortunately ECMA made a choice different from us in this regard. We discussed this, and decided that ultimately “CoffeeScript is just JavaScript,” and it would be more confusing the deviate from the standard. I understand this is a burden for upgraders.

not allowing super without parens

As it says in http://coffeescript.org/#breaking-changes-super-extends, just change any bare super to super arguments....

If you are going to make CoffeeScript more like ES2015, which tried to make Javascript more like CoffeeScript, why would anyone choose CoffeeScript?

People who came to CoffeeScript purely for features have a lot less reason to do so now than they did eight years ago; but that’s a good thing! JavaScript is improving, and we all benefit from those changes, even if some of them haven’t been perfect. What CoffeeScript still offers today is the same thing it always has: a clean, concise syntax that many people find easer to read and write. That advantage isn’t going away.

[helixbass]

@GeoffreyBooth @jashkenas I have to say the ES6 default param semantics is the one that's hardest for me to swallow as it seems like a really braindead decision on their part and has bitten me consistently. I read the linked discussion and actually really like the suggestion of introducing ?= as a way of getting the old semantics, I find that quite elegant and not nearly as ugly as @jashkenas does

@littlebee not sure whether you've bitten the bullet/moved on but the underlying AST support needed to be able to eg provide migration-easing transforms is well underway. I could picture having a cobbled-together tool that would parse your code to AST, apply a set of transforms (not sure whether the this referenced before super can safely be transformed?), and reprint (perhaps at first reformatted using Prettier, since that's what I'm working on, but ultimately being able to preserve original formatting would be nice too) in the next month or two