[addisonj]

I give credit to CoffeeScript with really helping to push the ES specs forward and think it helped introduce more people to JS and grow the ecosystem. Heck, I used it for a year, liked it, and had it change some of my approaches to writing JS.

That said, I hope it slowly fades into the background as more people go back to vanilla ES6 or go with something more powerful such as TypeScript (or Flux). With the progress around es6 and es7, gradual typing, macros, and other tooling around the language, I think CoffeeScript risks becoming a drag on getting people to learn modern JS and instead sticking with a language that has a lot of ambiguous constructions and fewer and fewer advantages over JS.

[briandear]

I sure hope you're wrong. The unnecessary clutter of plain JS is just painful to look at. I can't remember how many times I've looked over a 40 line block of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is just downright frustrating to be be wasting any time on what is effectively irrelevant syntax. With CS, it's indent and be done with it. It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less. To take Haml as an example:

.my-div %h1 Some Text - some_ruby_code

vs the ERB of

<div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>

[tragic]

> "With CS, it's indent and be done with it"

As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-)

I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that.

"It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less."

Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not.

A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc).

Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.

[jessaustin]

...two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces

Commit hooks will help you:

http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

The bigger your team, the more you need them.

[mistercow]

For open source projects, that's less of an option, but regardless, an individual's opinions about tabs and spaces are moot when working on a multi-dev project. You follow the project's conventions, or your changes don't get merged.

[jessaustin]

Yes it is frustrating that git doesn't automatically transfer hooks to cloned repos. I guess I understand the standard explanation of "git clone" never running arbitrary code on one's machine (although in a sense that is git's purpose), but it does reduce the use of client-side hooks in open projects.

[psychometry]

I see no reason why anyone should care that CSS is valid SCSS and HTML is valid ERb.

[tiglionabbit]

Ditching all the useless lines of closing brackets and parenthesis is my favorite part of using coffeescript. Matching up brackets is a pain. The less I have to do that, the better.

[vidarh]

My editors have had bracket/parenthesis matching for 30+ years, and automated indentation support as well. I don't get why anyone would do that manually.

[k__]

Also if it works good, you can give them the same color as whitespace, which I always show, but with almost the same color as the background. This reduces the cognitive overhead a bit.

[ffn]

It's also possible folks will continue forking and improving CoffeeScript so that it keeps up with future releases of vanilla js (which is actually what I hope will continue to happen). Folks like me who come from a Ruby / Python background really don't like brackets and declaring variables, so things like Coffeescript, LiveScript, CoCo, etc. are wonderful tools even despite their occasional moments of weakness.

That being said, you're absolutely right, folks who write in Coffee should also absolutely eventually learn all the tips and tricks behind vanilla js also if they don't want to be bogged down.

[smrtinsert]

I almost feel like the coffeescript variants are where the action is.

[berfarah]

Care to list some? I'm always interested in seeing what's out there

[Lazare]

The big one is probably LiveScript. I feel like it removes some of CoffeeScripts rough edges (the big one is the scoping rules; in LiveScript you have to use := to modify a variable in in outer scope).

[k__]

Yes, but they slowed down...

The LS2 issues are from years ago and nothing is happening.