Our consensus on adopting various ES2015+ features into CoffeeScript

[GeoffreyBooth]

I created a new markdown document to live at the root of the repo, that consolidates our consensus on the various ES2015+ features we want to add support for in CoffeeScript. I also prioritized the features into tiers, based on how bad it is for a project that CoffeeScript lacks support for that particular feature.

This is all separate from the effort of changing CoffeeScript’s output to ESNext.

The descriptions and rankings are just my best guess based on what I’ve read in the various issue threads. By no means do I intend to impose my own preferences. If you disagree with any rankings, or description of a feature or our proposal for how to implement, please comment on this PR. Even after it’s merged in, please feel free to submit PRs against this document as things change.

Tagging @rattrayalex @JimPanic @carlsmith @DomVinyard because they’ve all expressed opinions relevant to this document.

[lydell]

I definitely agree on the top priority list.

[JimPanic]

Me too. Thank you for gathering all that and writing it down. 🎉 🏆 🎉

[greghuc]

I like the top priority items. Interoperability is most important.

As a general observation, I value Coffeescript as a language by what it stops me using in Javascript. I want Coffeescript to offer me a minimal set of well-curated Javascript features, and nothing more. From this perspective, I'd query adding new ES features just because they exist. I'm even in two minds about const. I like the immutability angle, but it's got downsides for me:

• It complicates my mental model. A variable can now be in two states: read-write, or read-only
• A const variable carries no indication with it that is a 'constant'. I have to look back to the declaration to understand the variable's read-only nature.

From this view, I'm thinking that - if implemented - Coffeescript constants should simply apply to VARIABLES_IN_ALL_UPCASE, and that's it. I already define 'constants' like this in my current Coffeescript code, and I believe it's a common paradigm.

Sure you don't get all the advantages of const immutability. But this is Coffeescript. If people want the full power (and complexity) of ES201x Javascript, then they should use ES directly.

My two cents :-)

[DomVinyard]

I share @greghuc's opinion that the lack of const is a better feature than its presence.

[GeoffreyBooth]

In the proposed implementation, usage of const is entirely opt-in: if you don't type :=, you don't get it. I understand the philosophical objection, which I share, but for whatever reason a lot of people like using it. I don't think it's so horrible to give people what they want, and people who don't like it needn't use it. Just like I never use generators.

[DomVinyard]

@GeoffreyBooth I kind of feel like lots of those people are back with ES6 now for good. A new generation of Coffeescripters will replace them and those people will fall in love with the language too for the same reasons we did if it remains as beautiful and elegant as it was when we found it.

But the sort of performance optimisations that const provides just simply make no sense for Coffeescript. Especially when they come at the expense of the philosophical integrity. These small tokens to memorise are fine for us but for new users they're another grain of sand on the pile of conventions to learn. Either opt-in or otherwise, they will appear in the docs and they'll appear in Stack Overflow answers and users will need to learn them regardless.

[greghuc]

@GeoffreyBooth re consts I think the argument that "a lot of people like using it" is never a good one.

Coffeescript polarises opinions, and that's a good thing. It's a declaration of principles in code form, as initially set by the Great Benevolent Dictator (@jashkenas). Either people rally to these principles by using Coffeescript, or they don't. Coffeescript is less polarising than it was, as ES6 has become closer to Coffeescript. So naturally less people will use it - why go to the hassle of learning/using/compiling Coffeescript, when you can get 70% of the awesomeness by using vanilla ES6? If Coffeescript consciously becomes much closer to ES6 (by implementing almost all ES6 features), it will lose its polarising distinctiveness. It's just ES6 in a different syntax.

So what's the value of Coffeescript in the age of ES6 and beyond? Same as it ever was. Quoting from coffeescript.org: "CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way". To me, the value of Coffeescript is being a simple subset of Javascript, with a functional style. I use it precisely because it has opinions, like everything being an expression (and the occasional confusion that brings!).

So to me, the primary goals of Coffeescript next-gen should be:

• Ensure interoperability with latest Javascript
• Take advantage of latest Javascript tool awesomeness by transpiling Coffeescript into latest Javascript
• Very (and I mean very) selectively introduce latest-Javascript features if they are compatible with Coffeescript's principles.

The last goal is the hard one, as it's so opinionated. That's why the Great Benevolent Dictator model works well: the buck stops with a single person's philosophical view of what makes Coffeescript great. If no new Dictator can be found, the next best thing is to have a clear, written "objective" statement of Coffeescript's principles. Proposers of new features then have to justify why their new feature is compatible with Coffeescript's principles. And since adding more features makes Coffeescript more complicated (counter to its principle of simplicity), I'd suggest the bar for adding new features should be set pretty high.

Taking const as an example, I think the feature adds little to Coffeescript, whilst complicating the mental model of variables. My suggestion of VARIABLES_IN_ALL_UPCASE being constants is really just a formalisation of how people use Coffeescript already, so doesn't add as much complexity. But just replicating ES6 consts in a new syntax because lots of people like it in ES6 is not a good thing if it compromises the simplicity of Coffeescript.

Regarding async/await, the related issue shows some nice, clean uses of this feature to tidy up promise chains, so seems more aligned with Coffeescript's notion of simplicity.

Having principles and standing by them is a good thing.

[GeoffreyBooth]

@DomVinyard and @greghuc, there was a discussion in #1 and the consensus there was to add it with this syntax. If you disagree, I suggest you go to that thread and voice your opinions there. The point of this PR is just to consolidate the results of the other threads.

[greghuc]

@GeoffreyBooth thanks for the const discussion link. I just discovered this project a few days ago, so haven't read through all the issues yet. I appreciate the effort you've been putting in.

With regards to the nice prioritised feature list you've put together, I'd suggest cutting it at "Top Priority" for now, and postponing Medium and Low Priority discussions until later. Interoperability is important, and everyone can objectively agree that Coffeescript is broken if it can't interoperate with latest Javascript.

Assuming the Top Priority items are non-contentious, then the discussion/technical focus can shift to these items alone.

[GeoffreyBooth]

@greghuc thanks. As I look into classes I’m realizing that deciding on an implementation for classes means making decisions regarding decorators and getters/setters, as they’re very tied into classes. So this is all somewhat related.

Each feature heading includes a link to the thread where that feature was discussed. Many features lack consensus, and for those I’ve simply stated as much on this document. I find value in seeing that summary in one place rather than having to dig into long issue threads with dozens or hundreds of comments to determine that a consensus wasn’t reached. This document is intended to change over time as we hopefully reach consensus about each issue, even if that consensus is “wontfix.” Perhaps it might be a good idea to link to this repo from coffeescript.org, to attract a broader audience to ensure that our consensus is representative of the community. (@lydell ?)

There is agreement that no work should be done on medium priority or below until the top priority items are complete.

[GeoffreyBooth]

@DomVinyard and @greghuc I created #31 to specifically address the merits of a new const operator.

[GeoffreyBooth]

Merging this in, but it’s very much open to change if the consensuses in the issues changes.