It's near unreadable. It's optimizing the wrong things, prettiness (I don't think it's very pretty at all) and keystroke counts, vs readability, fewer errors and maintainability.

It also bugs the fuck out of me that CoffeeScript projects frequently end up being given a *.js extension in the name and how often people who want nothing in the world to do with CoffeeScript, people like me, end up having to deal with it for some reason. Like I don't like ada, and I never have to look at it. ada never ends up in my editor or on a github page I'm looking at, but frequently someone puts CoffeeScript somewhere where someone was expecting JavaScript, like a StackOverflow answer, or a package for Meteor, or something. If CoffeeScript stayed out of my life, and I out of it, I would probably hate it a lot less.

It's not that it's transpiled. I mean that isn't a great thing, but for example I like the idea of Dart and even TypeScript. But CoffeeScript? No thanks.

    > [...] how often people who want nothing in the world to do with CoffeeScript, 
    > people like me, end up having to deal with it for some reason. Like I 
    > don't like ada, and I never have to look at it. ada never ends up in 
    > my editor or on a github page I'm looking at, but frequently someone 
    > puts CoffeeScript somewhere where someone was expecting JavaScript, 
    > like a StackOverflow answer, or a package for Meteor, or something. 
    > If CoffeeScript stayed out of my life, and I out of it, I would probably 
    > hate it a lot less.

As the creator of CoffeeScript — I think your answer here is right on the money. It's a pretty perfect answer to joeblau's question.

First thanks, Coffeescript saved me days of work.

But I can understand , because it's popular , some people feel like they are forced to understand or learn it.

Yet you can be proud that Coffeescript influenced the latest ES spec, that's all that matters , you pushed Javascript forward, by saying "Dont wait for other to make the stuff you need, do your own stuff and eventually people will wake up and adress your intial issue".

Hear hear!

I'll never forget reading a blog post [0] by Brendan Eich in which he addressed upcoming ES features that were influenced by or emulated Coffeescript syntax.

It was a pretty solid Krusty the Clown reference on his part.

[0] https://brendaneich.com/2010/11/paren-free/

After using CoffeeScript for a few months I find JavaScript harder to read. Of course something foreign to you is going to be harder to read.

>It also bugs the fuck out of me that CoffeeScript projects frequently end up being given a *.js extension

If a project compiles down to Javascript and is intended to be used as such, a .js name suits it regardless of the source language.

Well since you can compile python, clojure, etc etc to JavaScript I guess the .js extension is meaningless. In my opinion it isn't at all OK, because a .js extension means that the code is in JavaScript, so that I can look at it, and maybe contribute. I'm not interested in CoffeeScript widgetmajigs that turn CoffeeScript into JavaScript. Use .coffee or maybe CoffeeScript just can't stand on its own. Maybe it's just riding JS's coattails and the moment it separates it becomes abandoned.

For the project, possibly. Not for an individual source file. That's bananas.

As a side note, I dislike the use of the term "transpiled."

A compiler is a program which translates between two programming languages. CoffeeScript -> JavaScript is just compilation. There is no need for a new word.

Most of the time, it's easy to ignore programming languages that you aren't familiar with. In day to day programming life, you're not going to be running into many examples of Eiffel, or Dylan, or D or E, in the wild. So you're not going to feel very strongly about them, either pro or con.

For better or for worse (I think for the better), CoffeeScript is fully interoperable with JavaScript. The runtime characteristics and the lowest-common-denominator ES3 support are such that you can use it just about anywhere you might want to use JS. That, and a modicum of success, means that JS programmers sometimes stumble across it in unexpected places, only after popping the hood. e.g. "I thought I was just using a simple library -- Eauggh! What is that stuff down there!" This makes it very hard to ignore...

As a JavaScript programmer, you're forced to ask yourself the question, "Why haven't I given CoffeeScript a real try yet?" Not all, but a large part of the dislike comes from folks rationalizing their response to that question to themselves.

tl;dr, CoffeeScript is almost perfectly situated to inspire fear and loathing in JavaScript programmers with closed minds.

Ah okay, that's a pretty interesting review. I was at an AirBnB Tech Talk and Isaac Schluetter (Head maintainer of Node.js) and he discussed his feelings on it. I've used it a few times and it's been fine, but I never felt compelled to learn it.

[1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&feature=player_de...

There's nothing of substance in his response. When asked what's worse or more ambiguous about CoffeeScript, his answers are:

1) That people who don't know CoffeeScript have to use CoffeeScript when they encounter CoffeeScript.

2) He thinks require might have been implemented differently, though he thinks that maybe that might have been changed, but "I don't really use it so I don't really know."

I frequently experiment with new programming languages (go, Rust, others) and I like Dart and have tried it. That's significant evidence that I'm not close minded. However CoffeeScript was at least for me the first of its kind, so maybe my negative perception has stuck with it unfairly. I do find it hard to read, but I'll tell you what I'll give it a try. :P

I found it a little awkward to read at first, but that went away in a short time. I suggest giving it a proper whirl. Most people who I've introduced to CS seem to really like it.

CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it.

I don't really dislike it but I really do not see myself using it if I had a task where I needed JavaScript.

Suprisingly, I have never even thought about compiling on Coffeescript since my rails app does that for me. Personally, I love using Coffeescript because it's just so much easier to write compared to javascript without thinking about braces and semi-colons. On the whole, I guess what framework you use affects how you use a language. In rails projects, it's very efficient to use coffeescript over javascript.

The problem is that sometimes what you write in CS results in surprising and/or incorrect JS.

This can be caused by an unnoticed block of whitespace, corner case of CS language itself, or me simply screwing something up.

About 5-10% of the time I hit a WTF in CS, which is, for now, an acceptable trade off vs. using pure boilerplate ridden JS.

If there was a concise TypeScript a la Scala for Java, I'd be all over it.

The syntax is broken. Things like operator precedence and associativity are the exact opposite of math conventions:

    f x + f y    // is f(x + f(y))
    f g x        // is f(g(x))

Not quite -- the rule is pretty simple: Implicit function calls associate to the right, to the end of the line (or the end of the trailing block). This allows you to write code like this:

    console.log inspect value

    model.save(attrs).then ->
      ui.update attrs

    rect.scale height * factor

... and have all of the results come out correctly, while leaving the code readable. If the rules were "more math-like" as you say, then none of that would work. Perhaps it would harmonize with special libraries that used functions (automatic-partial-application a-la Haskell) in a different way than JavaScript does ... but that's not the world we live in. It's gotta harmonize with JS functions as they exist.

I'm not sure where the idea originated that readability scales inversely with the number of parentheses, but I wish it would hurry up and die.

I'm not sure where the idea originated that readability scales with the number of parentheses, but I wish it would hurry up and die.

I'm not sure where the idea originated that readability scales, but &c., &c.

My brain isn't plastic enough to make this switch. :( For me, those code examples are uncomfortable to look at. backwards read to trying like It's

Right-o. The trick is to "read" it like pseudocode, or like English-ish.

    Log the inspected value.

    Save the model, then
      Update the UI with the attributes.

    Scale the rectangle by (the height times the factor).

The big syntactic difference still being the "model.save" vs "save the model" ordering of dot-notation. But them's the breaks.

I don't understand what's wrong with the second example. What do you think it should do?

In ML-family languages like OCaml and Haskell, function application is left-associative: f g x = (f g)(x).

I guess some just dislike the idea of sugaring Javascript. Others my think that it hides something that can bite your ass, though imho the oppossite is the case. For me personaly after spending some time with CoffeeScript writing plain JS was a displeasure for sure.

Very interesting that people are saying things like "significant whitespace" and "too similar to python" - I personally love Python and I like that coffeescript bears some resemblance to it. I voted "Coffeescript - Like" because it removes many of the mundane aspects of JS programming.

Definitely doesn't solve many of JS's problems, but it certainly makes things easier when writing client side apps. We use it a lot for Backbone development.

It's a quirky dialect of JavaScript, which has very little to offer. There is less typing, but that certainly wasn't JavaScript's biggest issue.

With languages like TypeScript, or Dart, you also reduce the amount of typing work, but that's just a side-effect of the good tooling these languages have to offer. You can auto-complete everything.

It makes a lot more sense to boost productivity via structure and tooling, because that's what really helps with scaling.

Personally I'm ready to start filtering anyone that prefers JS over CoffeeScript. Its just about superior in every way. Maintainability goes up as the lines of code drop precipitously and significant whitespace, come on guys. I use bracey languages all the time, and moving to one that doesn't isn't that big a deal.

The real problem is there are a lot of "developers" that came up just doing simple Javascript functions. They know their functions, and they dont want their world to change. They would rather accidently reference closure or global and type significantly more code than learn a slightly different way to code Javascript.

Complaints such as "extra hassle due to compilation" are laughable honestly. If adding a build step is an extra hassle, this might be the wrong profession. Tinkering should be in your nature!

CoffeeScript super charges Javascript. Any truly competent JS programmer that gives it a try for a few days would realize it.

"If adding a build step is an extra hassle, this might be the wrong profession."

That's a very railsy answer. The strength of the web is that you don't need to run a build at all. I think that's the fundamental dislike of Coffeescript. I've worked on so many html frontends where a build process wasn't necessary to accomplish our job, and if someone tried to introduce one for the sake of coffescript it would simply be an annoyance.

I'm currently using CoffeeScript for a big project on the web and the build step that I have automatically watches my coffee files and recompiles on a new change. Group that with using LiveReload and you have an auto recompile and reloading application with no additional manual build step.

It's also that you lose any ability to step-debug at the moment. You still need to know Javascript to debug Coffeescript by and large.

That mental context-switch overhead is the whole driving philosophy behind NodeJS in the first place - don't switch languages so often. CS/JS is enough of a change that the overhead is not insignificant.

Eh, I don't find switching back and forth to be that problematic in terms of context switching. That's because CS is very similar to JS in everything but syntax. Which is also why a solid JS background is almost essential when writing CS.

This is no longer true. You can debug CoffeeScript in web browsers now with source maps. Yes you may need to dig into JS for a more severe bug but most of the stuff is debug-able in source maps.

The problem for me is not technical per se, but that it adds another element of complexity to an already complex programming environment and has implications for human resourcing.

Becoming expert in a new language goes beyond learning syntax; one must also learn code conventions/style, compiler/transpiler quirks, runtime quirks, and library/framework ecosystem. In CoffeeScript the last two may be moot, but the first two remain. Additionally, to be an expert in a transpiled language, one must be an expert in the target language. It is much harder to find someone that has this knowledge and experience in both CoffeeScript and JavaScript.

This begs the question of each web dev team: if you are already experts in JavaScript, is the value-add from the transpiled language worth the cost of increased solution complexity/cognitive load, and smaller talent pool? My take is that CoffeeScript doesn't meet that bar for most teams.

For individual projects, or isolated one-off tools, these non-technical issues are moot. Also, server-side may be less of an issue since complexity is reduced by not having to write for multiple runtimes (only Node.js and usually without DOM).

Fixes a non-problem.

Ok, so Javascript has a bunch of gotchas but it's an interesting language which I both like and dislike but I don't dislike it enough to add yet another layer to my dev platform.

Also, as someone stated elsewhere on this page the true solution is to make a browser virtual machine and use any high level interpreted language you want.

Debug story perhaps? I haven't tried it but that's what puts me off.

Significant whitespace

My opinion is that it ended up causing more problems than it fixed. In theory is nice and beautiful, but once you start using for large projects you notice that it kills readability and introduces some other small problems.

I think some people still like wasting their time by writing "real" code from the start.

too similar to python

Not enough if you ask me. As other commenter said, too many JS-WTFs remain.

Not at all. I love Python and I don't like CoffeeScript. I think CS superficially looks like Python, but conceptually is more like Ruby/Perl.

It was a good idea but failed in execution. It might take fewer characters to type an instruction but at the cost of what? Being difficult to read? Ambiguity? Not really worth the time.

Any unfamiliar language is hard to read and will have seeming ambiguities.

In my experience working with CoffeeScript, I've always found well-written code easy to read with no ambiguities.