CS2 Discussion: Question: Survey for devs/teams with maintained Coffescript codebases: happy with CS, or considering migrating?

[coffeescriptbot]

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

Coffeescript has been around since 2009. Since then, a lot of Coffeescript code has been written, and non-trivial projects developed with it.

Given we're discussing the future of Coffeescript, it would be great to get the views of developers/teams who have non-trivial, maintained CS codebases, which they plan to maintain and extend over the coming years.

Specifically, it would be good to know whether you/the team are:
a) happy to keep using Coffeescript for the project
b) are considering migrating the project from Coffeesript to ES6/other.

Here's a little markdown 'survey' template below to use, or feel free to comment free-style.

**CS project summary.**
Quick summary: n developers, lines of code, years established, etc

**Is the project considering a switch from Coffeescript to ES6/other?**
No, or yes with language being switched to.

**If considering switch from Coffeescript, please explain your reasons.**
Give your reasons.

**If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?**
Give your reasons.

[coffeescriptbot]

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

CS project summary.
1.5 developers, 14K LOC, 3 years established.

Is the project considering a switch from Coffeescript to ES6/other?
Yes, to ES6, but not immediately.

If considering switch from Coffeescript, please explain your reasons.
I'm uncertain over the long-term substainability of Coffeescript. As Javascript develops at rapid speed in both browsers and nodejs, I want confidence that Coffeescript will still interoperate with latest Javascript+libraries in 3-5+ years. Recent incompatibilities with ES6 have raised uncertainty for me (broken tagged literals, and reports of ES6 inoperability. So I might de-risk the project by switching to ES6 Javascript.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
I feel more productive and less likely to make bugs with Coffeescript. It's a small, clean language with a functional feel. I don't consider ES6 massively superior to Coffeescript. Yes it's introduced some Coffeescript-influenced features, but it's also added even more complexity to Javascript.

[coffeescriptbot]

From @nwinter on 2016-09-10 14:49

CS project summary.
Quick summary: CodeCombat, 7 core developers and hundreds of open source contributors, about 100K lines of code, 3.5 years old

Is the project considering a switch from Coffeescript to ES6/other?
Not actively considering, though a couple of us would like to. Maybe eventually. We'd go to ES6 or maybe Typescript.

If considering switch from Coffeescript, please explain your reasons.
It's a polarizing language that can make it harder to hire developers who think they won't like it. There's a perceived lack of momentum compared to ES6. There are a few cool things in ES6 we'd like to use. It's more future-proof.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
Primarily the cleaner, more powerful syntax. There are some language features I can't live without. Also, no need to migrate our code. We haven't run into any interoperability problems yet.

[coffeescriptbot]

From @greghuc on 2016-09-10 21:37

Re existing CS projects, @devongovett justifies porting fontkit from CoffeeScript to ES6 here. He also plans to migrate pdfkit to ES6.

[coffeescriptbot]

From @alangpierce on 2016-09-11 01:53

CS project summary.
Benchling, 17 developers (about half of whom joined in the last 6 months), about 200K lines of CoffeeScript code, about 3-4 years old.

Is the project considering a switch from Coffeescript to ES6/other?
We've already decided to switch to JavaScript, and new code is written in JavaScript. I've been contributing a bunch to decaffeinate in my free time to make it easier to switch.

If considering switch from CoffeeScript, please explain your reasons.

• JS generally has better tooling, like linting, code coverage, etc.
• We were unhappy about various sharp edges in CoffeeScript, primarily implicit returns.
• We prefer JSX for React code, and we weren't comfortable with the risk and build complexity of CoffeeScript JSX solutions.
• We write fairly disciplined code and we're hoping to use flow at some point, which requires JavaScript.
• Once we decided to write new code in JS, moving off of CoffeeScript became important to reduce ramp-up cost for new people.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?

We're agreed on switching to JavaScript, but there are certainly some hesitations:

• Some people on the team still like CoffeeScript better, particularly range syntax and ?..
• Switching programming languages takes a lot of work and isn't particularly important for any company goals. By my super-rough estimates, converting the codebase to JS would take 4000 person-hours without decaffeinate and 400 person-hours with decaffeinate in its current form. That's a lot of time that could be spent building useful things that help people.

[coffeescriptbot]

From @greghuc on 2016-09-13 07:52

Feedback from Atom Editor at atom/atom#12656. Relevant quotes:

• "the current strategy appears to be that when new files are checked into the codebase, those should be written in ES6. No more Coffeescript files should be added. Existing coffeescript files may be converted to ES6 when they undergo a major rewrite."
• "Only suggestion I'll make is that you swap the freakin' of and in operators the other way around so devs won't keep confusing the two when flipping between CoffeeScript and ES6."

[coffeescriptbot]

From @honzajavorek on 2016-09-13 08:59

CS project summary.
Quick summary: Dredd & Apiary, ~15 developers at the moment, thousands of lines of code, mostly since ~2012

Is the project considering a switch from CoffeeScript to ES2015/other?
We decided to write new projects in ES2015 if possible. There's currently no strict policy about existing CoffeeScript codebases (which we have plenty of), but they're maintained and kept being developed. If we're tearing off some parts of larger projects into separate libraries or services, they're almost always started from scratch as ES2015 codebases. There's currently no plan to systematically decaffeinate any existing projects, but the codebases are considered as legacy.

If considering switch from CoffeeScript, please explain your reasons.
The company started with CoffeeScript in the past mostly because it was able to abstract away annoying limitations of standard ES5 JavaScript. Now that ES2015 offers new features and less annoying syntax sugars, there's no reason to use CoffeeScript anymore. While many of us are Python and/or Ruby fans, we don't see the benefit in using CoffeeScript just for the "clean" syntax - on the opposite, the syntax is sometimes way too benevolent (namely missing parentheses) and some of it's features are designed dangerously (variable scoping, implicit returns), so in the result the language produces mistakes and unreadable code rather than prevents them. We made our own strict style guide to prevent common mistakes. The language is now also now missing features which are already available in ES2015 and isn't able to keep up with growing JS ecosystem and tooling (e.g. eslint, coverage tools, ...). Basically, ES2015 seems like the future to pursue, while CoffeeScript turns out to be the (necessary) past to make the future happen.

(Fun fact: I agree with switching to ES2015 now, but if the company was using plain JS instead of CoffeeScript in the past, I probably wouldn't even consider to join them. I was very strongly Python-oriented and I completely hated plain JS. With CoffeeScript it was at least bearable.)

[coffeescriptbot]

From @davibe on 2016-09-13 19:32

CS project summary.
Quick summary: Yakyak (https://github.com/yakyak/yakyak), 2 devs + contributors, almost 6k lines. Also a private startup, 5 devs, 40k lines of code, 10 months.

Is the project considering a switch from Coffeescript to ES6/other?
We are resisting. We are waiting for a solution that allows us to support new features with no retarded syntax involved.
Yakyak is written in functional style therefore everything-is-an-expression of coffee fits better. A benefit of Javascript would be easyer contributions from a larger community.
In the private company we mostly care about async/await support at the moment. We are using generators in the meantime like this

If considering switch from Coffeescript, please explain your reasons.
If we have no choice we will eventually switch mostly for async/await support, better tooling, easier adoption for new people.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?

The fact that in CS everything is an expression, the cleaner syntax, more powerful and expressive. Small things like?.this?.one isnt 'trascurable' for most in people when not most.crazy may look stupid but they can really make things more concise, readable and most of the times you don't need external libs like underscore/lodash.
Its true that it's harder to find coffeescript devs and it takes time to learn it, but it pays off.

Babel is the only way to use ES6 stuff BUT it adds a build step OR it's super-slow (using require-hook). I also had problems with exception stacks not being readable and source maps not working as well as coffee. I don't consider it a decent backend replacement because it just adds overhead on our case. It's ok for a webapps indeed we do use ES6 js + jsx for frontend code.

[coffeescriptbot]

From @jcollum on 2016-09-13 19:47

CS project summary.
Quick summary: 1 developer, several projects, about 3k lines of code including tests, Hapi.js and pure node, 18 months old for the oldest

Is the project considering a switch from Coffeescript to ES6/other?
No, not the project. Unless we decide it's very important to re-do the codebase. Unlikely.

If considering switch from Coffeescript, please explain your reasons.
Yes, considering switching new codebases to ES2015. Mostly to avoid getting left behind if I ever need to look for a new job.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
I would prefer to stay with CS (vastly prefer the syntax) but the lack of ES2015 features gives me fear of a dusty resume. FODR instead of FOMO? Coffeescript was a reasonable "sell" to a potential employer but now it's outdated and I can't recommend it for new codebases.

[coffeescriptbot]

From @jcollum on 2016-09-13 20:14

@davibe I have to ask if you've considered LiveScript. Much more functional / closer to Haskell than CS.

[coffeescriptbot]

From @davibe on 2016-09-14 05:59

@jcollum no. Quickly looking at it the syntax already has horrible things that i don't need to know % *+like |> <- this. 'cmon. I would even remove @, => and maybe class from coffee if it was just for me. Sorry for being grumpy, I am exaggerating a bit i know :)

[coffeescriptbot]

From @JimPanic on 2016-09-14 06:03

No need to apologize, @davibe! I can relate re @, => and class. Although the pipe operator |> (also found in Elixir) is very handy sometimes! ;)

[coffeescriptbot]

From @mrmowgli on 2016-09-14 10:21

CS project summary.
2 developers, 35k+ lines of code, 4 years of projects and contract work in CS.

Is the project considering a switch from Coffeescript to ES6/other?
No, with some caveats. Frameworks like Meteor have already switched to shimmed ES6, and I am running into lots of issues updating projects. For the most part code is still CS, with some ES6 wrappers to deal with framework peculiarities.

If considering switch from Coffeescript, please explain your reasons.
Not interested in a world without CS. Good god, back to all those semi-colons and matched braces all over the place?

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
CS is by far the best way to approach Javascript. I know the ES6 features are the new hotness, but lord, I am happy with the CS classes, happy with the syntax, happy with conciseness and readability. I know everyone wants to keep up with the joneses, but CS is still a completely workable language form many tasks. Once we get some of these big ticket items (Thank you @JimPanic & @GeoffreyBooth for module loading!! ) cleared up then I can get back to clean beautiful code! Also I would love to see a day when all the ES coders end up adopting CS as the OFFICIAL version of ES, instead of just taking useful parts and mangling them. * sigh *

[coffeescriptbot]

From @jcollum on 2016-09-21 16:34

@GeoffreyBooth suggested I repost this here:

Hey I don't know where else to put this so:

I'm working on a new Hapi.js project the last few days. Decided to do it in ES2015 since a couple of junior devs are helping me. HOLY CRAP I MISS COFFEESCRIPT. All these damned extra braces and semicolons and such, clutterin' up my code. And the lack of easy key/value list comprehension. Etc.

So, thanks so much for participating here. Know that your work is appreciated.

[coffeescriptbot]

From @vpj on 2016-09-28 08:33

CS project summary.
1 developer, 60K LOC, 2.5 years

Is the project considering a switch from Coffeescript to ES6/other?
We are happy with CoffeeScript but are evaluating our options, because CoffeeScript doesn't have type annotations.
We are considering typescript or javascript with flow type checking.

If considering switch from Coffeescript, please explain your reasons.
It's difficult to maintain untyped code. For instance, if we want to make a change to a function definition, it's hard to find all the references. Also, it's easier to introduce bugs in untyped code.

Long term sustainability is also a concern as there are a lot of projects moving away from CoffeeScript. We feel that CoffeeScript is quite mature and doesn't need a lot of contributions to maintain itself. But as Javascript get more updates CoffeeScript could get lagged behind without a large community using it.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
We love the clean syntax on CoffeeScript. And well return CoffeeScript is short and easier to understand.

We also use executable class blocks a lot, as well as markup on CoffeeScript - which is made possible because of the CoffeeScript syntax - Weya.coffee

[coffeescriptbot]

From @doublerebel on 2016-10-23 15:46

CS project summary

CoffeeScript has been my go-to JS solution for several years, multiple projects, startups, and Appcelerator Titanium apps. Easily ?0K+ lines of code invested and currently in use.

Is the project considering a switch from Coffeescript to ES6/other?

I use Iced CoffeeScript, which is already using ES6 as a compile target in branch iced3. There are multiple of us who will sustain Iced for the forseeable future.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?

Iced await/defer syntax solves async issues, and never changes despite the velocity of JavaScript's language changes. This to me makes it a far more sustainable and safe business decision than trying to 'keep up' with ES2015 or ES2017. I never require my developers to write in Iced but they tend to choose Iced as it's so productive. I've never felt in my teams that CoffeeScript was keeping us from creating a better product.

I love CoffeeScript's functional syntax. Recently I translated Riemann's query parser from Clojure, and Coffee enabled me to create a mini-Lisp to do a near-direct translation.

I do wish there was an easy way to do optional typing with CoffeeScript. Contracts.coffee was a really cool concept.

I feel like so much of higher-level code is just data marshaling and destructuring and async coordination. That requires so much boilerplate in plain JS, at this point you'd have to pry Iced from my cold dead hands.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-23 22:36

@doublerebel Thanks for some links to some great resources! I’m curious, does iced3 output ESNext for any features besides async/await?

Contracts.coffee seems really cool. There’s a lot of interest still in somehow adding types to CoffeeScript, perhaps if that effort takes off Contracts.coffee could serve as a model.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-24 00:04

@doublerebel I should also mention that we’re hoping to add support for async/await soon via #3757. Is there anything that iced3 offers that that PR wouldn’t supply?

[coffeescriptbot]

From @williamstein on 2016-10-24 00:26

CS project summary.
Quick summary: n developers, lines of code, years established, etc

SageMathCloud: 6 developers, tons of code, 4 years, 10K+ weekly active users (many paying customers).

We use CoffeeScript very extensively, both on the frontend (including react and cjsx) and backend (in node.js).

Is the project considering a switch from Coffeescript to ES6/other?

No.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?

Clean and beautiful language that avoids some gotchas of Javascript. Can be written in a way that looks more similar to Python. Very stable (regarding language modifications/churn).

[coffeescriptbot]

From @disruptek on 2016-10-24 20:48

Though my CS use is limited, I wanted to offer some positive reinforcement.

CS project summary.
1 developer, >10k lines of CS/ICS, about 6 months of work begun 2.5 years ago. CS frontend and portions of the backend. Plays nicely alongside large amounts of Python.

Is the project considering a switch from Coffeescript to ES6/other?
No.

It is clearly harder to attract developers who are unfamiliar with CS. If I had a Real Job, I might worry about whether I was doing myself any favors by avoiding JS and signing up to hack in CS.

That question of CS sustainability is probably my biggest worry, but honestly, the pain of living with straight JS for however long it takes CS to become a liability dwarfs those concerns. I don't have any old JS code, though, so I don't have a good sense for how much longevity my own code has. I haven't found the JS ecosystem to be remotely stable enough to worry too greatly about reuse.

About 80% of my CS code is Iced and I've had some fears about the longevity of that project, but @doublerebel has helped put them to rest here.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
As articulated by @williamstein, @doublerebel, and @davibe, the language's elegant aesthetic and functional features offer an expressivity and legibility which has real value (albeit often poorly weighted by others), and that value is dramatically increased as you add developers.

Thank you for CS!

[coffeescriptbot]

From @jiyinyiyong on 2016-10-25 03:46

I heard the company I worked for migrated to TypeScript. Maybe @suyu34 @Brooooooklyn can give more details.

CS project summary.
10~15 developers this year, started 2013 or even earlier, a large single page app.

Is the project considering a switch from Coffeescript to ES6/other?
Switched to TypeScript. (Old case base not converted)

If considering switch from CoffeeScript, please explain your reasons.
no certain information.

[coffeescriptbot]

From @lubelski on 2016-10-26 15:30

CS project summary.
4 developers. 80K lines of code in main app + other utilities, probably another 20k - 40k lines. 4 years old.

Is the project considering a switch from CoffeeScript to ES6/other?
We are working more with React Native and the amount of ecosystem tied to babel/ES6 stuff in making us at least consider moving.

If considering switch from CoffeeScript, please explain your reasons.
Tooling / linting is limited and ongoing support questionable. Recruitment and on-boarding time for new hires.

If not considering switch from CoffeeScript (or are, but would ideally like to remain with CS), why are you happy with CS?
Concision and expressivity of code and our general programmer happiness. We much prefer reading, writing, and discussing CS to native JS.

General Thoughts
So far, all the ES2015 changes have felt like catching up to CS, with nothing going beyond CS.

There are a few features in CS that are godsends that we basically know will never get ported into ES. Specifically the ? that is ludicrously convenient, and the fact that almost everything is an expression (if, switch, try) + implicit return just makes makes it a lot easier to write concise functional code.

async/await might be the first ES feature that will be some kind of deal-breaker for us. My hope is that at some point a CS 2.0 comes into being that pushes past ES6/7 as much as original CS pushed past ES5.

[coffeescriptbot]

From @geoffreak on 2016-11-04 22:03

CS project summary.
Current: 4 developers, ~200,000 lines, 3 years (Node + browser)
Prior (various): 2-3 developers, ~20,000 lines, ~2 years (Node + browser)

Is the project considering a switch from Coffeescript to ES6/other?
No. While the lack of any kind of static typing is starting to become an issue, it was decided not at this time due to the large complexity of our project. Our team is in agreement that we would use TypeScript if we were doing it over. If Coffeescript had static typing or a straightforward upgrade path to TypeScript, this would be a non-issue.

If considering switch from Coffeescript, please explain your reasons.
CoffeeScript doesn't have anywhere near the tooling and development aids that TypeScript has available. Static typing is an absolutely massive aid and would have helped in a massive number of bug scenarios. Block scoping and constant variables would also have helped prevent a huge number of bugs. Coffeescript also encourages bad programming patterns that has resulted in buggy and unreadable code in many sections of our project. You also give up a lot of control over how the code functions (and its optimization) by abstracting away things with Coffeescript.

Our code is still growing and is starting to become unmanageable in some ways, so refactors have been needed, but these have been extremely dangerous with Coffeescript due do the lack of static typing and a set of tools than can quickly identify code that isn't using a new interface or variable type. It is very easy to introduce a new bug and therefore is very difficult to justify changing something that works, regardless of how many times it was extended or how unreadable it has become.

While CoffeeScript was the most advanced option at the time we started our projects, it has fallen greatly behind in terms of capability. I fear the community is dissipating to the point where we're going to have a hard finding new developers in the future and our current developers (including myself) will lose motivation from missing out on the time-saving features newer languages offer. The Coffeescript6 effort is too little, too late and so far has no new feature offers - just ES6 compatibility fixes.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
Whitespace-based languages lead to prettier looking code (sometimes). Writing code is also a little faster in Coffeescript because fewer symbols and characters are needed to accomplish the same task. Most of the syntax sugar is very helpful in allowing cleaner and clearer code.

[coffeescriptbot]

From @hems on 2017-08-08 19:09

i just can't wait for coffee script 2, is that a valid option!? : D

[coffeescriptbot]

From @sudowork on 2017-08-09 23:08

Our team recently just converted from CoffeeScript to ES6, and I wanted to provide some of our reasons for switching. Here's our blog post that goes into more depth: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep.

CS project summary.
Quick summary: 5-10 developers, 200k+, 4 years (Node + Ember)

Is the project considering a switch from Coffeescript to ES6/other?
Yes, just recently switched to ES6 using a mix of decaffeinate and jscodeshift.

If considering switch from Coffeescript, please explain your reasons.

• Evolution of ECMAScript (ES) language + TC39 process
• Larger ES community
• Tooling for ES (ESLint, jscodeshift, prettier, VSCode, static analysis)
• Native runtime support (e.g. Node.js v6), no transpiling for certain environments
• Recruiting/onboarding

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?

• Glad to see the evolution of CS to CS2 and the improved interoperability/adoption of ES features.

[coffeescriptbot]

From @michalholasek on 2018-02-06 09:18

Following up on @honzajavorek's comment in this thread - we switched from CoffeeScript to JavaScript (ES2015+) (using decaffeinate) in both Dredd & Apiary recently. Most reasons why we did were already mentioned in other comments above, but to reiterate - ECMAScript standard (and JavaScript) is now mature enough, tooling, no need for transpilation anymore (depends on which browsers / engines you support of course), recruiting / onboarding new people is easier with JS than with CS.

[coffeescriptbot]

From @hems on 2018-02-06 18:57

CS project summary.
Loads of developers, uncountable lines of code, loads of projects developed on the last +/- 7 years and still only kicking out coffee-script out of the door.

Backend, frontend and desktop apps, unfortunately, i'm not comfortable to disclosure the projects ( i know you think I'm lying!! )

Recently all projects are being developed and worked using CoffeeScript 2 and couldn't be happier.

Is the project considering a switch from Coffeescript to ES6/other?
Absolutely not

If considering switch from Coffeescript, please explain your reasons.
I would only migrate away from coffee if I wanted to go through some sort of religious ritual involving pain and suffering.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
Being a developer with over two decades and have developed "professional" projects I came to the conclusion developers overlook the power of "readability" and "simplicity" when developing a quality product.

New developers and developers without mixed background ( for instance developers who never worked with design, sound, databases, networks, Linux, standalone hardware, offline applications or even old archaic package manages / SCM ) tend to prioritise technology choices and facebook trends over what I believe to be the most important characteristics of a codebase: "readability", "simplicity" and "speed of change" and I believe coffee script is the perfect tool for that.

I think coffee script / the community ( including myself ) should explore even deeper the ability to look like "plain English", sometimes the code gets so readable that it looks like Cucumber tests and I think that is some really powerful stuff that Javascript will hardly ever have with all that verbose syntax. I personally can't smell typescript and other modifications that make JS look like Java or C#, I have seen other languages "evolving" that way and I know it decreases massively the capacity of a team to develop creative ideas since only "real coders" will be able to touch the codebase. I believe if you want your code to work, you have to write tests for it, over-specifying code is like declaring death to creativity, comfort and freedom and that's not what you want when coding products with quality output as a major goal.

Often times when I can read my code with designers and other non-programming people on the project it becomes really clear how powerful collaborating with mixed background people is and how big the difference is on the final product. Imagine explaining "interfaces" and other old-school "Object Oriented" patterns to such people, it simply doesn't work. Code must be simple, small, clean and have the least amount of boilerplate possible.

Ok, enough of ranting now 😵

Technically speaking I believe we would benefit from "Extending" the language so we could for instance add and overload operators in order to do more complex stuff with more readable syntax.

I have watched this talk by Jeremy and it's very inspiring but unfortunately i never took the time to play around, would be nice to learn/participate and try out more "unortodox" tweaks like those!

A simple example: would be nice to extend operators so you could create a "contains" operator which would take left and right side of the expression as arguments:

if array contains item
  # __contains__ would take "my_array" as first argument and "item" as second

# We kinda do something similar with the "in" operator, but 
would be nice to actually bake loads of "our own" operators, wouldn't?
if item in array
  # ...

# but wouldn't be nice to do something like

if item is in array
 #...

or

if something is greater than something_else
  # __is greater than__ would be translated to >

This would open incredible amount of possibilities and even more minimalistic approaches, I have worked on projects where snippets of code had to be written and puzzled up together dynamically from the UI so users could make their own routines and being able to provide users with such simple customised DSL on top of coffeescript is a dream!

ps: apologies for such long email, CoffeeScript just makes me overly excited, i think we should open a CoffeeScript church, maybe a CoffeeSript store and what not!

Thank You!!!

[coffeescriptbot]

From @johnjeng on 2018-02-07 22:23

CS project summary.
4 developers. A lot of code. Used for the front end of Cocalc. 5 years established. Using React, Redux, Babel, Webpack, etc.

Is the project considering a switch from Coffeescript to ES6/other?
No.

If not considering switch from Coffeescript (or are, but would ideally like to remain with CS), why are you happy with CS?
We like cleanliness too much and the direction of Coffeescript 2 seems solid. Transpiling to modern syntax with opt-in for everything new is definitely the right way.

Other Notes
If flow annotations were possible in a cleaner way, we'd be over the moon satisfied.
Projects like coffeescript6/discuss#92 give us faith that tooling will get better.

[coffeescriptbot]

From @GeoffreyBooth on 2018-02-07 22:52

@hems Thanks for all the kind words. I’ve been thinking for a while of trying to write a blog post that lays out the case for “Why CoffeeScript in an ES6 world,” which is basically an argument for why cleaner code is better, now that CoffeeScript and ES are roughly feature-comparable. I was thinking of trying to aim at persuading a skeptical audience. Maybe you should take a crack at it 😄

To your suggestion at the end, unfortunately we can’t add keywords without breaking backward compatibility, which is a big reason await is part of CS2 and not 1. But there are plenty of ways to add features without using keywords, and the time is ripe for new features that give us advantages over JavaScript 😄

@johnjeng Support for CoffeeScript in Prettier is really only held up by available developer time to work on it. Our own maintainer @lydell is a mainter of Prettier, so he could certainly help shepherd it in on their side. If you or anyone on your team has time to devote to helping, we’d love the assistance.

As for Flow, I wrote the comments support that hopefully makes Flow integration possible, but I don’t use Flow myself so I don’t have much of an idea as to how good or poor it is. I know it looks ugly, from the examples in the docs, but that’s always been a lower priority; it should be pretty trivial to write some kind of preprocessor for Flow-in-CoffeeScript files that lets you write the Flow annotations without the ### comment wrappers and the preprocessor adds the ###s before passing the result to the CoffeeScript compiler, so that your original source files are cleaner than the examples in the docs. If you’ve tried Flow in CoffeeScript and have feedback for how it could be better, please feel free to open an issue or issues in the main CoffeeScript repo with suggestions. Posting a repo of an example project that uses Flow with CoffeeScript would also be very appreciated.

[coffeescriptbot]

From @johnjeng on 2018-02-08 17:36

@GeoffreyBooth We haven't built a preprocessor and don't use Flow currently so I can't really say. It was just an option we strongly considered and decided that using ### in function definitions was unreadable. Wish we had time to help move CoffeeScript in Prettier forward. Our focus is less on tooling these days.