CS2 Discussion: Question: Ensuring long-term maintainability of existing CoffeeScript codebases

[coffeescriptbot]

From @greghuc on 2016-09-10 11:50

Many of the 'Coffeescript nextgen' issues currently raised are about which ES6 features should be added to Coffeescript. I presume this is driven from the viewpoint of "why should Coffeescript be chosen when starting a new project"?

I'm creating this issue to consider things from a different viewpoint:

• "We've an existing, non-trival Coffeescript codebase"
• "We plan to maintain and extend this codebase over several years"
• "We want to maintain interoperability with the latest and greatest Javascript libraries, build tools and eco-system"

Areas to consider:

• Coffeescript-nextgen being backwards compatible (as much as possible)
• Coffeescript-nextgen being interoperable with latest Javascript (ES6 and into the future)
• Community responsiveness to bug reports/fixes
• ???

[coffeescriptbot]

From @greghuc on 2016-09-10 11:57

It's worth noting that backwards-compatibility is likely less of an issue if an existing Coffeescript code-base is being actively maintained.

If backwards-compatibility was intentionally broken to ensure future Coffeescript could interoperate with now-and-future-Ecmascript, I'd be happy to fix up my existing Coffeescript codebases.

[coffeescriptbot]

From @rattrayalex on 2016-09-10 15:56

We've actually discussed several of these topics across the ~two dozen threads so far.

Here's my impression of where we stand so far:

1. Backwards Compatibility:
   Generally, there's a desire for a pretty high degree of backwards compatibility. Some amount of porting work is a given for certain features like classes, but hard-to-comprehensively-refactor changes like swapping the semantics of for..of and for..in, for example, would probably run into a wall.
2. There's a couple different kinds of "interoperability", depending on who you ask. I see four tiers:
   1. Actual Interoperability: being able to use ES6 libraries without hacks. For example, classes and modules – it's vital to be able to extend an ES6 class in coffeescript, for example. This is by far the most important subcategory.
   2. Feature parity: being able to do anything you can in ES6, in CoffeeScript. Stuff like const and await falls into this category. These are features you just can't use in CoffeeScript, but can in ES6. We're thinking hard about these, and will probably prioritize at least some of them.
   3. Syntax parity: examples include decorators, getters/setters, and methods. You can accomplish the underlying goal of any of these language features in CoffeeScript, but it might be less convenient/beautiful – or just different (eg, for..in/for..of). I think this category has been somewhat contentious but it's looking like we're leaning away from implementing most of these.
   4. Output parity: this is stuff like having a CS => output a JS =>. The decaffeinate project has done a tremendous amount of work to make this happen. This has been a fairly contentious topic as well, with a growing consensus that it should not be prioritized by this project at this time.
3. Community Responsiveness:
   The jashkenas repo actually isn't so bad on this, IMO. I've seen much worse. Nonetheless, I think it's clear that this project would love to see a more sophisticated leadership structure for the coffeescript project (see CS2 Discussion: Project: Leadership coffeescript6/discuss#3). This is mostly on the back-burner for now, as ultimately the best we could do is probably make a suggestion to jashkenas et al which would be up to them to adopt.

I'm just trying to summarize our existing conversations, but may have let my own opinions sneak in – please correct me if I've mischaracterized anything.

[coffeescriptbot]

From @carlsmith on 2016-09-10 16:14

Does anyone feel confident that they could implement a brand new compiler for CoffeeScript that doesn't deviate from the official compiler at all? CoffeeScript grammar has a lot of subtleties.

Realistically, it seems best to only aim to keep the official compiler compatible with previous versions, and for any new compiler to redo the language from scratch, with hindsight. Writing a perfect, drop in replacement for the current compiler is going to be really difficult.

[coffeescriptbot]

From @rattrayalex on 2016-09-10 17:12

@carlsmith wrong thread?

[coffeescriptbot]

From @carlsmith on 2016-09-10 19:03

@rattrayalex - Probably, yeah, sorry. It's a pretty general point though. If we don't have much hope of creating a new compiler without breaking backwards compatibility, there are limits on what can realistically be done.

[coffeescriptbot]

From @dadleyy on 2016-09-12 16:15

My codebase at work actually consists of about 40% coffeescript and 60% vanilla js. Our grunt/gulp configuration is built to copy the js and compile the coffeescript.

If the next iteration of coffeescript is not backwards compatible (meaning my existing code wouldnt compile), I would just add whatever additional steps to my build (e.g the new compiler) to allow us to write in the new coffeescript. I mind the idea of doing that much less than the idea of crippling this project with concerns of backwards compatibility.

Its very easy to rewrite old code vanilla js into coffeescript - we were probably around 70% vanilla js about 3 months ago. I'd imagine it would be even easier to rewrite CS into CS6.