CS2 Discussion: Project: Core Features

[rattrayalex]

---

EDIT: this is now better-documented in the Features.md file. Leaving the below for posterity.

@DomVinyard proposed these as the "core four" for this effort:

• Classes
• Import/Export
• Fat-Arrow Functions
• Async/Await

These are things that we "absolutely, definitely need", and will take priority over other changes.

However, this list may be too short. Other possibilities:

• let/const/var
• decorators
• for-in/for-of
• getters/setters/statics/methods

In particular, Async/Await, being less widely supported and used at this point, may not make sense to take priority over more widely used features like decorators, or more core-to-the-language features like const and for.

Thoughts?

EDIT: I'll keep this bit as an evolving understanding:

Tier 1

(features essential for JavaScript interop):

• Classes
• Modules

Tier 1A

(breaking changes that catch CS up with ES6)

• for-of/for-in
• let/const/var

Tier 2

(non-essential, popular ES6 Good Parts)

• async/await
• decorators
• getters/setters/statics/methods
• fat-arrow functions

Tier 3

(non-essential ES6 features and new features)

• ?

[JimPanic]

Using the ECMAScript 6 compatibility list as a reference for prioritizing is probably a good idea.

That said, I think fat-arrow functions, class and for-in/for-ofare relatively low hanging fruits; they are partly implemented in CS already. Their behaviour might have to change and the codegen will need updating.

I second prioritizing async/await rather low compared to the rest. I'm not even sure how far this is standardized already anyways?

[carlsmith]

Why do we need fat arrow functions?

Or special sugar for decorators? We don't have function or class statements, so we can apply decorators by just putting them in front of the function or class we're decorating. Say you have a decorator called memo, you can do stuff like this:

f = memo (args...) -> console.log args
j = (memo 10) (args...) -> console.log args

That syntax works fine.

I second prioritizing async/await rather low compared to the rest.

+1 We should wait on async until we can compile it to ES6 and run it in a browser.

I think we should prioritise classes and modules way above that other stuff personally. We can't use CoffeeScript with a growing chunk of the JS ecosystem because we can't import a module or extend a class, making CoffeeScript partially obsolete. The other stuff is just nice to have.

• Top Priority (features essential for JavaScript interop)
  • ES6 Classes
  • ES6 Modules
• Priority (non-essential, popular ES6 Good Parts)
• Optional (non-essential ES6 Good Parts and feature requests)

[rattrayalex]

Why do we need fat arrow functions?

Well, we don't. But:

1. If nothing else, I like the symbolism of it – compiling fat arrow to fat arrow (when possible) really says "ES6 is a first-class language target".
2. One of the things I love most about coffeescript is the readability of the generated javascript, and => is strictly better than function(){}.bind(this) and its ilk.
3. The fat arrow is one of the most clear examples of CoffeeScript features making it into ES6. It'd be really nice to celebrate that by baking it in.
4. On the scale of what we're talking about, I assume it wouldn't be that difficult to implement.

Ultimately I agree that it shouldn't be a Top Priority, but would definitely like to see it in V1.

[rattrayalex]

special sugar for decorators

ES6 has it, so we should too 😉

Of course, that doesn't mean it should be a Top Priority.

However, I'm not sure the workaround you suggested would work with classes?

pureRender
class MyComponent extends React.Component

Or methods, for that matter – in ES6, you can do:

const myObj = {
  @someDecorator
  method() {
     return 1;
  }
}

I'm not sure how that would look in Coffee?

[rattrayalex]

We should wait on async until we can compile it to ES6 and run it in a browser.

While I don't think async/await is as important as classes, modules, and possibly a few others, I definitely don't think we should wait that long – by then, it'll be too late. People are already using the feature in Babel and TypeScript, and have been for a while – and experimental support landed in Chrome several weeks ago.

Not only that, but it may be tricky to do (thus requiring a lead time) and is a feature designed to fix one of the most bothersome parts of JavaScript programming (node especially) – callback hell and neverending promises.

[rattrayalex]

Hmm, fair. I'd rather not force hacks, though, when we can build a feature people seem to want.

[rattrayalex]

Let's move the decorators and async/await convo's to separate threads and keep this thread centered around prioritization. @carlsmith would you mind moving your comments there to keep this thread clean? I'll do the same.

[rattrayalex]

Closing as this has been "officially" (if tentatively) decided in the Features.md file. Further discussion can happen around Pull Requests seeking to modify that file.